How to reconcile user with both on-premise and cloud mailboxes?
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 [email protected] -ForceRemove-MsolUser -UserPrincipalName [email protected] -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.
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}