Thomas, the best way will be altering HR procedures / software to check for existing accounts in AD by Display Name while creating new employee card in HR DB. So HR people will have to decide whether it's a completely new account or contractor becoming a FTE.

Thomas, I'm struggling with this for years - no luck. If you create lets say contractors on the FIM portal, manually in AD or in NON-HR CSV MA, then during provisioning you obviously have to check for uniqueness of UPN, sAMAccountName and so on... Same with provisioning from HR MA. So what happens with me once a week :) - there's a contractor's account in AD which was created manually (from FIM portal or CSV - doesn't matter). There's also a new HR specialist who doesn't follow the procedure for hiring contractors to be FTE (actually all you need is to manually enter employeeID to this account in AD or on the FIM portal _AFTER employee card is created in HR system_ but _BEFORE delta import from HR MA will happen) - this never works. But when it does - new employee is joined on EmployeeID during import and no duplicated accounts are provisioned in AD. Most of times this new account is provisioned into AD and it looks like 'John Doe (2)' I have to confirm with HR that it's not the second john doe, but the first one who was a contractor now entered in HR as FTE. Once confirmed: 1. turn off provisioing rules extension in MV 2. disconnect AD MA and all other MA from this new duplicated MV entry so MV entry will be deleted 3. either use dsmod user to set employeeID manually so join rules will work or (prefered for me) go to disconnectors an manually join this CS entry from HR MA to the existing MV object of the contractor so he wil become a FTE 4. turn on provisioning rules extension in MV I'm also interested in how to teach HR people to follow the procedures :) ps. managing all contractors in HR system is not a solution due to business reasons

Thanks for the feedback. I was hoping for some silver bullet. My customer his data is really in a bad shape. So at some point the HR department will have to invole the users to get their data validated. A Portal of some kind may be involved to get things sorted.http://setspn.blogspot.com

I agree that this is an ongoing struggle. If you have a particular situation that occurs frequently in exactly the same way you could code something to look out for it, but more often it's just new examples of how people can enter bad data, and manual fixes are inevitable. I remember Pam Dingle once saying you have to get to the head of the queue - get some kind of web page or registration form right in at the beginning of the data entry process that heads people off in the right direction. But that's not something I've ever dared propose to an HR department alread entrenched in their ways of doing things.http://www.wapshere.com/missmiis

I'm kinda struggling with the following: Suppose you have two datasources besides AD/FIM. Initially they both contribute a user to the MV which gets added to FIM & AD. they are cumulative, meaning they don't manage information for the same identities. Now suppose an error was made: both CSV-NoHR and CSV-HR projected a user which in reality is the same person. This person already uses the AD account provisioned from CSV-NoHR. So theoretically the FIM/AD user provisioned from CSV-HR have to be deleted and the CSV-HR CS object has to be joined to the MV (CSV-NoHR) entry. This would allow the CSV-HR MA to contribute information to the AD account currently in use. A manual procedure could be: Disconnect MV-CS (CSV-HR) using sync manager Delete object in FIM: run Delta Imports + Delta Syncs => Deletion is triggered in AD Alter the equavalent FIM User in the Portal so that it joins up for sure with the disconnected CS object of CSV-HR Run the required run profiles However I'm wondering if there's any automated possibilities here. Or perhaps a more clever use of join rules orso. Any tips would be greatly appreciated. http://setspn.blogspot.com