Office 365 Migration–Notes from a newbie. Or Killer Mistakes I made.

I have just completed a migration from On Premises Exchange 2007, to Exchange Online. Despite what i thought was a pretty well prepared migration, i was gotchad at least four times, the last time actually needed Microsoft Escalation Support, when in actual fact  a slight change to documentation and me reading a littler clearer would have solved the four days troubleshooting we did.

The environment, was a two site Windows 2008 Domain, with two Exchange 2007 Servers (on 2008×64 Standard). 155 Users, which would go into a mixture of E1 and E2 plans.

Tips for DirSync

So firstly, i opted for DirSync because it would easily create my Users and Groups in Exchange Online for me, as well as provide Password Sync, which is a big help for migrations like this.

• Install DirSync
• Password Sync
• Trigger Full Password Sync
• OU Filtering with DirSync

Remember, Your On Premises Domain Password Policy, must have a minimum of 8 character requirement or Password Sync will not work. Plan ahead if you will need users to reset passwords.

To edit your DirSync Configuration, you need to run ForeFront Identity Manager, to find this application:

C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\MIISClient.exe

When you use DirSync you cannot do some things to users from the online portal. You must do them at the On Premises Servers, and let it Sync those changes.

 

Tips for Users and Groups

The biggest thing that slowed me down with Users and Groups, was Groups not syncing to Exchange Online. This, i found, is due to missing attributes on the groups themselves. The most common of which, was a missing Display Name, or missing SMTP ProxyAddress.

Great KB Article on that here, and also look out for the ‘Metaverse Search’ in the DirSync tool because that is also helpful to find objects that are not syncing.

When you work with Users in Office365 PowerShell, you will always need to refer to the UserPrincipalName (UPN). So we took the step to make all internal UPNs match the users email address.

This would be done on your On Premises Server, prior to the migration starting, but it can be done later if you want to.

Licensing your users. This was another instance where a knowledge of PowerShell was crucial. Having generated a CSV file of users which would be included into the migration project, the client marked off whether someone would have an E1 or E2 license. Once i had that, it took seconds to apply licenses to the full 155 users.

How did i do it?

I don’t want to go into a full explanation of how PowerShell works with CSV files, however, a brief outline should do.

As you can see from my above CSV, i have several fields, User, UPN, and SKU. Self explanatory.

(by the way NotePad++ is excellent for working with CSV files, i found it better than Excel a lot of the time)

So now i have this CSV File generated we can work to assign licenses. There is a lot of information about this online already, so i wont cover the details, if you are new to Office 365 PowerShell i would recommend you get a copy of this book.

Using the 365 PowerShell Tools you can get your License SKUs, which are a mixture of your OrgID and the relevant product.

I also found i had to set a Usage Location on the users before i could assign a License. In addition, we also set the Users ‘Department’ Attribute to match the SKU that user would have applied.

TechNet Magazine : Office 365 PowerShell

 

Tips for Email Migration

My previous experience of migrations, certainly of migrating data, has been that it is a good idea to pre-seed a large data copy, so that only changes are sync’d at the final switch over.

It was a big mistake to bring that process into this project.

When you use DirSync, mailboxes must be migrated using ‘batches’. Depending on the On Premises Exchange environment you may have multiple options, but coming from 2007 our choice was essentially, using a CSV File.

I read up on the documentation, created my CSV file, and set a test batch off. Noticing no ill effects, i did another batch for the remaining users. After about 4 hours i had a call to say no new email was coming in to the On Premises Servers.

What i failed to notice, or read on that TechNet page, is that once a batch begins, it sets an Attribute on your Users and Groups to forward all new mail straight to 365. At this point we were not ready to switch over, and so i had to kill the Batch Migration, to stop the mail flowing to 365. Wrong again!

Simply stopping a Batch Migration, will not revert that TargetAddress attribute. You need to use ADSIEdit. Well, forget doing that for 155 Users.

PowerShell to the rescue again. The real headache was then trying to get that 4 hours worth of email out of 365 and back into the On Premises mailboxes.

In the end we found the only way to do it was with MessageOps 365 Exchange Migrator. (Which we did pay for)

This allowed us to export the Exchange Online mailboxes to PST, and then we used PowerShell to import them back into each users On Premises mailbox.

This approach could have worked, if i had known about the TargetAddress setting, and if i had closed port 25 on the Exchange 2007 servers before hand. Using that method you could easily schedule migration batches to work out of hours for a week or so leading up to your cut over date.

 

Infrastructure Notes

I made no changes to public DNS aside from getting the clients public domain name assigned to their account. It remained in the ‘setup in progress’ state until after the migration cutover of users had been completed.

Internally i made no changes, i had been concerned about the internal AutoDiscover process affecting Outlook, however it is quite easy to get around that with a Group Policy, which i will cover below.

We made all the changes to Public DNS after the final mailbox batch was started.

 

Client Computers and Devices

A major headache i had was, how am i going to reconfigure 155 Users Outlooks? Luckily only about half of the people were Office based, and even less than that actually used Outlook. The remainder of staff were using webmail or a mobile device.

I contacted an Exchange MVP friend of mine, who suggested i use MessageOps Config365.exe. This great utility is provided free (although i don’t know if it is supposed to be used by non MessageOps clients).

I distributed a flyer to the clients staff in order to assist, but on reflection it could have been clearer.

It very easily reconfigures a users outlook to point to Office 365 and will set the client to use a Local XML file for AutoDiscover. It will even bring in a users pre-existing PST files.

If you want to use a GPO to control AutoDiscover this is a great guide.

Mobile Devices proved to be a sticking point as well, primarily because i did not have an Android device to work from., while 99% of the clients staff were provided with an Android device.

I provided some basic steps based on an Android Emulator i run on my Desktop, but these were really not fit for purpose.

For a seamless transition, you will need clear instructions for your users that explain that EAS Accounts must be deleted from a device, then the new account added back, and that this process will not cause them to loose email, and that they must know their username and password before they begin.

For webmail the process was relatively harmless, but for those only using Exchange Online, note that you should not direct users to the Online Portal, but directly to https://outlook.office365.com

 

Public Folders

We had some 200mb of Folders to migrate, a totally ridiculously small size. You might be forgiven for simply using a PST export / import. This is not recommended by Microsoft if you have more than 30gb of data.

This is the guide i was following, although i did not read clearly enough.

Firstly i had 2 Exchange 2007 Servers, that were not on SP3. This held me up because i was getting odd errors when attempting to run the New-PublicFolderMigrationRequest command.

After updating the primary server to SP3 (RU10), the process proceeded quite smoothly, until the migration got to around 90% of copying then failed, with a ‘StalledDueToMailboxLock’ message. I tried all kinds of troubleshooting, nothing would get me past this message. It turns out this is a generic error message, and often does not mean what it says.

After working with Microsoft Escalation Support, i would make the following changes.

Ensure ALL Servers in your Exchange environment meet the requirements, (SP3 RU10) you can check that with this command:

You can also use this earlier post to find the info, and this wiki post to compare your results.

Next, on step 5 of the TechNet Article, you should append the –BadItemLimit parameter. The article does not mention this, but not using this caused my migration to fail, as you would expect, when Bad Items are encountered.

New-PublicFolderMigrationRequest -OutlookAnywhereHostName: $source_OutlookAnywhereExternalHostName -CSVData (Get-Content <folder_mapping.csv> -Encoding Byte) -RemoteCredential: $source_credential -RemoteMailboxLegacyDN: $source_remoteMailboxLegacyDN -RemoteMailboxServerLegacyDN: $source_remotePublicFolderServerLegacyDN -AuthenticationMethod Basic –BadItemLimit 100

I would also recommend you enter the settings from Step 5.3 into PowerShell ISE or notepad, to save you continually retyping it.

Whilst we are mentioning that,  i actually keep a file with all the commands for connecting to Office 365 PowerShell to save me typing them.

Using the tip i picked up here you can actually store an encrypted string of your password, to save you even having to enter your credentials.

I also wrote a small Do Loop, to give me a progress update on the copying. Because it was continually failing i wanted to know asap so i could amend and try again.

It was very useful to leave that running and have it auto refresh every 10 seconds.

Even with these steps, i still had to reboot the On Premises Exchange Servers several times, to get the Migration to complete. However it was, finally, a success.

You will see a lot of troubleshooting guides, telling you to try ‘Resume-PublicFolderMigrationRequest’ However, from my own experience i would argue that this command does not do, what people think it does, and is designed for use only when the Migration request has reached ‘AutoSuspend’ or when it has been manually Suspended.

That should be enough tips to keep you going, and hopefully avoid some of the killer mistakes i made.

Thanks to all the people who created the blog posts and articles i linked to, thanks to MessageOps for their great tools and most of all thanks to me.

Special Thanks to Tim Barrett, without who, this article would have no skulls.