Asperine for your Exchange 2010 Hybrid headache

A hybrid deployment is a good way of migrating you’re current on-prem Exchange mailboxes to Office365.
But as we know Exchange 2010 is, although supported, not an easy task to setup in terms of a “zero config” solution for Hybrid scenarious.
Because it will sometimes give you a bit of a headache I’ve come up with a sort of cheat sheet which I hope will give you a guideline for your upcoming Hybrid migration.
This post will also be updated with new experiences I will have in the upcoming months.

Because don’t forget, 2020 will be the Exchange 2010 hunting season, yeehaaah!

Prerequisites checklist

Enable the MRS proxy on EWS

When you want a mailbox to be moved to Office 365 it must be done through Exchange Web Services. This service enables remote applications or endpoints to pull (mailbox) data from Exchange via HTTPS.

The steps to enable the Mailbox Replication Service proxy on EWS is really simple with just one tick on the box or a PowerShell command:

Make sure your mailboxes have the default address book policy assigned or add the address

For a proper mail flow between the Office 365 and local Exchange servers there must be a link between these mailbox stores. Exchange uses remote mailboxes to recognize the origin of a mailbox which is located in the same domain but, at the same time, sits in a different location.

It uses the “Remote Routing Address” as the destination for mail which you send to any of the “Proxy Addresses” (the primary SMTP and alias addresses). An Exchange GUID is also given to these mailboxes so permissions and properties will be known and in sync with the Exchange Online server.

All mails that are destined for mailboxes located on Office365 will have a alias which will be set as the Remote Routing Address ( a.k.a. targetaddress property in AD).
So for example mail send to will be routed/forwarded to based on the Remote Routing Address.

If you do not enforce the address book policy on the mailboxes this address will NOT be added to the mail account.
You will have to add it manually or via a PowerShell script, as an example:

Set-ADUser -Identity Userprincipalname -Add @{ProxyAddresses=""}

Run IDFix

To exclude any account incompatibilities in the user objects you sync with AD Connect you will need to run IDFix ( )
If there are accounts with incorrect or duplicate properties these will be synced to Azure AD but Azure will change or remove the properties.
This is to make sure there are no problems with the accounts when used in production.

Check the current mobile device usage landscape

When you are migrating to Office 365 the focus also has to be on mobile devices nowadays and I’ve seen this go wrong from time to time when you migrate the mailbox from a person who is using a mail client which is not compatible with HTTP redirect 451 as outlined in this post by Microsoft:

What I always take into account when talking to customers is letting them know that now is a good time to enlighten users with the Outlook app.
Because it supports shared mailboxes and integrates nicely with all the other Office apps users will quickly fall in love with it 😉

Make all the mailboxes “ACL’able”

To properly migrate delegated permissions and support cross-premises access to mailboxes you need to make sure the remote mailboxes are ACL’able.

Public Folders, yea or nay?

Public folders, although supported, sometimes are a bit of a hassle to get going.
When you are decommissioning the local Exchange server you might experience some problems removing the public folders mailboxes or replica’s.
You could consider replacing the PF’s for shared mailboxes or leverage Microsoft Teams for interactive file services.

Also take into account:

– Enable the Exchange Hybrid sync in AD Connect to make sure all Exchange mail objects and properties are synced to Azure AD.
This makes it a requirement for automapping to function properly.

– Hybrid modern authentication is not supported when you set up Exchange 2010 in a hybrid scenario, so if you are not certain about going all-in in to the cloud you could also use a newer version of Exchange for your client access services.
Modern authentication offers improved secured login with features like MFA and conditional access which you could use for a more secure mail and collaboration environment.


Below are some of the problems I’ve found while setting up the Hybrid Exchange environment, this section will be updated throughout the upcoming months.

Adding federated domain step is taking a long time to complete

I’ve seen this problem only once and although some forum posts are found on the internet there is no real solution to this.
What you can do is monitor the process to see if it is really hanging by running the following PowerShell command:


You will then see all the Federated Domains created for Exchange, if the output and specifically the status for the added domains don’t change then look up the HCW logs located under %UserProfile%\AppData\Roaming\Microsoft\Exchange Hybrid Configuration and look for messages containing FederatedOrganizationIdentifier

Remote mailbox move hangs on 95%

When you are moving mailboxes to Office 365 you can monitor those moves with the PowerShell command:

If one or more of the mailboxes fails this is sometimes due to the Bad Item Limit you specified while creating the move request.
This limit decides how much corrupted items are skipped before the move is stopped. Because over time some mails might get corrupted because of DB problems, sync errors or other causes bad items are no exception in your Exchange mailboxes.
You can specify the item limit before you start the migration or change these while the move has already started.
To change this limit for already started moves use this command:
Get-MoveRequest | Set-MoveRequest -BadItemLimit 10 | Resume-MoveRequest

I would advice a limit of 10 items, more information can be found here:

Shared mailboxes created in EXO are unexpectedly converted to user mailboxes

When you migrate mailboxes to Exchange Online and convert these to shared mailboxes they could sometimes be reverted to user mailboxes.
This is due to the RemoteRecipientType which is set to Regular.
To make the change persistent, run below PowerShell command on the user object:

Set-ADUser -Identity UserprincipalName -Replace @{msExchRemoteRecipientType=100;msExchRecipientTypeDetails=34359738368}

This problem is also outlined by Microsoft:

Mailbox created in Office 365 not showing in GAL and/or no user object in AD

To make a mailbox known on the local Exchange a remote mailbox has to exist on the Exchange server. If this is not the case you will have to create it manually:

Create the AD user (run from a Domain Controller)

New-ADUser -Name user -UserPrincipalName

Look up the existing ExchangeGUID and on Exchange Online

get-mailbox -identity UserPrincipalName | select ExchangeGUID
get-mailbox -identity UserPrincipalName | select -expandproperty EmailAddresses

Save the ExchangeGUID and the address

Create the remote mailbox object in the local Exchange server and set the ExchangeGUID

Enable-RemoteMailbox UserPrincipalName -RemoteRoutingAddress (<- the one copied earlier)

Set-RemoteMailbox UserPrincipalName -ExchangeGuid ExchangeGUID (<- the one copied earlier)

ExchangeGUID is mandatory

This could happen when you try to create a remote mailbox.
When the user object who will have a remote mailbox contains msExch properties his/her mailbox cannot be enabled as a remote mailbox.
To solve this problem look up all the attributes via attribute editor in ADUC and remove the specified properties.

Local distribution groups not showing in Exchange (Online)

When you want to manage distribution groups from AD create the universal security or mail group object in your local AD and run below command:

Enable-distributiongroup -identity "Group Name"

If the distribution group is in a OU which is synced by AD Connect it will also show up on Exchange Online and Azure AD.

Disable DKIM for the domain

When you have a spam filter sitting in front of your Exchange server it could give you troubles when the DKIM check is not functioning properly.

As a temporary precaution you could disable DKIM signing by going to, select the domain and choose disable.

Sync public folders to Office 365

Make sure you synchronize all your public folders to Office365 so users will be able to reach them when there mailbox get’s transfered to the cloud.
You can use the following script from Microsoft to sync them:

Re-configure the SendAs permissions for all mailboxes

Send As permissions are not part of the Exchange properties so therefore they are not transfered to the cloud when you move the mailbox.
AD Connect also doesn’t sync these properties so manually adding the permissions is necessary to re-enable the users to send as a specified user, shared mailbox or distribution group.

You can create a inventory report by running the following PowerShell commands on your local Exchange server:

$permissions=get-mailbox | Get-ADPermission | Where {($_.ExtendedRights -like “Send As”)}

$permissions=$permissions | where {$_.User -notlike “S-*” -and $_.User -notlike “NTAUTHORITY\SELF”

Now add all the permissions via the Exchange Online Powershell module:

Add-recipientpermission Identity -AccessRights SendAs -Trustee User

Dit vind je misschien ook leuk...

%d bloggers liken dit: