If you treat the FIM Synchronization Service well and your configuration is good, it will reward you and the ‘magic’ will happen. At my customer site, the ‘magic’ stopped working and I was faced with an increasing number of synchronization errors being ‘An object with DN “CN=<blah>” already exists in management agent “<blah> MA” ‘. For users that were already provisioned correctly, the FIM Synchronization Service was attempting to re-provision a duplicate object in the destination directory but obviously the account already existed. Why was this occurring and how to resolve it? To be honest it stumped me for quite a while until I remembered I was faced with the same scenario a few years ago with yet another FIM Synchronization Service with many 100s of thousands of objects.
Before I start, I’ll preface that this blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. Let’s delve deeper.
We should all know that best practise when making changes to any part of the FIM Synchronization Service configuration, or new or updates to FIM Service Synchronization Rules, you should do a Full Synchronization cycle to ensure the changes and rules are all processed against the objects in the solution. When you are working on a large solution with 100s of thousands of objects, it is not always possible to do this Full Sync cycle at will and it needs to be typically scheduled as a change over a weekend, maybe even a long weekend! We had attempted a full synchronization cycle on this customer solution in the past and it took just on 2 days to complete. So when you don’t have the opportunity perform this cycle, you use your prior knowledge, expertise and judge if the solution can continue to function if a change has been made. In my case, a new attribute flow in a Synchronization Rule which was not critical to the existing objects in the solution. So I thought I could avoid a Full Sync cycle and everything appeared to be working as expected.
Over a few weeks, these sync errors started to occur as illustrated below and they were increasing until I got to around 40 errors and further troubleshooting action needed to be taken.
The customer had rules in the solution to detect when an existing user account was disabled and perform some functions in the FIM Service. If the user account was re-enabled, the ‘provisioning’ MPR was triggered as the user was back as a member in the ‘provision accounts’ Transition Set. Workflows assigned a handful of Synchronization Rules against the user as Expected Rule Entries (EREs), which had already applied to the user when it first came to existence and provisioned. These duplicate EREs when flowed from the FIM Service to the FIM Synchronization Service were throwing the errors.
Back in the test environment, the ‘magic’ was still working with no errors thrown. What normally happens in this situation is if you happen to assign a provisioning Sync Rule to a user account, but that user already had one previously successfully ‘applied’ (and was already provisioned), this duplicate ERE would be processed by the Sync Service and also marked as ‘Applied’. It was smart enough to know that the provisioning event was not required because an existing ERE had already been assigned. When the Sync Service flows the status of the duplicate ERE back to the FIM Service, the duplicate is deleted and world order is restored with this ‘magic’. Sorry I find no way of easily describing it without detailing my scenario, so I hope you are still following me. So why was it not working in production?
I’m not sure of the internal innards of the Sync Service, but what I have found is when a delta import change of a Synchronization Rule flows into the Sync Service and a ‘Delta Sync’ is processed on this change, it seems to have an adverse effect on the other Sync Rules. Sync Rules that have previously been working fine start behaving badly and to put it simply, the ‘magic’ breaks.
The fix is to obviously perform a Full Synchronization on the whole solution because a configuration item has changed. However, without having the easy opportunity to do this, I needed to perform a Preview/Full Synchronization on each Synchronization Rule in the solution as illustrated below. Although no obvious change is shown in the preview window, it seems like each Sync Rule is re-processed/reset into good working order and the ‘magic’ is restored.
After performing this change against all Sync Rule objects, all synchronization errors have been cleared and the ‘magic’ now works as expected. I didn’t find much in the forums or public domain about this scenario, so I hope this helps somebody in the future. I’m now working on getting the full synchronization cycle actioned! Let me know in the comments below if this has saved you.
