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.
Category:
Communication and Collaboration, Exchange, Identity and Access Management, Office 365
Tags:
,

Join the conversation! 9 Comments

  1. Great article Andy! I’ve had to piece together these steps from other blogs – though your summary here is concise. I often perform inter-forest domain migrations, and have recently come up against this challenge. I suspect there will be plenty more in the future too!

    Reply
  2. Also – good catches on the deletion of Groups & Contacts. If acceptable – you could always change the DBEB (Directory Based Edge Blocking) feature off for the domains you’ll be doing this with. By changing the Domain in EOP (Mail-Flow–>Accepted Domains) and changing the Domain Type(s) to “Internal Relay” rather than “Authoritative” it will effectively disable DBEB – allowing any mail to be delivered to the mail server during the time you don’t have the groups/contacts present in WAAD. Once synchronized again and you have your groups synchronized again, you could change back your Domain Type(s) to Authoritative.

    Reply
  3. Is there a way to unlink DirSync from the current domain and then resync it up to a newly created domain/forest made from scratch with all the same user names & emails? I only have 40 users and syncing forests isn’t possible due to the current provider uses NAT on their end…

    Reply
    • Yes absolutely, subsequent to the this blog, MS have obviously released a number of iterations of the directory sync product, the latest of which being Azure AD Connect. They now include the ability to soft match based on SMTP address so as long as the users in your new domain have the same SMTP address, you can simple install the sync tool and connect the new domain users to the existing Azure AD accounts.

      Reply
  4. In my scenario there is a trust between the legacy and target forests. I don’t believe I can have the same UPN suffix in both forests in this case, correct? How will the soft matching work? Will it chose another attribute or would I have to remove the UPN in the legacy forest, add it to the new forest and assign to users all after I disable dirsync?

    Reply
    • Hi Benny,

      There are a number of ways you can tackle this problem, and it really depends on whether the legacy forest will be retained after migrating to the target forest.

      As there is a trust in place between the two forests, you are correct in the fact that you will not be able to have the same UPN suffix in both forests. To work around this problem, and to have accounts soft match in the first instance when you sync the target forest, you can do the following.

      1. Stamp the existing immutableid of the legacy forest (Convert ObjectGUID to base64) to an extensionattribute of the object in the target forest.

      2. Configure your synchronisation service in the target forest to sync based on the above extensionattribute.

      This process will successfully soft match the objects as the immutableid will be the same.

      You can then clean up the legacy forest UPN values, and allow the required UPN suffix to be added to the target forest.

      NOTE: If you are using ADFS to authenticate the target forest, custom claim rules will be required in order to address the extensionattribute above.

      Shane.

      Reply
      • Hi Shane,

        assuming that I’m in an environment very similar to the one described by Benny, what if I want to migrate users in batch? for example 50 users\day? Should I use the AADConnect installed in the legacy domain and configure it to read from both forests?

        thanks

      • Hi Manueleb,

        You could do it this way, although if the legacy forest is going to be decommissioned, you may be better off installing AAD Connect in the target forest and migrating users’ from this instance.

        Kind regards,
        Shane.

      • Hi Shane, thanks for your answer. I’ve one more question. What about the UPN suffix?
        In my case the email domain will be unchanged so I need to reuse the same UPN on the target forest. If we migrate users in batch (for example 50\day), the UPN suffix should be shared between both forests. Is that possible? Is ADFS able to understand where to redirect authentication requests to? (legacy\new forest)
        thanks again

        Manuele.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: