The office 365 “big bang” cutover migration took place over
the weekend. Testing had proven
everything we wanted to see, and - apart from the logistics of transferring GB’s
email up a 3Mb down/710Kb up ADSL connection (it’s measured in days if you want
to know!) - all went as planned.
And then we noticed incoming emails to some mail enabled public
folders were not working. Some desperate
testing (including borrowed external accounts) proved that internally all email to
Mail Enabled public folders worked; but that some of these public folders were
receving external email, some not.
At which point the tech support incident was created. Thankfully, within 90 minutes the problem
was solved and the incident closed. Again, nice one Office 365 support.
The lesson though. It
seems Microsoft have a bit of a bug in the system for newly migrated domains in
a cutover migration; in that email addresses may not function for externally sent email and cause the
sender to get a 5.4.1 NDR:
But didn’t I test this?
Yes, I did. However the testing
was done on a spare domain that was handed over to the Office 365 over a month
ago. So by the time I was testing the Mail
Enabled Public Folder function, they all worked. It seems the sequence that can create the problem
is to add and authenticate the domain during the cutover (but that’s how you
have to do it).
The explanation.
It seems that in a cutover migration when you add further
SMTP domain aliases to Office 365, it is possible for the data not to propagate
around the entire O365 world quickly enough.
The net effect is that when an external party emails that public folder,
the address goes unrecognised and the message NDR’s.
But, there is a fix, whizz over to the office 365 portal and
take the following steps
1. Go to the admin page2. At the bottom, go to Exchange admin
3. Click on Mail Flow down the left hand side and select accepted domains across the top to get to here (domain names hidden to protect the innocent!)
4. Now double click on the domain in question and
change it from Authoritative to Internal Relay, and accept the prompt that
comes up and save this (see below).
5. The net effect is that when your sender’s email hits
the office 365 setup, it will (instead of NDR’ing as an unknown alias) pass on the
email through the environment until it reaches your public folder. Internal Relay forces the server accepting the incoming email to assume that if it does not know the addressee, another server will, so it works it way through. In authoritative mode it will just NDR the email immediately.
The advice Microsoft support gave was that this setup could be
left on internal relay indefinitely, but if you give it a few days (well, a
week), then you could move it back to authoritative, but feel free to leave it
on internal relay.
Although it wasn’t stated, I suspect the propogation issue is one related to mail enabled public folders and not mailbox or shared mailbox aliases, but I have no evidence for htat.
In hindsight I might have been able to create all the aliases
on the new domains in the Office 365 setup but that would have hampered testing
in that during testing we could send and receive email between the live
setup and office 365 testing world. I don’t
think I would want to have given that up.
But, my recommendation? Unless there is a good reason for not doing so, setup up your domains as internal relay before, during and for a few weeks after your cutover migration.
But, my recommendation? Unless there is a good reason for not doing so, setup up your domains as internal relay before, during and for a few weeks after your cutover migration.
Posts
