{"id":866,"date":"2017-12-12T11:58:09","date_gmt":"2017-12-12T09:58:09","guid":{"rendered":"https:\/\/msb365.abstergo.ch\/?p=866"},"modified":"2023-06-23T13:13:29","modified_gmt":"2023-06-23T11:13:29","slug":"merge-exchange-online-mailbox-premise-ad-account","status":"publish","type":"post","link":"https:\/\/www.msb365.blog\/?p=866","title":{"rendered":"Merge Exchange online Mailbox with on-premise AD account"},"content":{"rendered":"

One of my customer runs a hybrid exchange environment. By the onboarding process of new employees he needs to create the AD user and Mailbox onpremise.<\/p>\n

After creating the Mailbox and if is needed (depends on Company Police) the Customer moves the Mailbox to the exchange online.<\/p>\n

Here it is important to be sure that the right routing address is set and all works fine.<\/p>\n

If you wanna know more about the Routing address, you can find my article about it here<\/strong><\/a><\/p>\n

 <\/p>\n

In this Case for some reason, one of the Mailboxes was created wrong. That means,\u00a0 the Mailbox was created directly in the Cloud.<\/p>\n

Here that means that there was a User AD Object on premise but no Mailuser.<\/p>\n

When the User was sending Mails (across the Cloud) he was able to send it with his Maildomain address.<\/p>\n

But if someone tried to send him or answer him to his Mailaddress, he got the following Note:<\/p>\n

\"\"<\/p>\n

This happened because there is no Mailuser on the onpremise side Exchange. The Exchange means that this Mail address don’t exists and refuse it to accept.<\/p>\n

 <\/p>\n

How to fix this issue?<\/strong><\/p>\n

EASYLY…<\/p>\n

First we open a remote PowerShell connection to the Office 365 Tenant\u00a0and run the following cmdlet:<\/p>\n

Get-Mailbox user | fl ExchangeGUID<\/pre>\n
\"\"<\/p>\n
We copy the displayed GUID of the Exchange online Mailbox.<\/p>\n
Now we have to go to the onpremise Exchange and start the Exchange Management Shell. There we run the following cmdlet:<\/p>\n
Enable-RemoteMailbox user -RemoteRoutingAddress user@domain.mail.onmicrosoft.com<\/pre>\n
\"\"<\/p>\n
Now we are able to see in the Exchange Console under Recipient Configuration > Mail Contact<\/em><\/span> the enabled Mailuser.<\/p>\n
\"\"<\/p>\n
The next step, we need to change the GUID for the enabled Mailuser. The one we copied earlier today.<\/p>\n
For that you simply run on the onpremise Exchange management shell the following cmdlet:<\/p>\n
Set-RemoteMailbox user -ExchangeGUID <the ExchangeGUID you copied above><\/pre>\n
\"\"<\/p>\n
 <\/p>\n
So what we did?<\/strong><\/p>\n
First cmdlet will create a mail-enabled object in Exchange on-prem and configure the target Address for remote routing and coexistence.<\/p>\n
Second cmdlet sets the on-prem ExchangeGuid so it matches Office 365.<\/p>\n
This will allow you to move the mailbox from Office 365 to on-prem (offboarding), if you ever want or need to do that.<\/p>\n
As the last step is, we start a AD Sync on the AAD Connect server with the following cmdlet:<\/p>\n
Start-ADSyncSyncCycle -PolicyType Delta<\/pre>\n
\"\"<\/p>\n
When sync is successfully done, Mailbox will work as expected.<\/p>\n
I hope this solution will help you to fix this kind of issues, it is more smoother than to delete the Mailbox and recreate it.<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
Photo by\u00a0Jonathan Borba<\/a>\u00a0on\u00a0Unsplash<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
One of my customer runs a hybrid exchange environment. By the onboarding process of new employees he needs to create the AD user and Mailbox onpremise. After creating the Mailbox and if is needed (depends on Company Police) the Customer moves the Mailbox to the exchange online. Here it is important to be sure that […]<\/p>\n","protected":false},"author":1,"featured_media":3415,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1923,2,3],"tags":[],"class_list":["post-866","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-microsoft-365","category-exchange","category-powershell"],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/866","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=866"}],"version-history":[{"count":6,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/866\/revisions"}],"predecessor-version":[{"id":5208,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/866\/revisions\/5208"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/media\/3415"}],"wp:attachment":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=866"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=866"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=866"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}