New hybrid Organization Config Transfer-feature (OCT) announced

Yesterday, Microsoft announced the Organization Config Transfer feature (OCT) in the Hybrid Configuration Wizard. The feature is expected to start showing up starting late June 2018. In an ongoing effort to improve the Wizard, I believe this is a step in the right direction. Ever since the HCW was first conceived, running the HCW resulted in a series of steps which you had to (manually) run through to ensure that the Exchange Online configuration matched the on-premises configuration.

For example, you had to recreate the retention policies and tags that existed in the on-premises organization if you wanted to continue to use them in Exchange Online (and not to lose them during a migration!). The same was true for other policies like the OWA Mailbox Policy or ActiveSync Policy.

With the OCT feature, the HCW will automatically take care of that and copy the settings of the following elements to Exchange online for you:

  • Retention Policy
  • Retention Policy Tags
  • OWA Mailbox Policy
  • Mobile Device Mailbox Policy
  • Active Sync Mailbox Policy

Note: in this version of the HCW, it will only copy “new” policies. These are policies that do not exist in Exchange Online. If a policy with the same name already exists in Exchange Online, or when you update the policy in the on-premises organization after it has been copied to Exchange Online, the OCT-feature will not “sync” the policy or updates thereof across. As per statement from Microsoft, this is something for the next version of the feature.

Some might say this is only a small addition to the HCW, and while it might not (yet) benefit existing Hybrid customers, it’s a welcome addition for any consultant working on getting customers across to Exchange Online as it makes life just a little easier!

I’m looking forward to what Microsoft has more for hybrid in the future. Remember BRK3155 at Ignite 2017? There was a ton of cool new stuff announced, but only little has been delivered so far… Let’s see what Microsoft might deliver for Ignite 2018 as, traditionally, there seems to be a sprint to get a lot of new features out of the door ahead of the annual conference of conferences.

Looking forward to seeing you there!

-Michael

Blog Office 365

Hybrid Configration Wizard fails with error ‘Mail Flow Default Receive Connector cannot be found on server…’

Recently, I got asked to assist with a Hybrid Configuration Wizard which was failing with the following error message:

Updating hybrid configuration failed with error ‎’Subtask NeedsConfiguration execution failed: Configure Mail Flow Default Receive Connector cannot be found on server <server name>. at Microsoft.Exchange.Management.Hybrid.MailFlowTask.DoOnPremisesReceiveConnectorNeedConfiguration‎()‎ at…

Although the message might not reveal much information at first sight, it does contain everything we need to start troubleshooting. Typically, I would suggest you go and have a look into the Hybrid Configuration Wizard log files (located in the logging\Update-HybridConfiguration folder), but the only thing you would find there is the exact same error message.

First, we know that the HCW is trying to configure the hybrid mail flow and that it failed trying to modify the default connector that’s in place. More specifically, it was trying to modify the receive connector on the server that’s specified in the error message.

In this particular case, it wasn’t even able to find the Default Receive Connector. However, when you run the Get-ReceiveConnector -Server <servername>, the receive connector does show up. How is this possible?

The Hybrid Configuration Wizard looks at more specifics than just the existence of the connector. In fact, it will check that the connector’s configuration is valid as well. As such, it will check the bindings on the connector and expect that both bindings for IPv4 and IPv6 are present. So to check whether your existing connector is valid, you should run the following command:

Get-ReceiveConnector -Server <servername> | fl Identity,Bindings

receiveconnector

In this particular case, the IPv6 bindings were missing. This was caused because IPv6 was disabled on the server (which shouldn’t be!). Re-enabling IPv6 and then either manually adding the binding to the connector or re-creating the connector solved the issue.

The morale here is that you shouldn’t disable IPv6 on an Exchange 2013 box. Even more so, it’s not supported if you do. I’ve seen companies that still disable IPv6 by default; maybe a remainder from earlier times where disabling IPv6 would actually solve issues instead of creating them. However, times have changed and the IPv6 implementation in Windows is much better now…

Blog Exchange 2013 Hybrid Exchange