Hello! We have 2 Oralce Management Agents, FIM MA and ADMA. The data flow is going Oracle MA -> FIMMA -> AD and it's organized by FIMsynchronizaion rules. We have to restore th data from backup. But there are a lot of provsioned accounts in the AD. When we are perform the Full Sync on FIMMA, the error An object with DN "cn=..." already exists in management agent ADMA. We have disabled Provisioning and creating Join rule in ADMA (oject Person), then we: run Full Import on FIM MA and ADMArun Full Sync on FIM MA and ADMA no Joins was performed. Also when I click on the object and run the Preview, no joins are seen. How to troubleshoot this issue? Please hekp to solve the problem. Thanks!

Which exactly are you restoring from backup, and what, if anything, is being retained without a restore? Given my understaning of FIM disaster recovery, you would need to run a full import and a full sync on the FIM MA before synchronizing any other MA after doing a restore of the FIM sync and service database(s). The reason is that the FIM MA will only join based on metaverse object ID, and if you project any objects in from other MAs first it can never join to them because they are generated at random. I'm not sure why you're seeing the object already exists error with provisioning turned off...make sure that you have both kinds of provisioning disabled in the Sync Server manager. However, if the FIM MA is projecting the objects into the metaverse you should be able to join the ADMA objects to it when the ADMA full sync runs, assuming your join rules have something to join on. Chris

Additional information In the connector space of the OracleMA I see the user entry in the Metaverse ant it has connectors for user in OracleMA and FIMMA. In the connector space of the ADMA I see the same user entry in the Metaverse and it has connectors for user in ADMA and FIMMA. The metaverse object id from both connector entries does not match. Do the fim is generated random object id? What do you mean with "...both kinds of provisioning disabled in the Sync Server manager"? I see only Tools->Options-> Enable Synchronization rule provisioning. One more question: cna you clarify the step by step process to recover fim in the disaster recovery? Restore the DB'sFull import on the all agents to incialize themDisable Provisioning (tools -> options)Full import on the FIM MA and ADMAFull sync on FIM MA and ADMA Are the steps correct? Thanks!

The FIM Sync Service generates a new metaverse object ID (a GUID) when an object is projected into the metaverse. This is why the FIM MA must be the first to have a full sync run after restoring from backup, as it must be first to project...otherwise it won't join properly. Based on your description, you have duplicate metaverse objects, some tied to Oracle the duplicate connected to AD (or vice-versa). This could happen if you project into the metaverse from both Oracle and AD, and do not have proper join rules set up to join existing metaverse objects rather than projecting new ones. When I said both kinds of provisioning, I mean clearing the checkbox for "Enable Provisioning Rules Extension" AND "Enable Synchronization Rule Provisioning". If you're doing all your provisioning codeless via the FIM MA, perhaps you can get by only unchecking the second one, but since obviously something is doing provisioning you'd be best off covering all the bases. The DR plan is always going to be a little different for each environment. What you have laid out is correct (though #4 could be included in #2 as the FIM MA and ADMA are management agents, too) at least until you get to the full sync on the FIM MA. Whether the ADMA is the next MA to run a full sync depends on your scenario. Since Oracle seems to be authoritative in your environment, it might be best to run the full sync on the Oracle MA(s) first and then the AD MA. However, for this to work, you absolutely must have join rules configured that lets FIM match the AD MA connector space objects to the existing metaverse objects. If sAMAccountName is generated in Oracle and flowed out to AD, that might be a potential join candidate. In my environment, we get a separate key value from our ERP system and flow it out to employeeID in AD, and that value is always used preferentially for joins on any MA that can hold it somewhere, including the AD MA. Once you get everything back in the metaverse and joined up properly, you would also need to re-enable provisioning and run another round of full syncs, at least enough to hit all your objects at least once just to be safe. An additional caveat there is if you are using equal precedence then the order of the full syncs will determine which MA "wins" in deciding what is in the attribute value set for equal precedence. Chris

The FIM Sync Service generates a new metaverse object ID (a GUID) when an object is projected into the metaverse. This is why the FIM MA must be the first to have a full sync run after restoring from backup, as it must be first to project...otherwise it won't join properly. Based on your description, you have duplicate metaverse objects, some tied to Oracle the duplicate connected to AD (or vice-versa). This could happen if you project into the metaverse from both Oracle and AD, and do not have proper join rules set up to join existing metaverse objects rather than projecting new ones. When I said both kinds of provisioning, I mean clearing the checkbox for "Enable Provisioning Rules Extension" AND "Enable Synchronization Rule Provisioning". If you're doing all your provisioning codeless via the FIM MA, perhaps you can get by only unchecking the second one, but since obviously something is doing provisioning you'd be best off covering all the bases. The DR plan is always going to be a little different for each environment. What you have laid out is correct (though #4 could be included in #2 as the FIM MA and ADMA are management agents, too) at least until you get to the full sync on the FIM MA. Whether the ADMA is the next MA to run a full sync depends on your scenario. Since Oracle seems to be authoritative in your environment, it might be best to run the full sync on the Oracle MA(s) first and then the AD MA. However, for this to work, you absolutely must have join rules configured that lets FIM match the AD MA connector space objects to the existing metaverse objects. If sAMAccountName is generated in Oracle and flowed out to AD, that might be a potential join candidate. In my environment, we get a separate key value from our ERP system and flow it out to employeeID in AD, and that value is always used preferentially for joins on any MA that can hold it somewhere, including the AD MA. Once you get everything back in the metaverse and joined up properly, you would also need to re-enable provisioning and run another round of full syncs, at least enough to hit all your objects at least once just to be safe. An additional caveat there is if you are using equal precedence then the order of the full syncs will determine which MA "wins" in deciding what is in the attribute value set for equal precedence. Chris