Moving Dirsync Between Active Directory Forests

With the ever growing popularity of Office 365 it’s no surprise that situations are starting to pop up where organizations want to move Dirsync between forests. A recent example of this was a customer who divested from a parent company leading to an inter-forest migration using the traditional ADMT tool set. Consequently directory synchronization (version 2.0) also had to be moved between forests. The good news is that this IS possible despite a fair amount of web content to the contrary. Below I describe how this can be achieved;

The following diagram depicts an existing environment with an Exchange Hybrid Coexistence model in place between a ‘Legacy AD Forest’ and Office 365, obviously complete with Directory Synchronization with password sync;

In the above scenario ADMT is used to provision objects from the ‘Legacy AD Forest’ to the ‘Target AD Forest’, the challenge is then how can Dirsync be setup in the ‘Target AD Forest’ to successfully match up against the original objects within WAAD (Windows Azure Active Directory)

Re synchronizing User Objects

By default Dirsync uses the objectGUID attribute as the immutable ID that distinguishes a user in both on premise Active Directory and the Windows Azure Active Directory. During the directory synchronization process Dirsync takes each objects GUID value and converts it to base64, this is then stamped to the objects ImmutableID attribute within WAAD.

Following on from object provisioning by ADMT, if a Dirsync server is then established within the ‘Target AD Forest’ and an attempt is made to synchronize those objects back to the Windows Azure Active Directory, whilst ‘soft matching’ will work based on UserPrincipalName, Dirsync will be unable to update those objects on account of the ImmutableID differing between the on premise object and the object in WAAD.

To observe this error, open up the FIM Synchronization Service Manager on the newly provisioned Dirsync server in the ‘Target AD Forest’, browse to the ‘Management Agents’ tab, open up the ‘Windows Azure Active Directory’ management agent and view the errors that occurred during the last attempted synchronization. There you will find an error for each object that has an identical UPN value but a different ImmutableID. Below is an example of such an error;

To work around this issue the objectGUID attribute in WAAD can be cleared and upon the next DirSync synchronization, the soft matching process will match user objects based upon UserPrincipalName. The objectGUID of the user object in the target AD forest will then be converted to base64 and stamped as the immutableID attribute in the corresponding user object in WAAD.

This can be achieved as follows;

• Stop directory synchronization in the ‘Legacy AD Forest’, this should be accomplished by stopping and disabling the ‘Windows Azure Active Directory Sync Service’ on the Dirsync server.
• Disable Directory Synchronization on the Office 365 tenant by issuing the following commands against the tenant:

Set-MsolDirSyncEnabled –EnableDirSync $false

• Disabling Directory Synchronization can take a lengthy amount of time to complete but this will vary depending on the amount of objects contains within WAAD. Microsoft advise that this process can take up to 72 hour to complete so ensure enough time is left for this step and consider the implications this will have on your tenant. In reality disabling/re-enabling Dirsync is likely to take a few hours at most.
• To check on the status of disabling directory synchronization issue the following commands and check the DirectorySyncronizationEnabled is equal to False:

Get-MSOLCompanyInformation

• The following basic following command can be used to remove the immutableID value:

Set-MsolUser -UserPrincipalName “User Principal Name ” -ImmutableId “$null”

• Obviously its likely that you’ll want to extend the above command to update all of necessary objects within WAAD at the same time. Once all necessary objects have been updated to remove the current immutableID values, the process of enabling Dirsync in the ‘Target AD Forest’ can be performed as follows;
• Re-enable directory synchronization on the Office 365 tenant using the following Powershell commands

set-MsolDirSyncEnabled -EnableDirSync $true

• Re-enabling Dirsync can also take a period of time, Microsoft quote this as taking up to 24 hours but in practice I’ve observed this taking much less time. This can be checked in the same manner as before by utilizing the Get-MSOLCompanyInformation cmdlet.
• Once this process is complete the Window Azure Active Directory Sync Service can be enabled and started on the Dirsync server in the ‘Target AD Forest’
• Directory synchronization can then be forced by either re-running the ‘Directory Sync Configuration’ wizard or running the ‘Start-onlinecoexistancesync’ command from a WAAD powershell session.

Re-synchronizing Group and Contact Objects

Now, all of the above information holds true for user objects but what I hear you all say happens to group and contact objects that are also synchronized from the on premise Active Directory to WAAD? Well, groups and contacts do not use the ImmutableID attribute in the same manner as previously discussed. Consequently if you wish to synchronize these objects from the ‘target AD’ to WAAD, the only method to do this currently is to delete them from WAAD and allow Dirsync to essentially recreate them. This can be achieved as follows;

• Stop directory synchronization in the ‘Legacy AD Forest’, this should be accomplished by stopping and disabling the ‘Windows Azure Active Directory Sync Service’ on the Dirsync server.
• Disable Directory synchronization on the Office 365 tenant by issuing the following commands against the tenant:

Set-MsolDirSyncEnabled –EnableDirSync $false

• Disabling Directory Synchronization can take a lengthy amount of time to complete but this will vary depending on the amount of objects contains within WAAD. Microsoft advise that this process can take up to 72 hour to complete so ensure enough time is left for this step and consider the implications this will have on your tenant. In reality disabling/re-enabling Dirsync is likely to take a few hours at most.
• To check on the status of disabling directory synchronization issue the following commands and check the DirectorySyncronizationEnabled is equal to False:

Get-MSOLCompanyInformation

• Use the get-msolgroup and get-msolcontact powershell cmdlets to remove the required group and contact objects from WAAD
• Re-enable directory synchronization on the Office 365 tenant using the following Powershell commands:

set-MsolDirSyncEnabled -EnableDirSync $true

• Re-enabling Dirsync can also take a period of time, Microsoft quote this as taking up to 24 hours but in practice I’ve observed this taking much less time. This can be checked in the same manner as before by utilizing the Get-MSOLCompanyInformation cmdlet.
• Once this process is complete the Window Azure Active Directory Sync Service can be enabled and started on the Dirsync server in the ‘Target AD Forest’
• Directory synchronization can then be forced by either re-running the ‘Directory Sync Configuration’ wizard or running the ‘Start-onlinecoexistancesync’ command from a WAAD powershell session.

Points to Note

• If your organizations MX records are pointing directly to Office 365, using the above process to delete and recreate group and contact objects WILL result in a period of time when any email addressed to those objects from the outside world will bounce and generate an NDR.
• Depending on the amount of group and contact objects within your organization, deleting these objects from WAAD could take quite a long time which could exasperate the above point. Microsoft quota the number of changes that can be made to a tenant in a period of time and although these limits can be raised upon request, this is likely to still be a factor.
• If your organizations MX records point to another AV/AS service prior to hitting Office 365, it could be possible to park inbound email for a period of time while the above changes are being made. This could help to mitigate issues around the generation of NDRs.
• It may be worth considering source of authority for group and contact objects before performing this process as it may be desirable to have these objects authored from WAAD instead of your on premise Active Directory. Another of my blog article discusses this topic in more depth.
• Whilst this blog discusses user, group and contact objects separately, you may wish to consider making the changes required to re-synchronize all of these objects in a single change window to minimize impact/outage.