Solution: Unable to update Active Directory information for the source mailbox at the end of the move

This scenario applies to hybrid configurations when moving mailboxes from on-premises to Office 365.

Whenever you see the error in the migration log that says “Unable to update Active Directory information for the source mailbox at the end of the move” it means that when the mailbox move completed, MRS could not disable the mailbox on the on-premises Exchange server and then RemoteMailbox-enable the user account as a cloud mailbox.

This results in two mailboxes – the original one on-premises and the new one in the cloud. However, the on-premises mailbox is inaccessible and autodiscover gets invalid information to setup the outlook profile.

To resolve this, perform these steps manually on the on-premises Exchange server in the Exchange Management Shell:

  1. Disable-Mailbox <alias>
  2. Enable-RemoteMailbox –Identity <alias> -PrimarySmtpAddress alias@contoso.com –RemoteRoutingAddress alias@TenantName.mail.onmicrosoft.com
  3. Wait for (or force) AD replication, then manually force a DirSync
Advertisements

Using Remote PowerShell to Bulk-Add and Verify Vanity Domains to Office 365 [Updated]

Rare is the customer who uses the built-in Office 365 tenant domains for doing business. After all, what company wants to be known as “Widgets.OnMicrosoft.com”? You’re vane and want to have your own name, right? Sometimes, you want to go by LOTS of names, especially if your company is involved in different areas of business or has lots of different subsidiaries that go by different names.

Adding individual vanity domains to Office 365 is very easily done through the web portal and is well-documented in the Office 365 contextual help located here. But the purpose of this post is to show you how to bulk-add lots of domains to your tenant via remote PowerShell.

Step 1 is to collect a list of all the domains you need to add and save them in a TXT file like the one below. All you need is a list of domains – one per line.

fabrikam1.com
fabrikam2.com
fabrikam3.com
fabrikam4.com

Save this file with a name like VanityDomains.txt or something like that.

Then, open a remote PowerShell session to your Office 365 tenant, making sure to load the MSOnline module. I recommend using my script that I wrote a while back – it loads the modules for you. You can find it here.

Once connected, run the following command:

$VanityDomains = Get-Content .VanityDomains.txt
foreach ($domain in $VanityDomains) {New-MsolDomain -Name $domain}

You’ll get results similar to below:

Name                Status                Authentication
—-                ——                ————–
fabrikam1.com        Unverified                Managed
fabrikam2.com        Unverified                Managed
fabrikam3.com        Unverified                Managed
fabrikam4.com        Unverified                Managed

Now that you’ve added the domains to the tenant, you need to setup the DNS TXT records so that you can validate that you own the domains. To do that, you can run the following PowerShell command next to get a list of what TXT records you need to add:

foreach ($domain in $VanityDomains) {Get-MsolDomainVerificationDns -DomainName $domain -Mode DnsTxtRecord}

You’ll get results similar to below:

Label : contoso1.com
Text : MS=ms34591742
Ttl : 3600

Label : contoso2.com
Text : MS=ms16484203
Ttl : 3600

Label : contoso3.com
Text : MS=ms17807888
Ttl : 3600

Label : contoso4.com
Text : MS=ms22135974
Ttl : 3600

Now, log onto your external DNS provider’s website or provide this list to your DNS administrator to have the TXT records created in the public DNS for each zone. Once that’s done, you can validate the domains with the following command:

foreach ($domain in $VanityDomains) {Confirm-MsolDomain -DomainName $domain}

Office 365 will check for the existence of those DNS TXT records for each domain and if so, change the Status for each domain from Unverified to Verified.

The last thing you’ll need to do for each domain is to assign intent. (is this domain meant for Email or SharePoint or Lync?). Unfortunately, as of this writing there is no way to script these settings via PowerShell. This isn’t such a bad thing if you have a handful of domains to work through. But if you have A LOT (and why would you be looking to do all this through PowerShell if you didn’t) you are looking at a grueling experience clicking through the portal interface for each domain to assign intent.

If this changes in the future I’ll come back and update this post to reflect that. Until then, happy clicking.