Luckily, there have only been a few moments in my life when I realized something went horribly wrong and I could not change it. Realizing the consequences, I could only muster the words “uh-oh.” Whether the issue was rebooting the wrong server and realizing that I actually rebooted a production SQL server or ordering the wrong takeout meal – uh-oh is never a positive thing to hear.
In preparing a migration to Office 365 many administrators take great care in making sure that all the necessary components are accounted for. The careful planning allows for all the latest and greatest features like Office 365 Groups to become beloved technology by end users within the enterprise. With all the great features available within Office 365 it becomes very easy to overlook the basic principals of successful migrations. Ignoring items lurking behind the scenes in an on-premises Active Directory infrastructure can lead to an “uh-oh” moment.
The past 18 years of delivering Exchange has afforded me the opportunity to be part of and witness many successful migrations. I’ve noticed that these successful migrations have all exhibited similar characteristics. The lessons learned from these projects can be broken down into three different success criteria.
First and foremost, all of these past projects spent a tremendous amount of time in the planning stage. It can be quite challenging with some projects to rope everyone in and understand what is a business requirement and what is a technical requirement. Management will need to provide clear justification of the project and highlight what the specific needs of the business are behind the migration. This allows the design team to ensure that the technical requirements and new features support the overall business requirements for the migration. Sometimes this phase can take much longer than executing the actual migration. This is not always the mentality or approach that the migration team may have.
Secondly, running through an initial discovery process of the as-built environment and supporting infrastructure is paramount to success. The reality is that the existing directory and messaging environment has probably survived through years and years of upgrades and mergers and acquisitions. Most enterprises do not completely understand what is floating around in their directory and messaging environment. Only by performing an initial discovery process will potential problems and migration blockers manifest themselves.
Mitigating any issues prior to launching the migration is the third success criterion. This activity is directly related to the initial discovery process that was run against the as-built environment. You may have a highly complex and tightly regulated Active Directory environment with numerous forests. If that is the case, you may need to perform some Active Directory and consolidation work prior to setting up and configuring directory synchronization with Azure Active Directory. In this instance, collapsing forests will require an understanding of how security identifiers and sIDHistory comes into play to maintain coexistence. If the environment is large then the use of sIDHistory may expose issues with max token size or token bloat. The more groups that a user is a member of the larger his or her access token becomes. This scenario can result in users sporadically not being able to access network resources.
Don’t let migration problems be the first time that you take a hard look at your on-premises Active Directory environment. By following the steps that I outlined you will position yourself well to avoid the moment during your migration project when all you can say is “uh-oh.”
If you have a good “uh-oh” story, tweet me at @ntexcellence.
Justin Harris is a Microsoft Certified Master on Exchange Server and a Microsoft MVP for Exchange Server. Justin is a Senior Solution Architect with Binary Tree where his primary responsibility is engaging with customers around their migration needs.