Office 365 Migration Exchange and an AD Forest Move

Many of you may be considering moving your business email platform to Office 365 from perhaps Exchange 2003, Exchange 2007 or 2010. The process for these moves can become complex depending on the servers involved, the sites, mail domains etc. If you don’t have a “greenfield” install then you will choose between a staged, cutover or hybrid migration. More information on what each type can be found here, but in general they are fairly well documented and paths more well trodden.

What about an Active Directory Forest Migration simultaneously with an Exchange to Office 365 Migration?

There appears to be a lack of information for when an organization wants to migrate from their old Active Directory forest at the same time as moving from their old Exchange on premise set up to a new hosted Office 365 platform.

This article will hopefully show you in detail the options you have (few) and the things to avoid (many).

Simultaneous Inter-Forest AD and Exchange to Office 365 Migration Scenario

The scenario I am going to describet here has the following set up and is somewhat based on a few real situations. Names have of course been changed to protect the innocent. So here goes:

• We have an old Windows 2008 AD forest with a single domain we shall call oldad.local.
• An Exchange 2007 based organization that is part of the oldad.local forest and is in the same domain and for simplicity’s sake its a single server.
• There are multiple hundreds of users in a couple of locations, Public Folders are heavily utilized.
• The new Windows 2012 AD forest is also a single domain and is calledl newad.local.
• The users are all moving to the new domain, everyone is moving to Office 365 E3 plan so Office 2010 Pro Plus is being deployed to the desktop.
• Some users will be getting new PCs and some will be just moved over.
• The finished goal is to use Federation and Directory Synchronization (DirSync) with Office 365 from the new AD forest.

After having done a fair few migrations in my time and based on the size and budget available I knew we wanted to use the Active Directory Migration Tool (ADMT 3.2) to migrate users, groups, and PCs. An important requirement was the ability to use SIDHistory so that users could get back to resources in the old forest until the said resources finally get brought over to the new side which would be after the Office 365 migration.

ADMT and Windows 2012 Active Directory Issue

The first problem you will run into is that the current version of ADMT (3.2) does not support Windows 2012 and according to my sources there isn’t a version on the horizon yet. I am sure that will change soon, but if you want to use it today (late 2012 / early 2013) you will have to have a Windows Server 2008 R2 Domain Controller in your domain. Its a little frustrating.

However, it isn’t nearly as frustrating as installing  a Windows Server 2012 Domain Controller as the first Domain Controller in the Domain / Forest only to discover there is no ADMT support for Server 2012 (yes I know I should have checked…I assumed wrong). As you probably know, you cant add a Windows 2008 R2 domain controller into your domain for ADMT support because if you install 2012 first and then promote to be the first DC, the Forest and Domain Functional levels default to 2012. Thus you cannot add a 2008 R2 domain controller at a later date.

So make sure you build the new forest with the Windows Server 2008 R2 domain controller first, then add your 2012 domain controllers. Once you have finished the migration and no longer need ADMT you can demote the 2008R2 Domain Controller and remove it from the domain and then up the domain and forest functional levels to 2012 assuming you have zero reasons to keep it at 2008R2 levels.

Domain Trust and Other Prep Work

Once you have your new forest up with at least one domain controller you can do all the tasks that are required in readiness for the migration to make the old and the new communicate:

1. Ensure that DNS servers on both sides have conditional forwarders to the other side.
2. Ensure that you deploy DNS suffix search orders to all DNS clients so clients will append both oldad.local and newad.local to any queries.
3. Set up a two way trust between forests – no need to get fancy here, just make sure that you can permission things on either sides with groups from the opposite side as a test.
4. Put your newad.local Domain Admins in the Administrators Group on the oldad.local domain and on every member server and workstation – this is best performed by a nice Group Policy.

Now those are the main things to do but there could be many other areas to consider in your environment. Certificates for instance, but that’s another story.

Strategies for Exchange 2007 to Office 365 with an inter-forest migration

I thought carefully about the methods we could employ to get this job done. I knew I had some pre-requisites and also some items that would govern the solution and the migration.

First off, our end goal is to use AD Federation with Office 365. We are commonly implementing this solution due to the tidy nature of only have one username and password combo to remember for the end user. We like to couple that with an email UPN (for more on this click here) to make their life (and therefore ours) even easier. It can really reduce support calls and problems with Office 365.

Because we want to use Active Directory Federation that means we have to use Active Directory Directory Synchronization with Office 365 (DirSync) which handily means all our users and groups will be created for us without lots of typing or imports and exports.

One limiting factor we had which may affect you is the unknown nature of the mail environment we inherited for part of this example. To put it mildly it was in bad shape and the original administrators had no documentation or records on the environment. It wasn’t even being backed up when we arrived so we were loathe to touch it too much.

Hybrid, Cut Over or Staged Office 365 Migration

We didn’t have a need to support co-existence for a long period therefore the Office 365 hybrid migration technique didn’t particularly apply. I was also concerned by the method because it involved modifying the current Exchange environment and I was very unsure how it would perform if we had the Exchange organization and the hybrid server in one forest, the new users in another and the mailboxes and supporting users in Office 365. I felt that might not hang together and I was correct.

So the choice left to us was a cut-over or staged migration. The cut-over is just a very fast staged migration, as in do everything all in one go. That was too quick for us based on other moving parts of the project so a staged migration over a few weeks to a month fit better. For you this will be dependent on factors such as how long you can tolerate free/busy etc.

Therefore our 3 configurations options looked like this:

• Option A – DirSync and Federate from the new Forest, migrate mail boxes from the old Exchange server, Office 365 will know that it is a shared namespace for non migrated users and once complete we can remove the old Exchange and the old Forest.
• Option B – DirSync from the Old Forest, populate the objects so they have mail attributes in Office 365, do the migration, then at the end swap the DirSync to new Forest for everything to match together.
• Option C – DirSync and Federate from the new Forest, manually enable users in Office 365 and create forward rules for non-migrated users until everyone is migrated.

So due to the lack of documentation or information, we explored the options in depth and tried to make each one work. Option A was the most desirable and option C probably the least.

In part 2 of this post I will cover how the options panned out and which one we eventually went with plus the good news about a tool that will improve this in the future.

We are here to help! Give Squeeze a call on 949-287-4500 or email info@squeezetech.com