1- Hi Folks, we got a case somedays ago where the admin wanted to move the mailbox of user that is hosted in cloud (Exchange Online) to OnPrem environment
2- They commented with us they cannot move back the user in cloud to onprem because of the error below presented on Powershell connected to Exchange Online in order to try move the mailbox cloud -> onprem
PS C:\Windows\system32> Get-Mailbox -Identity firstname.lastname@example.org | New-MoveRequest -OutBound -RemoteTargetDatabase 'ExchangeLocalDatabase' -RemoteHostName 'mail.domain.onmicrosoft.com' -RemoteCredential $OnPremAdminCred -TargetDeliveryDomain 'domain.com'
Cannot find a recipient that has mailbox GUID 'c4c85e6e-bc47-4e12-adc8-67bce80dd7b6'.
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemotePermanentException
+ FullyQualifiedErrorId : [Server=CY4PR12MB1574,RequestId=fe527a05-bea2-431d-8775-8905a20515ff,TimeStamp=XX/XX/XXXX - X:XX:XX p.m.] [FailureCategory=Cmdlet-RemotePermanentException] 81AD4932,Microsoft.Exchange.Management.Migration.MailboxReplication.MoveRequest.NewMoveRequest
+ PSComputerName : outlook.office365.com
3- We told them this is because the mailboxes are different since they duplicated it and the local AD (we will not comment why they duplicated, but one of most causes of dups is assign a license to cloud user with a current mailbox on OnPrem that is not synced with all attributes through all DCs in local AD) user don’t have the guid filled in msExchMailboxGuid attribute in local AD with same value of guid that we see in error, but it seems easy if we just copy and paste the guid on error (c4c85e6e-bc47-4e12-adc8-67bce80dd7b6) to the attribute in local AD, the problem here is because that attribute doesn’t accept the guid as it is, we have to fill it as Hexadecimal, Binary, Decimal or Octal.
4- So we will need to do a conversion to proceed, here is the trick that the engineer Agustin Gallegos show to us:
a. Sample EXO Guid: c4c85e6e-bc47-4e12-adc8-67bce80dd7b6
b. Split the value in pairs: c4 c8 5e 6e - bc 47 - 4e 12 - ad c8 - 67 bc e8 0d d7 b6
c. First 4 pairs, you need to invert the order: c4 c8 5e 6e >> 6e 5e c8 c4
d. Invert next 2 pairs as well: bc 47 >> 47 bc
e. Invert next 2 pairs as well: 4e 12 >> 12 4e
f. Leave the rest of the GUID as it is: ad c8 67 bc e8 0d d7 b6
g. New on-premises HEXA value is: 6e 5e c8 c4 47 bc 12 4e ad c8 67 bc e8 0d d7 b6
h. Go and insert the value on msExchMailboxGuid attribute of the expected user as Hexadecimal
5- after insert the value into msExchMailboxGuid run a delta sync in your AADConnect Server (Start-ADSyncSyncCycle -PolicyType Delta) and run the same cmdlet to move mailbox again
6- And also I have to remember you this is a workaround when you are sure there is nothing else that will be impacted with this change, use at your own risk.