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?
- Don’t assume a completely standalone move, even with unused domains, to O365 will go smoothly :-) - just because it’s completely separate
- If you have unused domain names on your exchange infrastructure then do check carefully whether aliases have been created for them
- 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)
- 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