Interesting migration issue with Office 365

We’re currently running a migration to Office 365 from an internal Exchange environment.  Rather than use directory synchronisation or go to a Single Sign On environment (SSO), this is a 1 time migration to the new O365 world.

The idea was that instead of “polluting” the new world with rubbish legacy information/setup created over probably 15 years operation since Exchange 2000 days (through 2003, 2007 and 2010); as well as have an impact on the internal setup/migrating by configuring a hybrid setup we would go for a  new setup that we knew would be fresh.

Fortunately (or possibly not, depending on your point of view!) we had an email domain fully registered and configured, but not used in real life (it was just to protect against misuse by someone else). We decided to add that to the O365 world and get a fully working setup, and then we could just add the other "real-life" domains to it to complete the migration.

To set up the O365 trial we did a number of things:

• Removed the SMTP domain from within Exchange setup (and from the message hygiene service we used)
• Added it to the O365 trial account
• Created our mailboxes in O365 and had everything working OK.
• By now we had removed the aliases in place on the internal exchange system user mailboxes (note: user mailboxes!) for the new domain.  Everything was going swimmingly.

It was at this point 3 further things needed to be tested on O365 before “signing off” that all was good for the 1-time transfer over and migration of data.

• Mail Enabled Public Folders for List Server subscriptions
• Use of O365 for automatically mailing of messages from devices and services
• Use of O365 Shared Mailboxes for accounts such as Admin, Webmaster, Postmaster and so on to cover off public required (or sensible) aliases without using an O365 licence.

The first two were sorted quite quickly using publicly available information (although watch out for mail enabled Public Folders needing anonymous “Create” rights to enable mail to be delivered).

But the last was proving a right PITA.  I had created a Shared Mailbox for the webmaster and whenever I added it to my O365 mailbox my outlook account would constantly prompt for my password to connect.

Eventually (after deleting and recreating profiles, deleting the contents of the Outlook folder (OST and so on) in my home directory, and deleted windows credentials through the control panel); I put in a support call.

Before getting the call and whilst away at a Microsoft IT Camp, I recreated the shared mailbox and found that on my Surface the profile worked fine.  So it was machine specific…

Raj called and we tried a number of things (no caching, new profile, delete the profile from the registry) and so on.  Then we spotted something.  In the depths of the profile registry entries I spotted a reference not (as in the image below) to the ExchangeLabs O365 folders, but to my internal exchange server

Raj agreed this was something to work on, and he came up very quickly with a fix.  The creation of a registry key in AutoDiscover to prevent SCP lookup on the network.  This would prevent the outlook client from searching through our network for a resolution of the webmaster shared mailbox identity and location.

We deleted and recreated the profile, logged in and it all worked.  Hurrah.

As a final test I sent an email from my phone (connected over 3G, not the internal network) and found that my email did not hit the shared mailbox, but when Raj sent a test email, it worked.  Hmm....  This was a further clue as to why SCP lookup was causing the problem.

A quick look at the Exchange Console (I say quick, but given I had Microsoft support on the line it took a bloody age to load!); and I discovered that the webmaster@ alias was still registered on the administrator mailbox.  So, what had been happening is that the SCP lookup in the profile creation when I started outlook was finding the alias in my network, and thereby causing a conflict with the O365 provisioned shared mailbox with the same email alias.

Remediation was then straightforward:

• delete the now unused smtp alias (and a few others I found) for the domain now on O365 from recipients on the internal network (there were a few admin like accounts that still had them)
• regenerate the Offline Address Book
• allow the OAB to distribute
• remove the ExcludeSCPLookup key from AutoDiscover
• test again

And all was well.

Lessons?

1. Don’t assume a completely standalone move, even with unused domains, to O365 will go smoothly :-) - just because it’s completely separate
2. If you have unused domain names on your exchange infrastructure then do check carefully whether aliases have been created for them
3. If you have (for legitimate reasons like us, or not) disabled automatic address generation on mailboxes, then you really need to take some care over legacy SMTP aliases on mailboxes  (the PowerShell code listing later on will help you find them - run on an exchange server and look at the output file - the location of which is coded at the end of the PowerShell)
4. Microsoft O365 tech support are good.  It was nice to prove that before we committed over to the service.

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,ServerName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\smtp.csv -NoTypeInformation