Active Directory design is never set in stone. Companies will build and active directory infrastructure that best suits their needs. In some cases, a single domain in a forest will meet their needs. In other cases, multiple domains or trees in the same forest does it for them or in extreme cases, multiple forests will be required, one to act as the resource forest where all services and applications are maintained and another for all user accounts and logins.
I had a client who has their Exchange 2010 organization hosted by a third party company. They had just under 1,000 mailboxes in the hosted environment running on a single exchange 2010 server SP2 with mailbox, client access and hub transport role. “@Abc.com” was the SMTP domain being used by the organization. In the corporate office, a different Active Directory forest existed (named XYZ.CORP) where all computer accounts and user accounts would log into.
Yes your assumptions are correct – every user had essentially 2 user accounts. One for logging onto their workstations and accessing network resources in the corporate office (email@example.com) and another one strictly for accessing their mailboxes in the hosted environment (Username@abc.local). Every morning, after logging on to their workstations, users would open Outlook and would re-authenticate with their abc.local credentials. All outlook profiles have been configured to use Outlook AnyWhere since there was no trust relationship between the two forests plus due to some limitations, a trust relationship could not be configured.
Out comes Office 365 and XYZ.CORP is ready to migrate all their mailboxes to the cloud. They have heard of single sign-on and would like to allow the cloud-based mailboxes to be accessed using their XYZ.CORP credentials. With no trust relationship, this was definitely going to be a challenge.
Contacted Microsoft for advice on this migration path but did not get anywhere – Microsoft’s recommendation was to do a forest consolidation first and then migrate to the cloud. Since we are not able to setup a trust relationship between the forest, this was proving to be almost an impossible task. Yes, we could use third party products but it would still require building a full exchange organization in the corporate forest, which was what my clients were trying to avoid.
Did my research and found the following article:
How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization (http://support.microsoft.com/kb/2641663).
This should work, right?! – RIGHT!
STEP 1 – Install Hybrid Exchange in Existing ABC.LOCAL Exchange Organization
- The first step was to install a new Exchange 2010 server running SP3 (minimum service pack level required for operations with Wave 15 of Office 365). This server was installed with the hub transport and client access roles only.
- Setup a hybrid configuration between Office 365 and the Exchange organization in abc.local – as part of the implementation, abc.com was added as a UPN suffix to the forest and configured as the UPN for all users in this domain
- Manage the hybrid configuration and have the wizard setup the settings along with the organization relationships
STEP 2 – Export Attributes from ABC.LOCAL mailboxes
- The second step is the most important for this type of migration. Export the following attributes from all the mailboxes in the organization:
- It must be noted that any users who do not have their email addresses automatically updated with the e-mail address policy will have issues. This is because after completing the first step above, the hybrid configuration will add a new SMTP domain of @O365Tenant.mail.onmicrosoft.com to the email address policy. This is added as an email address to all mailboxes for forwarding purposes. without this address, mailboxes will not migrate to the cloud.
- Once the attributes have been exported and saved in a CSV file, copy the file to a domain controller in the XYZ.CORP forest.
- Run Exchange Server 2010 SP3 Schema updates in the XYZ.CORP domain to create exchange attributes
- Import the values of the three attributes onto the user accounts in the XYZ.CORP domain. This can be done manually or using SET-QADUSER from Quest tools(http://ss64.com/ps/quest.html). Below is the script I used to perform the import after installing the Quest tools (Script available for download ImportScript):
STEP 3 – Configure Directory Synchronization in the XYZ.CORP domain
- Add a new domain suffix of ABC.COM to the domain. Change all user accounts to use the new UPN Suffix of ABC.COM – bulk modifications can be done using ADModify
- Now that all user accounts in the XYZ.CORP domain have been populated with Exchange attributes, directory synchronization can be setup. Install a new server running the directory synchronization tool in the XYZ.CORP domain
- Configure DirSync to synchronize either based on OU or filter based on Attributes. For my client, all user accounts were created in one OU so we used OU based filtering for DirSync
- Before Synchronizing make sure all user accounts have been updated with the new UPN suffix. Run a directory synchronization to start it off. DirSync runs every 3 hours by default but it can be customized.
You can also start directory synchronization manually. To manually force the synchronization, log into the Directory Synchronization server. Open up PowerShell and change directories to C:\Program Files\Microsoft Online Directory Sync. Then start the Directory Sync Configuration Shell by typing.\DirSyncConfigShell.psc1. This will launch the Directory Synchronization Configuration Shell. Once this is open you can type Start-OnlineCoexistenceSync to force synchronization.
STEP 4 – Configure Single Sign-On
Install ADFS and /or ADFS Proxy in the XYZ.CORP domain. This will allow for single sign-on between the mailboxes in the cloud and the user accounts in the XYZ.CORP domain.
STEP 5 – Migrate Mailbox from ABC.LOCAL domain
Run the remote mailbox move request wizard to begin the migration of mailbox data to the cloud. The migration tool will compare the mailbox GUID and email addresses to make sure they match before it begins the migration. Once completed, users will be able to log in with their XYZ.CORP credentials in either of the following formats: