7

We are in the middle of hybrid coexistence migration from Exchange 2010 on-premise to Office 365. That means we have ADFS and "Dirsync" (now called Windows Azure AD Sync) running. We are more than halfway through migrating mailbox, so about 60% of our users' mailboxes are in the cloud and the remaining 40% or so are still in on-premise Exchange 2010 databases.

Today we discovered that one of our users has both an on-premise and an Office 365 mailbox linked to his one AD account. That means that if he opens Outlook on a domain-joined computer and goes through the initial configuration, it uses autodiscover to connect him to his on-premise mailbox, but if he logs on to the Office 365 portal, it shows his cloud mailbox.

Even worse, when a user whose mailbox is in the cloud sends him an e-mail, it goes only to his cloud mailbox, and when a user whose mailbox is still on-premise, it goes only to his on-premise mailbox. So he can't see all his mail all in one place.

How can we "merge" his mail data (final destination: Office 365) and make sure his Outlook "autodiscovers" the Office 365 mailbox and all mail is routed to that mailbox?

Todd Wilcox
  • 2,831
  • 2
  • 19
  • 31
  • First...the cause: https://blogs.technet.microsoft.com/timmcmic/2017/09/10/office-365-users-have-both-a-cloud-and-on-premises-mailbox/ Now (posted two weeks ago)...the solution: https://blogs.technet.microsoft.com/timmcmic/2018/04/10/office-365-detecting-and-preventing-duplicate-mailboxes-between-on-premises-and-exchange-online/ – Kirk Frankovich Apr 24 '18 at 20:50
  • Kirk, good pointers, thank you, but fyi: there are other causes, these posts don't cover every situation where dual mailboxes are created. In my case "dual delivery" started a few days ago and these posts don't apply. I'm deleting the cloud user as described below and moving back to (more reliable) on-prem. – panos415 May 14 '18 at 05:06

4 Answers4

7

I've the same problem in my domain. Someone manually create the o365 mailbox for users who already have an on-premise mailbox

I've found this way to fix it:

  • Export office 365 mailbox in PST
  • Remove office 365 user license (this will remove his cloud mailbox)
  • Remove office 365 user from office 365 AD:
    • Remove-MsolUser -UserPrincipalName youruser@youroffice365domain.com -Force
    • Remove-MsolUser -UserPrincipalName youruser@youroffice365domain.com -RemoveFromRecycleBin -Force
  • DirSync (recreate user in office 365 AD)
  • Reassign the office 365 license for the user
  • Migrate user to office 365
  • Restore PST

I think is more simple and straightforward. You can also re-migrate your mailbox on-prem (offboarding) if you need it.

Chris Magnuson
  • 3,701
  • 9
  • 40
  • 45
Mauro
  • 71
  • 1
  • 1
  • This is the other way to do it. This method involves deleting and re-creating the cloud mailbox, which I wanted to avoid doing. The GUID portion of my process is the only part that makes my process seem more annoying than this one. – Todd Wilcox Jul 18 '17 at 19:06
6

I decided I didn't want to export all the mail from the cloud mailbox using Outlook, remove the Office 365 license (or just the EOL license) from the user, then use Powershell to permanently delete the mailbox, then migrate the on-premise mailbox to the cloud, and then re-import the exported data to the new cloud mailbox. I knew that would work but seemed to roundabout. What I ended up doing might have been more so, but here's another way:

  • I changed the e-mail addresses on the on-premise mailbox to stop mail from going to it, then I used the Exchange shell to export the on-premise mailbox to PST.
  • I disabled the on-premise mailbox (which basically deletes it in Exchange 2010 - former called "removing Exchange features").
  • I created a new Mail User in Exchange 2010, connected with the existing user in question. This gave me a start on an object necessary for mail routing to Office 365 from on-premise, which is an object called a Remote Mailbox (It looks like you can't use the New Remote Mailbox... tool if the remote mailbox already exists). When creating the mail user, I made sure the target address was <user alias>@<our custom domain>.mail.onmicrosoft.com.

Once the Mail User object was sorted out, I figured I had several things to adjust in Active Directory attributes:

  • First, I capitalized the protocol for the correct reply-to address in the proxyAddresses attribute.
  • I verified the targetAddress attribute was <user alias>@<our custom domain>.mail.onmicrosoft.com.
  • Copying from another user who was set up correctly, I changed msExchRecipientDisplayType from blank to -2147483642.
  • As above, I changed msExchRecipientTypeDetails from blank to 2147483648.
  • I changed msExchRemoteRecipientType to 4.
  • Finally, it looked like I had to populate the msExchMailboxGuid attribute, which turns out to be trickier than it seemed. I found the ExchangeGuid property for the cloud mailbox using a PowerShell session connected to Exchange Online with Get-Mailbox -Identity <alias> | fl. The trick is when it's reported there, it is in text format and to edit the AD attritube one must enter it in hex format. I used an online converter (there are several, which I found out after doing a web search on the format mismatch) to get the hex version and updated the AD attribute.
  • At that point it looked I was done in AD so I ran a dirsync, made sure there were no horrible errors, and then contacted the user to run them through the Oulook initial config again, which "autodiscovered" the online mailbox and worked like a charm.
  • At this time I'm finishing up the copying of items from the PST exported at the beginning into the online mailbox using Outlook.

An anonymous user suggested the following, instead of using the GUID converter. This also would allow Powershell automation of the process.

Rather than use the GUID converter, you can just copy the GUID from 365 and update the user property in Active Directory:

$365MboxGUID = get-mailbox -identity $samaccountname | select -ExpandProperty ExchangeGuid

Set-ADUser $samaccountname -replace @{msExchMailboxGuid=$365MboxGUID}
Todd Wilcox
  • 2,831
  • 2
  • 19
  • 31
  • 2
    Did you figure out how the user got into a two-mailbox hybrid state? This sounds like mailbox migration GONE WILD. – blaughw Jun 06 '16 at 19:23
  • 1
    @blaughw I suspect the user was assigned a license in the Office 365 admin portal and then at some time later an on-premise mailbox was created. If there is no on-premise mailbox when you assign a license, it creates a cloud mailbox. If there is an on-premise mailbox then it warns you that the mailbox has not yet been migrated. Exchange 2010 has no way to check if an online mailbox exists. – Todd Wilcox Jun 06 '16 at 19:33
1

Thanks Mauro! It worked for me, U had to add -UserPrincipalName to your command and it worked for me!

Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -Force
Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -RemoveFromRecycleBin -F
chicks
  • 3,639
  • 10
  • 26
  • 36
Tony
  • 11
  • 1
-1

To get rid of the cloud mailbox I simply changed from one subscription to another so IE I was on E5, I changed my account to Business Premium but removed Exchange Online option, I then migrated my mailbox to the cloud before changing back to E5 subscription.

Kevin Nisbet
  • 1