Office 365 Migration Exchange and an AD Forest Move Part 2

Welcome back to the second and final part in this series on Simultaneous Inter-Forest AD and Exchange to Office 365 Migrations.

If you haven’t yet read part one then please check out Office 365 Migration – Exchange and an AD Forest Move Part 1 now.

Simultaneous Inter-Forest AD and Exchange to Office 365 Strategy Options

When we left off we were about to explore the three scenarios or migration options open to us after discounting the Office 365 Hybrid set up due to reasons discussed in the previous post. Lets go over each scenario.

Option 1 – Federate from the New Forest, Migrate from the Old Forest, Office 365 will know its a shared namespace and non migrated users will get their mail on the server

This configuration was the scenario we would have liked to use. This is how it should work:

1. The newad.local Active Directory would be populated via ADMT User and Group migration processes from the oldad.local domain. Obviously there would be some clean up first.
2. The Office 365 Directory would be populated from the  users and mail enabled groups now residing in the newad.local Active Directory domain using Office 365 Dir Sync. Initially all the users listed in Office 365 would be unlicensed and would not have mailboxes.
3. We would set up a shared namespace in Office 365.
4. We would not at this point switch on Federation but we could have if we so wished.
5. We would then migrate our first email user, using the Exchange Migration tool within the ECP Admin panel – this is the only option available in this scenario other than exporting a mailbox to PST and editing the AD Target attribute and then importing the PST (which is what the ECP Exchange Admin Panel does in a friendly way).

Once the user is migrated we could assign the first Office 365 E3 license to them and they would be able to login and away they go. All the services would be available. Then it is just a case of rinse and repeat.

Unfortunately this is not quite the case. It is true that the user will have their mailbox working, they can receive email from external sources, they can send to external sources and they can email their own people still residing on the Exchange server. However, when you look at the Global Address List, there are no Distribution Groups and no users.

The problem is that if a mailbox is unlicensed on Office 365 then there is no way for it to show up in the Global Address List. That means that the global address list will be empty for your first user and as subsequent users come over the list will be built but it wont ever be complete until the final user is migrated.

The other issue with this scenario and all scenarios is that Free/Busy will not be supported across systems.

Now there is a work around to get Distribution Groups / Lists to show up in the GAL (link here) but you cannot get those pesky users to show up with licensing them (which is mail enabling them) and once you license them then anyone on the Office 365 side who emails a user with a license will have that email delivered to the Office 365 mailbox rather than the mailbox on the old server.

We hoped to use this scenario in a way where we would buy and deploy licenses as we needed them (rather than all at once) and we also wanted to avoid making unwanted workarounds and add steps to the migration.

For this customer it was unacceptable for the GAL to be empty and partially populated as the migration wore on. Not having free / busy was acceptable for a period of time so that part was fine.

Now if you were able to do your migration in a relatively short time, such as over a couple of days or weekend – so better for lighter mail users with small mailboxes or few users then you could probably tolerate the GAL situation. You could also workaround it with a set of Contacts that you manually delete as you use the corresponding user, but for any prolonged migration this isn’t going to work.

The reason  users weren’t appearing in the GAL (without a license) was due to the fact that their accounts on AD and therefore Office 365 were not mail enabled. Adding a license would (and does) mail enable a user. Therefore if we could get the user created with attributes form the oldad.local domain rather than the brand new clean newad.localthat doesn’t have Exchange Schema extensions then maybe that option will work better.

That is option 2.

Option 2 – 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 2 was a less desirable choice as it required more back end work and felt somewhat messy. The plan was as follows:

1. Set up the Dir Sync from the Old Forest so that it creates all the users and groups in Office 365 but this time because they are objects with mail attributes they would end up on Office 365 and appear in the GAL.  Really this part is exactly the same as if you had a single forest and Exchange 2003/2007 or 2010 and were doing a straight migration to Office 365. You could even use the Hybrid server at this point and it would also do the same thing.
2. Migrate users in a traditional staged format over a number of weeks.
3. We would not switch Federation on at this point but manually keep passwords synced. We could have switched it on, but as you will see from the next steps it felt a little over complicated.
4. Prior to the migration completing we would use ADMT to migrate all users and groups over to the newad.localActive Directory (we would also use ADMT to do workstations too but thats another story).
5. Once the migration was complete from a mail perspective, then we would tear down the DirSync from the oldad.local domain and set it up in the new forest so that newad.local would now DirSync. At this point we would also switch on Federation.
6. Before the sync would be started we would manually make sure that the user and groups that were originally synced from the old side matched and were exactly represent by the users and groups on the new side and recently brought over via ADMT. We would also make sure that the users User Principle Name (UPN) was the same on all three sides.
7. The final step would be to switch on Dir Sync on the new side, the objects would match up and we would be finished.

Unfortunately for us, the plan does not work and it will not work for you how ever hard you try. The initial part of the plan to get a populated GAL from the start of the process did work. Mail flow also worked for all test cases. Free / Busy as always is not supported to function but that was fine as we didn’t expect it to.

AD Dir Sync Issues

The issues start when you come to do your initial sync after moving the Dir Sync server from one forest to another (which is an entire article on its own) and get ready to start a new process.

What should happen is that the new Dir Sync process will start and the objects in the newAD.local will be matched to the pre-loaded mail enabled objects from the oldad.local via the UPN or primary SMTP address and everything should be merry. What actually happens is you start getting duplicate object errors emailed to you every time the process runs. There is no fix to this right now as the matching attribute (anchor) for the sync process is set in stone and it isn’t the UPN or SMTP address.

I checked in with Microsoft Consulting Services to ask if there was a way to “anchor” the process to a different attribute like the UPN or SMTP address but alas there is not. It is currently anchored by the Globally Unique Identifier (GUID) so an object in the old forest will obviously have a different GUID to the same object (even if migrated via ADMT) in the new forest.

There is no way to get around this but I understand there is a Forefront Identity Manager product for Office 365 that will allow different anchor attributes coming soon. For smaller customers the FIM product may be unhelpful anyway. Until then we are left with the third option and the one we have opted for on several occasions.

Option 3 – 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

The setup in this case is fairly similar to option 1. The main difference being that where I had hoped Office 365 would realize that if a User was not mail enabled and would just send the email out to the on premise Exchange server hosted mailbox that was yet to be migrated,  here we are accepting this is not the case and using a second mail domain to facilitate the function.

The actions to enable the configuration is described below:

1. Use ADMT to populate Users and Groups from the oldad.local into the newad.local Active Directory. It is important to be careful that the AD UPN might not equal the desired smtp address in some cases (this will require some clean up at migration time).
2. Set up DirSync and Federation from the newad.local to the Office 365 directory – this can take 24 hours or more to enable on Microsoft’s end so don’t leave this task until the last minute.
3. Buy a publicly accessible domain name as a secondary email address space for use during the migration (example mysecondnamespace.com). Once purchased point the MX record at your old Exchange environment. Add that SMTP namespace to your Exchange server so it will accept mail from that address and use Recipient Update Policy to create addresses for everyone locally.
4. Test the set up to be sure you can send emails. For example if a user, Ringo Starr, has an email of ringo.starr@mycompany.com they should now have also ringo.starr@mysecondnamespace.com and you should be able to send emails to both addresses with the same success. Don’t forget you may need to update your email spam filters and front AV setups.
5. Buy your licenses for your users and enable all the accounts so they now are mail enabled and operational.
6. Make sure that your Office 365 uses have the correct primary SMTP address and also if you need to add other alternate SMTP addresses follow the Adding secondary SMTP addresses to Office 365 in a Dir Sync environment.
7. For all Groups go through and mail enable them in your local Active Directory (article to follow).
8. Each mailbox now needs to be set up to forward email from Office 365 to the corresponding user on the Exchange server using the secondary mail domain you set up earlier (i.e.  mysecondnamespace.com) – this way when a migrated user wants to email a non migrated user they can pick the user from the GAL, the mail will go to the Office 365 mailbox and then forward out using the secondary namespace and get delivered to the un-migrated users mailbox on the local server.
9. You would then want to try and instigate some sort of freeze to minimize work during the migration process.
10. Finally as you migrate users over to the Office 365 (using the ECP based Migrate Mailbox tool) you will turn off the forwarder first then do the mailbox move and then reconnect up the users Outlook and other devices to the new Office 365 mailbox.
11. Now they can sign on anywhere using their newad.local account and it is a beautiful thing.

Concluding the Simultaneous Inter-Forest AD and Exchange to Office 365 Migration

Once all the users, shared resources, groups etc are moved over and you are happy that it is complete you can remove the pieces of your network that wont be needed anymore culminating in saying goodbye to your old Exchange server. Just don’t forget to do something with your public folders before you turn the server off and crush it!