As a technology consultant with a heavy focus in the last few years on Office 365 implementations, it seems like most of the “low-hanging fruit” is gone. It is becoming less common to encounter clients with a single Active Directory forest/single Exchange organization that want a straightforward, plain vanilla move to Exchange Online. Now we are left with the more difficult hybrid organizations that are the byproduct of mergers and acquisitions, i.e., multiple forests/multiple Exchange organizations that want to consolidate into a single Office 365 tenant. This blog post is the first in a series about overcoming the unique obstacles and challenges Office 365 implementers face when migrating clients who have disparate identity management and messaging platforms due to mergers or acquisitions.
In the case of my most recent engagement, the client (Company A) recently merged with another company (Company B). Company A already occupied an Office 365 tenant and recently moved all of their users’ mailboxes to Exchange Online. They were still in a hybrid configuration as distribution groups and some other mailboxes were still being managed in Exchange on-premises. Company B was still completely on-premises with Exchange Server 2010. The client’s desired future state was a unified identity management and messaging platform, meaning a single Active Directory forest and all Exchange services consolidated into the existing Exchange Online in Company A’s Office 365 tenant. That is much easier said than done.
Moving to a New Forest
Step one of this process was Active Directory forest consolidation. Both Company A and Company B had things they did not like about their Active Directory environments. Senior management also wanted a new unified brand name to be reflected in the Active Directory domain name. Consequently, we developed a strategy to migrate the two single forest/single domain environments into a new forest in a single domain I’ll call NewCo.biz.
Cross-Forest Trust Name Resolution Challenges
Building a new greenfield Active Directory forest and domain is easy enough once you get all of the stakeholders to agree on the new OU structure and Group Policy strategy. The implementation gets more challenging when you start building trusts between the three domains. I subscribe to the old axiom “When Active Directory is not working check DNS, failing that, check DNS again.” Conditional DNS forwarders for the partner forest’s namespace are typically all that is required to get name resolution working between the two environments. In this case, name resolution between the two forests was intermittently slow and sometimes led to authentication failures. Performing packet captures to diagnose the problem yielded these results:
Company A still had an Active Directory site called Default-First-Site-Name while Company B had renamed theirs. What did not make any sense was that Company A computers were sending Company B DNS servers SRV record lookups for _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.companyb.local. Those queries returned a query response of “No such name” because that site did not exist on the Company B side. After doing some research I learned from reading this TechNet blog post that trusting domains attempt to locate the closest counterpart domain controller by performing site-specific DNS queries. In my captures I was seeing that the first DNS query for a domain controller in another forest will look for a domain controller in a site that matches the client’s site in its own forest. If that query fails, then it falls back to non-site specific queries, which assume connectivity between all sites in both forests. In this scenario, Company A and Company B did not have full mesh connectivity between all of their sites so authentication would fail depending on which site’s domain controller was returned.
My investigation also turned up this Active Directory Team blog post, which described how to fool the DC locator service by creating placeholder sites in Active Directory Sites and Services to mimic the partner forest’s site configuration and facilitate cross-forest site-specific DNS queries. That made perfect sense to me except that I did not like the idea of cluttering up AD Sites and Services and possibly creating confusion for other admins. So I improvised on this strategy a little and just created placeholder site-specific DNS SRV records instead.
The end result was the same as creating placeholder sites: site-specific cross-forest queries were receiving valid responses and name resolution/authentication began working consistently across the trust.
Universal Principal Names: You Can’t Take Them With You
The next issue we faced involved Universal Principal Names (UPN) and name suffix routing across the trust. Company A had gone to considerable lengths to make users’ UPNs match their e-mail addresses in order to make signing into Office 365 more intuitive. They had a dozen e-mail domains and matching UPN suffixes such as constoso.com and nwtraders.com in Active Directory. The bad news was those UPN suffixes could not exist in the Company A forest and the NewCo forest at the same time. We tried it and name suffix routing across the trust quit working completely. When I looked at the Name Suffix Routing tab under the trust’s properties in Active Directory Domains and Trusts, all of the name suffixes showed “disabled” under routing and “conflicting” under status.
Company A was also too large to migrate all users sharing an e-mail domain at the same time and preserve users’ UPNs. That meant every user who migrated to the NewCo forest would have to receive a new UPN suffix like NewCo.biz. This change necessitated a larger educational messaging effort prior to the migration to help users understand that how they log into Office 365 would change. For the migration team, this meant we had to figure out how to change an existing Office 365 user’s UPN and anchor it to a new user account in a different forest without breaking their identity in the cloud. That will be the topic of the next post in this series.
Do you want to explore options for moving your organization to Office 365? Credera has extensive experience in designing, planning, and implementing cloud solutions. If you have questions about this blog post, points of view, or IT infrastructure, please leave a comment below, tweet us @CrederaIT, or contact us online.