Office 365 – Hybrid Wizard Fails To Update Default Address Policy

In my last post “Migrating From Exchange 2003? – Watch Those Address Policies!“, I documented some of the issues that can arise when running the Office 365 Hybrid Configuration Wizard (HCW) in an Exchange 2003 organization.
No Exchange 2003, no problems right? Well unfortunately that’s not always the case; the odds are pretty good that the Exchange organization you’re working with began as Exchange 2003 or earlier. So even though all the Exchange 2003 servers are gone, that doesn’t mean poorly executed Exchange migrations of years past didn’t leave some remnants behind.
I recently worked with a client with Exchange 2007 on-premise. While deploying the Exchange 2013 hybrid server, we ran into nearly every road block possible with their existing default email address policy.
The HCW does a pretty decent job of logging the errors encountered when updating of the default policy fails. These logs can be found in: “%ExchangeInstallPath%Logging\Update-HybridConfiguration“.
The errors below were those encountered while running the HCW; resolution was a bit of an iterative process as fixing one issue would just lead us to the next.

Issue #1: Policy Version

The first attempt at running the HCW generated the error below:

ERROR : System.Management.Automation.RemoteException: The recipient policy "default policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.

A look at the address policy would confirm that the policy was in fact version “6.5.6500.0” or Exchange 2003. Usually we could just upgrade the policy with following command:

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Unfortunately, the phrase “with mailbox manager settings” in the original error tells us that the policy includes some Mailbox Manager settings. We can confirm this by checking the “HasMailboxManagerSetting” attribute on the policy and seeing that it is set to “True”. The policy cannot be updated until the Mailbox Manager settings are removed.

Issue #2: Mailbox Manager Policy

Normally, removing the Mailbox Manager settings from the policy would not be an issue. In this case, there were no Exchange 2003 servers which meant no Exchange System Manager to edit the policy with. This meant editing the policy via ASDI Edit and modifying two values. The policy should be located in the “Configuration” container in the path “CN=Recipient Policies,CN=Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration”.
Once locating the policy, you’ll want to clear the “MsExchMailboxManagerFolderSettings” value in the policy.
The second edit is to remove the following hex string from the “msExchPolicyOptionList” value (leave the 0xfc… string):

0xec 0x13 0x68 0x3b 0x89 0xce 0xba 0x42 0x94 0x42 0xd8 0x7d 0x4a 0xa3 0x0d 0xbc

If all that hex scares you, check out the Microsoft Exchange Team post for more details on the msExchPolicyOptionList value: “Taking a good look at Exchange 2003 Mailbox Manager”
After removing the Mailbox Manager settings, we were able to successfully upgrade the policy.

Issue #3: Proxy Address Templates

Surely the HCW would complete successfully now that we removed the Mailbox Manager settings and upgraded the policy? Unfortunately we were stopped by another legacy remnant, some might call it a prehistoric remnant, in the error below.

ERROR : System.Management.Automation.RemoteException: The following error occurred during validation in agent 'Rus Agent': 'Failed to valid the proxy address template "MS:CUSTOMER/HQ". Additional information: Failed to find the address type object in Active Directory for address type "MS:AMD64".. '

Yes, that’s a Microsoft Mail proxy address; also in the policy was a CCMAIL proxy address template. After confirming that these couldn’t possibly still be needed, they were removed from the default policy and we were finally able to complete the hybrid configuration successfully.