Eliminating the Identity Manager Bottleneck
Microsoft Identity Manager (MIM) 2016 binds Microsoft’s identity and access management solutions together by seamlessly bridging multiple on-premises authentication stores like Active Directory, LDAP, Oracle, and other applications with Azure Active Directory.
Processing Jobs
MIM Synchronization jobs are created to sync various authentication stores into Azure Active Directory to create a single identity source to authenticate against. This can be within a single organization with multiple locations or a global organization comprised of many entities and unique authentication stores. MIM can also be used for syncing up Global Address Lists from multiple entities into a single GAL.
MIM processes the synchronization jobs in a first-in, first-out sequential queue. This single point of processing can become a bottleneck holding up other synchronization jobs. Examples include a job processing a large synchronization of many records or an entity that is being synced is on the other side of the globe and/or has a poor internet connection. This creates latency issues causing the job to take longer to run. A job with many records to process from an entity on the other side of the world can take days to process. While this job is processing, everything else waits in the queue. If you just added a new user and that user needs access to apps that are authenticated against the synced Azure Active Directory, it could take up to a week before this user can authenticate and access these apps because the job syncing their account is stuck in the queue. This of course is an unacceptable delay, yet it was actually occurring.
Actual Case Scenario
This involves an international firm with offices across the country in its U.S. division and member companies in 140 countries around the globe. These member companies are individual entities, independently owned, operating as members of the main company. The member firms can range in size from 5-5,000+ employees. Each member firm has its own Active Directory forest. They sync userid’s into a central Azure Active Directory for access to an assortment of corporate shared applications. The member firms also sync their GAL’s for ease of email communication between the firms.
The Active Directory sync jobs processed in an acceptable time frame, even for the larger firms. However, the GAL sync jobs were taking extended periods of time, specifically the job that pushed out the GAL updates to all 140+ firms. This job was taking up to a week to run. Since MIM does not allow parallel processing of jobs, nor prioritizing of jobs, all jobs had to process sequentially in a queue in the order they were submitted. This caused delays in the processing of the AD synchronization jobs, delaying users from accessing the shared applications.
The Solution
SPR analyzed the problem and developed a solution to eliminate the bottleneck allowing Azure Active Directory synchronization to process in a timely manner. SPR solved the problem by adding a 2nd MIM server and then migrated the GAL sync processing to that server.
The original server now only processes AD synchronization jobs. With the two synchronization processes running on separate servers, the AD synchronization jobs can run without delay and the GAL synchronization processes can run as long as needed without impacting the AAD synchronization. In this configuration the servers are only running the MIM 2016 Synchronization Service, no other MIM components are installed.
Database Requirement
This design required the creation of a 2nd MIM SQL database since MIM only allows one server at a time to connect to its database. A 2nd MIM SQL instance was created on the existing SQL database server for the GALSYNC process. Both the AD sync and the GAL sync are now connected to their own databases and run independently.
End Result
Critical jobs are no longer held up in queue while long running lower priority jobs are processing. New users can get authorized access to the shared apps in less than 24 hours versus waiting days in the past.
