Hi folks. Please bare with me if I'm asking really stupid questions here, I'm really new to FIM/ILM/Miis! I have a pre-existing AD with about 25.000 users and 15.000 security groups. Yep, 15 k! And in a year, it may well be twice as big... I'm gonna sync and provision accounts and groups from an HR database, but initially only about 2/3 of the AD accounts will be synced/provisioned. The rest will be handled manually directly from the AD snap-in. Also, at least initially, only a fraction of the synced/provisioned users and groups need to be managed via the FIM portal, so I don't have to sync them in there. I'm thinking leaving out the unmanaged objects will speed things up significantly. But if the best strategy to resolve the unique samAccountName problem is to import the lot into the portal, so be it. Let me also point out that no accounts will be created from the FIM portal - at least not currently. So I don't have to bother with checking for uniqueness there. Q1: Since quite a few accounts and groups will be handled outside FIM, I reckon checking for uniqueness (and if necessary re-construct the DN and account name) would be best handled during export to the AD? (As close to the actual account creation in the AD as possible.) Q2: Assuming the answer to Q1 is "yes", I suppose DNs and account names should only flow in to the MV (and be synced to FIMMA if they're gonna be managed there) from the AD, never the other way around? Q3: I can always code an LDAP search for each pending account creation, then re-construct the DN and account name if needed. But what about dealing with it in an error handler instead? That could be more efficient, since only few account names will be duplicates. Is that possible and if so, how/where do I trap the error? Do errors thrown from a connected AD sort of "bubble up" into FIM? And if they do, would it be safe, or do I risk all sorts of nasty side effects in the AD, memory leaks and such? (Yeah, I know, handling business logic in exceptions is kinda messy, but I figure any little performance gain is crucial with such a big AD.) Thanks! /Jonas

Do it as an import flow rule (old style, coded) from your source/s. See this example: http://msdn.microsoft.com/en-us/library/ms696019(VS.85).aspx I believe in handling these things as Import flow rules. Flow the good data into the metaverse, and then it's already there for your provisioning rules. http://www.wapshere.com/missmiis

Do it as an import flow rule (old style, coded) from your source/s. See this example: http://msdn.microsoft.com/en-us/library/ms696019(VS.85).aspx I believe in handling these things as Import flow rules. Flow the good data into the metaverse, and then it's already there for your provisioning rules. http://www.wapshere.com/missmiis Thank you Carol, I certainly see the point of flowing good data to the metaverse. Problem is, a lot of accounts will be created outside of FIM and I was hoping not to have to import the OUs with manually created accounts into FIM at all, to gain performance. And even if I do import these accounts to FIM, there's still going to be at least some lag between the import/sync of them, and the export of the FIM created accounts to the AD. That means there's a risk that some AD admin creates an account for a john.johnson in company x (not in the HR db), a few minutes before FIM creates an AD account for John Johnson in company y (in the HR db). And then FIM will fail to create the john.johnson account. It may not be a big risk, but still. We have a surprising amount of same-named people in our organization already. And since we're in the education business, we tend to create a lot of accounts at the same time. (The HR database is for both staff and students and most of them get accounts.) Now, would there be any risks involved if I was to handle this in an export rule instead? If so, I'm gonna have to weigh the risks before I decide on my strategy. /Jonas