Why is ExchangeGuid blank for user that we use Enable-RemoteMailbox on?

Question

We have a hybrid setup, and in our user creation process script we create the AD object, then we connect to our on premise Exchange and run Enable-RemoteMailbox -Identity $UserName -RemoteRoutingAddress $RemoteRoutingAddress to enable the user's mailbox in Office 365.

What I have been noticing recently is if we run Get-RemoteMailbox -Identity "[email protected]" | FL *ExchangeGuid* it'll return with 00000000-0000-0000-0000-000000000000 as the ExchangeGuid. When I run Get-Mailbox while connected to O365, it'll give me the correct ExchangeGuid. This issue only happens with mailboxes that were created with Enable-RemoteMailbox, am I missing something that's causing the on premise Exchange server to see the mailbox has a blank ExchangeGuid?

I wrote the following script to fix this:

$ProblemMailboxes = Get-RemoteMailbox * | Where-Object {$_.ExchangeGuid -eq "00000000-0000-0000-0000-000000000000"} | Sort-Object Name
foreach($Mailbox in $ProblemMailboxes) {
    $ExchangeGuid = Get-OnlineMailbox -Identity $Mailbox.UserPrincipalName | Select-Object ExchangeGuid -ExpandProperty ExchangeGuid
    Set-RemoteMailbox -Identity $Mailbox.UserPrincipalName -ExchangeGuid $ExchangeGuid
}

But I rather not have to do this in the future and fix the problem or step(s) I'm missing when we create the user.

Solution 1

The only real reliable way for guids to match in a hybrid environment is to create mailbox on prem, run aad connect then when sync completes move mailbox to O365. GUIDs will rarely match when using enable remote mailbox because guid doesn't exist as an AD attribute because it wasn't created by exchange.

Solution 2

This situation occurs if the mailbox was created directly in Exchange Online since the Enable-RemoteMailbox command does not populate this attribute; also it is not included in the Azure AD Connect write back attributes. This process could definitely be improved by MS, but nonetheless it still hasnt.

I have located a script to copy back the exchangeguid from Exchange Online back to On Prem. It worked for me!

https://gallery.technet.microsoft.com/office/Sync-Exchange-Online-646b88ab#content

I had an issue with it storing the credentials in the XML so I just changed the 2 credential variables to = Get-Credential rather than it looking up the XML file.

The 2 lines I modified were:

FROM:

$ExchCred = Import-Clixml C:\scripts\creds\ExchScripts.xml 

TO:

$ExchCred = Get-Credential

and also

FROM:

$cred = Import-Clixml C:\scripts\creds\ExchScripts.xml

TO:

$cred = Get-Credential

Obviously this will prompt for credentials every time you run the script which is ok for single use. If you want it as a scheduled task you'd best get the credential export part working. Also, Make sure you DISABLE MFA on the account you're using to authenticate to Exchange Online. Once disabled, leave it sit for 15 mins to ensure full replication on MS servers. It took a while for mine to allow access even though it stopped prompting for MFA straight away.

Hope this helps someone. Took me ages to find a solution for this.

Comments

[shinjijai]

the script I provided in the question should automatically fix any mailbox that has this problem. I use the Online prefix for my O365 Exchange session.

[shinjijai]

In the article it states : "These issues can occur when the shared mailbox is created by using the Exchange Online management tools. In this situation, the on-premises Exchange environment has no object to reference for the shared mailbox. Therefore, all queries for that SMTP address fail.". Is this the same as using Enable-RemoteMailbox with the on-premises Exchange?

[yagmoth555]

Hi, it seem a good answer, but does it answer the OP ? Please edit. Thanks

[Josh]

Updated, thank you.

[shinjijai]

Thanks for the background info on why the ExchangeGUID is not populated, it's good to know. I've been using my GUID fix (basically copying it back) since posting this.