I am trying to wrap my head aroundon how to efficientlyhandleprovisioning of contact objects.In one test scenario, I created a separate contact object type in FIM portal bound with a subset of attributes I wanted associated to this object type and established flows to contact object type in MV. It could be done but I am not so sure that this is the way to go. Suggestions?A specific use case that I am testing- I want to be able to create users by default as mail enabled contactsin exchange. AfterAuthZ workflowsin FIMhave completed successfully, I want to thenmove these contact objects to user objects. Futher, based on certain criteria, these user objects couldget a mailboxin exchange or can remainasmail-enabled user.So toflip between user andcontact states what's thebest design approach -use distinctobject types in FIM or create a complex set that will drive provisioningof user vs contact or ....?Thanks. Anu

Anu, I'm not sure I understand what it is you are trying to accomplish. A contact is a lightweight user, a user without a SID, means, the source of a contact is a user.Why do you need a separate object type in FIM for them? Could you please elaborate further? Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Marcus,It is aa common scenarioin Active Directory today thata person canexist as a Contact and as aDisabled User. The state could furtherchange, meaning the Contact object could be deleted and User object re-activated; or, Contact could continue to persist but the disabled User object could be deleted.If both Contact and User states for the same person must be provisioned and managed in AD via FIM,I need a clear direction on how to use the single person object in FIM to manage both. And, if this cannot be done, or is not easy or efficient then I haveto knowwhy and know if extending FIM and a new object type is the only solution.Thanks! Have a good weekend. Anu

Any idea????Anu

AnuYou could add two attributes to the idenity if the portal (one to indicat that user account should exist, one of the contact), you might be able to codeles sync to manage he associated accounts, but your fall-back is "classic" provisioning.RegardsSteve Mitchell Technical Director - Oxford Computer Group

Anu,one big word of advice - don't create seperate object types in the FIM portal or in the metaverse Treat all people as "person" objects and then determine exactly what happens to them in AD based on their attributes.I once worked in an environment where we had regular movement from "user" to "disabled user + contact" and sometimes back again. Treating everyone as a "person" in the metaverse made my life a lot easier.This was on MIIS 2003 using the old style metaverse extension of course - which is still the best way to go for flexibility IMO.http://www.wapshere.com/missmiis

Totaly agree with Carol as far as the sync engine is concerned,However, there is one issue in the FIM portal world - there is no way to distinguish between the "object types" of a base object using RCDC, so if you want different attributes to be available in the UI depending on the person.EmployeeType, you have a problem (well, to be specific, it's impossible).A possible solution (just thinking of the cuff here guys) maintain the object as a person in the MV with an object type, create two new MV object type (FIMperson, FIMcontact - say), use a reflaction MA to sycn data to/from the person to the othe objects. May work, but I can already anticipate all sorts of issues even as I type :-)RegardsSteve Mitchell Technical Director - Oxford Computer Group