Microsoft Office365 Uncategorized

Even when you fully test, something still bites… #MailEnabled #PublicFolders can NDR after an #Office365 cutover migration

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 page
2. 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.

Microsoft Office365 Uncategorized

Office 365 mail enabling public folders #Office365 #MailEnabled #PublicFolders

I\’m about to publish details of a bug we encountered (and bypassed) with mail enabled public folders in Office 365, but thought a quick post on how it\’s done might be useful.

You can create the public folder in the Exchange interface and create the folders, but they will not be mail enabled until you do the following:

1. Enable the mail address (either by the GUI or through PowerShell)
2. Set the email address (either by the GUI or through PowerShell)
3. Disable the Address Policy
4. Most importantly (and only via PowerShell as far I can see), enable Anonymous users to Create Items in the folder (otherwise incoming emails cannot reside in the Public Folder).

The code to do this is straightforward, and turned into a script so that it is repeatable in the event of any changes in your plans (and also why do repetitive tasks in the GUI, when one script will do it all?!)

This line of PowerShell will enable Anonymous Create Item rights:
Get-PublicFolder “” | Add-PublicFolderClientPermission -User Anonymous -AccessRights “CreateItems\”

This line does the mail enabling, setting the address, and blocking Address Policy Enabling all in one go:
Set-MailPublicFolder \”” -EmailAddressPolicyEnabled $false -PrimarySmtpAddress “\”

Note that the full path to the public folder is the folder heirarchy so something like this for a folder 3 levels down a tree called \”Fred\”
“\\Root Folder Name\\Second Level Folder Level\\Fred”
and the Public Folder Name in this instance is just

So, if the fred PF alias was your two lines of code would be:
Get-PublicFolder “\\Root Folder Name\\Second Level Folder Level\\Fred” | Add-PublicFolderClientPermission -User Anonymous -AccessRights “CreateItems\”
Set-MailPublicFolder \”Fred” -EmailAddressPolicyEnabled $false -PrimarySmtpAddress “\”

My thanks to the following 2 blog entries for pointing the direction:
Exchangepedia Blog

NB. use the code at your own discretion and please note that this was done in a single Public Folder Mailbox environment.

Exchange 2010 Office365 Uncategorized

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.
  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