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.

DirSync and Distribution Group Self Service Management

If you’re an Office 365 Exchange Online customer and currently utilizing Directory Synchronization (DirSync) to synchronize between an on premise Active Directory and the Azure Active Directory you’ll be all too familiar with the limitations that are imposed around the management of distribution group membership. Namely an Exchange online user specified as the owner of a distribution group will not be able to manage the membership of that group through the standard Outlook Address Book interface as detailed here

In the background, if we think about this in relation to DirSync functionality, the group is being pushed from the on premise Active Directory to the Azure Active Directory in a one way sync. Consequently the group object in the Azure Active Directory is read-only which explains the limitations that exist around group modification.

As distribution group self-service functionality has been in place for quite some time in the Exchange landscape, it often comes as a significant blow to businesses when they realize this functionality isn’t available by default in Exchange online. The net result is either an accepted loss of functionality or the prospect of a significant increase in calls to the helpdesk to facilitate the modification of group membership from the on premise Active Directory.

There are however a variety of ways to work around this issue, this is by no means an exhaustive list but gives some guidance/ideas around what’s possible;

Use the ‘Find Users, Contacts and Groups’ tool to allow group modification

For domain connected computers it is possible to run the following command to fire up the built in ‘Find Users, Contacts and Groups’ tool;

%systemroot%\system32\rundll32.exe dsquery.dll,OpenQueryWindow

This will allow an on premise Active Directory group to be searched for and modified by an end user which will in turn be synchronized back up to the Azure Active Directory via DirSync.

Pros

  • No changes required to the Exchange/Office 365 configuration
  • The source of authority for all directory information remains on premise

Cons

  • Only works from domain connected machines
  • Represents a change to the existing manner in which distribution group objects are currently modified using the Outlook Address Book interface.

Move the Distribution Group Objects to the Azure Active Directory

It is possible to delete distribution groups from the on premise Active Directory and recreate them in the Azure Active Directory. By doing so the groups created in the Azure AD are writable and can consequently be modified using the standard Outlook Address Book functionality from an Exchange online mailbox user.

Pros

  • Allows Distribution Group membership to be modified using the existing Outlook Address Book functionality and consequently means zero change to the way end users are used to working.

Cons

  • Requires Distribution Group objects to be moved to the Azure Active Directory. This involves both a level of change, risk and impact which I will touch upon in the points of consideration section below.
  • Requires a change in the way that groups are managed moving forward, namely security groups are managed in the on premise Active Directory and Distribution Groups are managed in the Azure Active Directory.

Points of Consideration

  • In a typical Dirsync deployment the source of authority for all directory information is on-prem. If distribution groups are moved to the Azure Active Directory, source of authority is split between the on premise Active Directory and Azure Active Directory. Whilst this isn’t necessary a negative aspect of this option, it is a worthy point of consideration, least of all because administration of groups will now be performed in both locations.
  • Consideration needs to be given to the implementation timing of this option. Whilst deleting and recreating distribution groups is a relatively straight forward change which can easily be scripted using Powershell, there’s likely to be a period, albeit potentially small between when the on premise group is deleted and recreated in the Azure Active Directory. During this time any email addressed to the group will obviously NDR. This can potentially be mitigated if your organization use a third party solution for AV/AS which can be used to hold inbound email for a short period until distribution groups have been recreated in the Azure Active Directory.
  • Consideration needs to be given as to when during the migration that Distribution Groups are moved. Typically this should be performed at the end of a migration after all mailboxes have been migrated to Exchange Online. Obviously any remaining on premise Exchange mailbox users will no longer be able to see/utilize distribution groups once they have been deleted/recreated in the Azure Active Directory.
  • Changes made to the Azure Active Directory are throttled by Microsoft which could potentially impact the speed at which distribution groups can be created. Whilst it is possible to request Microsoft to amend the throttle policy this is still likely to be a factor.

Use a ForeFront Identity Manager Management Agent for Office 365 to synchronize Distribution Groups

Use the FIM MA for Office 365 to manage the provisioning and synchronization of groups between the on premise Active Directory and the Azure Active Directory.

Pros

  • Allows Distribution Group membership to be modified using the existing Outlook Address Book functionality and consequently means zero change to the way end users are used to working.

Cons

  • Requires a FIM sync engine license
  • Involves a level of complexity regarding the implementation and management of FIM

Summary

The option you choose here is very much dependent on your organizations requirements and each option carries with it a different set of pros and cons. In scenarios where an organization want to retain the standard self-service functionality provided by the Outlook Address Book, the second option provides a good balance of functionality and low cost of implementation/management moving forward. The points of consideration for this option should however be carefully considered prior to any attempt at implementation.

 

 

 

Removing an Exchange Hybrid Configuration

I was recently working with a customer who were performing an organization led de-merger, for the purposes of this blog entry lets refer to them as ‘CompanyA’ and ‘CompanyB’.  Prior to the de-merger CompanyA hosted an on premise Exchange 2013 environment that both CompanyA and CompanyB utilized for the purposes of mailbox/public folder hosting. At the point of the de-merger, CompanyA were going to retain their existing Exchange environment and CompanyB were planning to move to O365.

Due to the size and complexity of CompanyB, Exchange Hybrid was used as a mechanism to facilitate the migration of CompanyBs mailboxes and public folders to Office 365.  Following on from the migration there was obviously a desire to remove the Exchange hybrid configuration to sever ties between both organisations.

When faced with this challenge, it became apparently that there wasn’t a great deal of information available around how to smoothly remove an hybrid configuration from an Exchange organisation, whilst MS walk through the process in the following technet blog entry the order in which MS suggest performing the steps required wasn’t actually possible and resulted in a number of errors.  I therefore wanted to provide some clarity around the process/ordering.  This process covers hybrid configurations in both Exchange 2010 and Exchange 2013.

Firstly I assume the following activities have already been completed;

  • All required mailboxes have been migrated off of the on-premise environment across to Office 365
  • If necessary all public folder content has been migrated across to Office 365, either to shared mailboxes or traditional public folders.
  • All Exchange related DNS entries (autodiscover,OWA etc) have been re-pointed to O365
  • All MX records for SMTP domains that are being managed by O365 have been re-pointed to O365

Once these activities have been completed we can start on the steps required to remove the hybrid config;

  1. Remove the organizational relationship from the on-premise environment as follows; ‘Remove-OrganizationalRelationship -identity “name_of_org_relationship”.  The identity of the organizational relationship can be obtained by using the ‘Get-OrganizationalRelationship’ if required.
  2. Remove the organizational relationship from the O365 tenant as follows; ‘Remove-OrganizationalRelationship -identity “name of_org_relationship”, Again the identity of the organizational relationship can be obtained by using the ‘Get-OrganizationalRelationship’ if required.
  3. Remove the federated domain(s) from the on-premise environment as follows; ‘Remove-FederatedDomain -domainname name_of_domain
  4. Remove the Email Address Policy/Policies associated with those SMTP domains that have been moved to O365.  This can simply be performed from on the on-premise Exchange admin console
  5. Remove the Accepted Domain entries from the on-premise Exchange admin console for those SMTP domains that have been moved to O365.  Again this can simply be performed from on the on-premise Exchange admin console.
  6. Remove the federation trust from the on-premise Exchange environment as follows; ‘Remove-FederationTrust -Identity “Microsoft Federation Gateway” By default the hybrid configuration wizard in Exchange 2010/2013 names the federation trust “Microsoft Federation Gateway”.
  7. Remove the remote domain associated with the Exchange hybrid configuration using the on-premise Exchange Admin Console.  This will be named something like “Hybrid Domain – tenant_name.mail.onmicrosoft.com”
  8. Remove the SMTP send connector from the on-premise environment as follows; ‘Remove-SendConnector “Connector_Name”‘
  9. Remove the inbound and outbound SMTP connectors that were created by the hybrid configuration wizard in the Exchange Online Protection Administration Console
  10. Finally remove the HybridConfiguration object from within Active Directory.  This isn’t supported in Exchange 2010 and its perfectly fine to leave the object in AD without any adverse effects.  If however Exchange 2013 is being used in the hybrid configuration, the following PS command can be used to remove the HybridConfiguration object;  Remove-HybridConfiguration

 

Once those steps are complete, all references to the previous hybrid configuration are removed leaving two separate and distinct Exchange environments, CompanyA on-premise and CompanyB in O365.