[ UPDATE: A new version of Dirsync was released in June 2013 which uses the username MSOL_AD_SYNC_ followed by a random hex value in order to make the username unique. This helps with the two-accounts-with-the-same-username issue but the basic principle of filtering/scoping the two Dirsyncs still applies so I’m leaving this post “up”. ]
I recently assisted an educational customer who had two independent live@EDU tenants with upgrades to Office365. They were previously provisioning users into the two tenants using two separate management agents on an old MIIS 2003 server and keep all users in a single AD. Therefore, we needed to find a way to make things work using only the Dirsync tool provided by Microsoft.
Dirsync is basically a preconfigured version of FIM 2010 which has two management agents in it: one to connect to an AD and another to connect to Office 365/Azure AD. What we needed to figure out was how to get two Dirsync installations to cooperate while working from a single source AD.
Here’s how I approached the problem.
1) How to allow two Dirsync installations to connect to the same source AD:
Getting two copies of Dirsync to both talk to the same AD is easy. When you run the Dirsync configuration wizard, it creates a domain account called MSOL_AD_Sync which is assigned a randomized password. Obviously, running the installer for Dirsync #2 overwrites the password used by Dirsync #1 so the solution was to set up Dirsync #1, get it working properly (see below) and then repeat the process with Dirsync #2. Then, set the password on the MSOL_AD_Sync account to a known value and update the configuration on both Dirsync installations to use that password. Piece of cake!
2) How to get two Dirsync installations to provision only the “right” users from the source AD.
I handled this one by taking advantage of one of the few supported customizations to Dirsync: Using an attribute to limit the objects that Dirsync will handle.
The first part of this task is to find a way to label all users with a value that indicates what tenant they should be synchronized to. In my case, since users are imported into MIIS from two separate SQL databases — one for each set of users — I added a flow to the SQL server MA’s to include a value which reflected the user’s origin. For example, users arriving from the database for students from database A were labeled as belonging to A and similarly for students arriving from database B.
At this point I had MIIS set up so that every user had a label to show where they came from… but this important information was still only within MIIS.
Next, I added a flow to the MIIS management agent for AD which copies the point-of-origin value into the extensionAttribute15 attribute on the matching AD user object. Now I had every user in AD labeled with where they belonged. Progress!
The last step was to configure the two Dirsync installations to each EXCLUDE the “wrong” users. The process for doing this involves creating a “connector filter” entry within the SourceAD management agent in each Dirsync that matches the value that is applied to users that you don’t want to sync. This is a fully supported customization for Dirsync and is documented at http://technet.microsoft.com/en-us/library/jj710171.aspx. An example of how this looks is in the screen shot below. In this case, any user in AD with the value “A” in extensionAttribute15 will not be processed by Dirsync.
While doing so isn’t an absolute requirement, I strongly recommend that you make these filter modifications after Dirsync has been configured but BEFORE the first synchronization run so you don’t create a bunch of stuff in Office365 that later needs to be cleaned up.
How this looks when you turn the crank — and ongoing impact to Dirsync:
When you run Dirsync the first time, it will load all users in your AD (“listed as Adds”). This is normal. Then, the filter will be applied and you will see a number of objects listed as filtered disconnectors. These are the objects that Dirsync skipped when processing them because they matched the filter.
Then just verify in your O365 tenant that the right users have been synchronized and, if necessary, check your filters if you are still seeing things that shouldn’t be there. In my case, I had to add an extra filter condition to also exclude users with no value set in extensionAttribute15 to keep out other non-student accounts that were in AD.
NOTE: Because Dirsync will re-check all of these disconnectors every time it runs a processing cycle, this approach will increase the load on the Dirsync server and make processing take longer. For the customer that I was working with, with a total of about 30,000 users between the two tenants, this has not been a problem.