For those of you that may have missed it, in early 2016 Microsoft released a hotfix for Microsoft Identity Manager that included a change that removed the ability for multiple management agents on a Microsoft Identity Manager Synchronization Server to simultaneously run synchronization run profiles. I detailed the error you get in this blog post.
At the time it didn’t hurt me too much as I didn’t require any other fixes that were incorporated into that hotfix (and the subsequent hotfix). That all changed with MIM 2016 SP1 which includes functionality that I do require. The trade-off however is I am now coming up against the inability to perform simultaneous delta/full synchronization run profiles.
Having had this functionality for all the previous versions of the product that I’ve worked with for the last 15+ years, you don’t realise how much you need it until its gone. I understand Microsoft introduced this constraint to protect the integrity of the system, but my argument is that it should be up to the implementor. Where I use this functionality a LOT is with Management Agents processing different object types from different connected systems (eg. Users, Groups, Contacts, Photos, other entity types). For speed of operation I want my management agents running synchronization run profiles simultaneously.
Overview of my workaround
First up this is a workaround not a solution to actually running multiple sync run profiles at once. I really hope Microsoft remove this limitation in the next hotfix. What I’m doing is trying to have my run sequences run as timely as possible.
What I’m doing is:
- splitting my run profiles into individual steps
- eg. instead of doing a Delta Import and a Delta Sync in a single multi-step run profile I’m doing a Delta Import as one run profile and the sync as a separate one. Same for Full Import Full Synchronization
- running my imports in parallel. Essentially the Delta or Full imports are all running simultaneously
- I’m leveraging the Invoke Parallel Powershell Script to do this. Very similar to how I leverage it to perform VM tasks in parallel in Azure
- utilising the Lithnet MIIS Automation Powershell Module for the Start-ManagementAgent and Wait-ManagementAgent cmdlets to run the synchronisation run profiles
This example script incorporates the three principles from above. The environment I built this example in has multiple Active Directory Forests. The example queries the Sync Server for all the Active Directory MA’s then performs the Imports and Sync’s. This shows the concept, but for your environment potentially without multiple Active Directories you will probably want to change the list of MA’s you use as input to the execution script.
- The Invoke-Parallel script from here
- The Lithnet MIIS Automation Powershell Module from here
- You’ll need a naming standard for your Run Profiles and Run Profiles created on each of your Management Agents created accordingly. I use DI for Delta Import, DS for Delta Sync, FS for Full Sync etc
The following script takes each of the Active Directory Management Agents I have (via a dynamic query in Line 9) and performs a simultaneous Delta Import on them. If your Run Profiles for Delta Imports aren’t named DI then update Line 22 accordingly.
With imports processed we want to kick into the synchronisation run profiles. Ideally though we want to kick these off as soon as the first import has finished. The logic is;
- We loop through each of the MA’s looking for the first MA that has finished its Import (lines 24-37)
- We process the Sync on the first completed MA that completed its import and wait for it to complete (lines 40-44)
- Enumerate through the remaining MA’s, verifying they’ve finished their Import and run the Sync Run Profile (lines 48-62)
If your Run Profiles for Delta Sync’s aren’t named DS then update Line 40 and 53 accordingly.
While we don’t have our old luxury of being able to choose for ourselves when we want to execute synchronisation run profiles simultaneously (please allow us to Microsoft), we can come up with band-aid workarounds to still get our synchronisation run profiles to execute as quickly as possible.
Let me know what solutions you’ve come up with to workaround this constraint.