During a recent customer support case, I noticed that a scheduled import and sync run profile stopped running its sync step. Here’s what happened and why...
Microsoft Sync services (ILM/FIM/MIM) have the concept of a ‘run profile’, which describes the operations to perform for a specific sync management agent (MA). These run profiles may contain one or more steps. In this case, a database MA had a run profile with two steps: a Full Import step, followed by a separate Delta Sync step (not the single step import and sync option).
The customer reported that data that would normally come into the metaverse during the sync step suddenly stopped flowing. Upon investigation, it was discovered that the sync step was not executing. The second step was being completely bypassed. The cause of this issue was that the Full Import step had duplicate object discovery import errors. This caused the sync step to not execute. We worked around by breaking the two steps into separate run profiles, while the customer worked with their database administrator to fix the duplicate objects in the database view.
Related to this is another unexpected consequence of imports with discovery errors. When there are discovery errors during an import, any subsequent sync operations of the MA will not process deletions of any objects in that MA’s connector space. This applies to all MA connector space objects, not just the errored objects. I have seen this situation several times, and this scenario is not always obvious, especially to inexperienced FIM/MIM practitioners.
With all these potential issues related to import errors, it’s important to have some process in place, either manual or automated, to review the results of your run profile executions. Because when the quality of source data fails validation, FIM/MIM takes special steps which can result in unexpected downstream results.
Frank Drewes is a Senior Architect at Oxford Computer Group. He’s being doing Microsoft Identity as long as Microsoft has had identity products. Frank’s on Twitter @frankdrewes.