Solving issues when migrating away from Telstra’s Office 365 to Office 365 via CSP

I ran a small migration on Friday last week that took a lot longer than planned due to a few unexpected issues. The customer was migrating away from Telstra’s Office 365 service (AKA syndicated account) to a Microsoft Office 365 account licensed via the CSP model.

This is a pretty standard migration that we run often, though this time I ran into a number of issues.

Since it was a small migration (4 users), and it needed to be moved over in a short amount of time, I opted to do a standard PST migration on an Azure VM. The plan was as follows:

1. Disconnect the domain from the existing tenant
2. Add it to the new tenant by moving it to new name servers and verifying the DNS
3. Create the required users on the new tenant
4. Set up the Exchange accounts for the old users via their .onmicrosoft.com addresses and export the mail via PSTs
5. Set up the Exchange accounts for the new users and import the mail

Here’s a few important details regarding the source tenant:

• Office 365 licensed via Telstra on a syndicated account
• Domain DNS hosted on Microsoft’s name servers

Here are some important details regarding the destination tenant:

• Office 365 licensed via CSP model
• Domain DNS hosted on external name servers

Problem #1: Cannot create a user with the same UPN as before

My first issue occurred when I started to set up the users on the new tenant. Three out of four worked correctly, though the fourth mailbox (unfortunately the most important one) would not create correctly on the new tenant.

I was given the error OrgIdMailboxRecentlyCreatedException and the message:

Hang on, we’re not quite ready

It looks like your account [email protected] was created 1 hour ago. It can take up to 24 hours to set up a mailbox.

I did some testing and discovered that the error message only appears when I set the User Principal Name to match what it was on the old tenant ([email protected]). If I set it up to use a variation of the old name ([email protected]), it worked instantly.

I suspected this was to do with some internal updating issue with how Office 365 maps usernames to mailboxes, and decided to give it a bit of time.

In the meantime, the customer needed to be able to send and receive as their previous email address. So I logged onto Exchange via Powershell and ran the following cmdlets:

set-mailbox paulm -windowsemailaddress [email protected]

set-mailbox paulm -emailaddresses [email protected], [email protected]

These cmdlets keep the user principal name as [email protected] though allow the user to send and receive mail as [email protected].

Once this was confirmed working, I set it up on the user’s Outlook profile and kicked off the migration.

I left this running overnight, and in the morning faced a new problem.

Problem #2: Cannot send to BigPond addresses due to SPF issue

The next issue was related to recipients using Telstra BigPond addresses. Emails sent to external domains worked fine, though emails sent to BigPond account would fail instantly. They’d return a message stating that the message was rejected by the recipient email server.

The error message was <[email protected]> Sender rejected. IB506

The SPF Headers in the returned email state that there is no SPF records configured for the domain:

I double checked the SPF records on the new name servers and they were configured correctly. I also sent test emails to my own external addresses, and the SPF headers were fine too.

I’m not 100% sure what the cause of the issue here is, though I suspect it is due to the fact that Microsoft used to manage the DNS for this domain via their internal Office 365 name servers. If the change is taking a while to propagate throughout the system, it may still looking at their internal name servers for records relating to this domain.

Solution: Switch Name Servers back to Microsoft

To resolve this issue, I transferred management of the DNS records back to Microsoft’s Office 365 name servers, and within about half an hour, all of the issues were resolved.

I was able to rename the user to the correct email ([email protected]) and users no longer had issues mailing BigPond accounts.

Since I was trying everything to resolve this issue, I’m not sure what the ultimate fix was. Though it seems that switching the name servers back to Microsoft on the new tenant did the most good.

I suspect that this was a DNS propagation problem within Office 365, and may have been resolved in time anyway. If you’re currently experiencing it, moving the DNS to Microsoft’s Office 365 name servers may speed up the resolution.