Configuring an Exchange Hybrid Deployment Migrating to Office 365 (Exchange Online) (Part 11)

by [Published on 26 March 2013 / Last Updated on 29 May 2013]

In this article we will run the Exchange 2010 hybrid configuration wizard in order to set up the Exchange hybrid configuration.

If you would like to read the other parts of this article series please go to:


In part 10 of this multi-part articles series revolving around Exchange hybrid deployment based migrations to Office 365 or more precisely Exchange Online, we had a look at the existing Exchange publishing rules in our TMG stand-alone array and then re-configure them, so that the on-premise Exchange infrastructure can coexist properly with Exchange Online. Moreover, we added our Exchange Online organization to the Exchange Management Console (EMC) as an additional Exchange forest. Finally, we connected to the Exchange Online organization using Windows PowerShell.

In this part 11, we will continue where we left off in part 10. That is we will run the Exchange 2010 hybrid configuration wizard in order to set up the Exchange hybrid configuration.

Let’s get going…

Configuring Exchange 2010 Hybrid

Okay, so we have now prepared our on-premise Exchange messaging environment as well as our Exchange Online organization for the Exchange 2010 based hybrid configuration and now, the moment we have all been waiting for has arrived. That is we are going to run the famous hybrid configuration wizard in order to allow mailboxes to be moved from on-premise to Exchange Online, establish mail flow between the Exchange Online organization and our on-premise Exchange messaging environment and configure cross-forest availability lookups (free/busy information and calendar sharing).

To launch the hybrid configuration wizard (HCW), open the Exchange Management Console (EMC) and then click “Organization Configuration”. Select the “Hybrid Configuration” tab and then click “New Hybrid Configuration

Figure 1: Hybrid Configuration tab in the Exchange Management Console

In the “New Hybrid Configuration” wizard, click “New”.

Figure 2:
Clicking New in the Hybrid Configuration wizard

The hybrid configuration wizard will now do the following:

  • Create a new self-signed certificate that will be used for federation with the Microsoft Federation Gateway (MFG)
  • Create a new federation trust with the Microsoft Federation Gateway (MFG)
  • Create a new hybrid configuration object in the on-premise Active Directory

When the wizard has completed, click “Finish”.

Figure 3:
Hybrid configuration wizard completed successfully

Now right-click on the new hybrid configuration object and select “Manage Hybrid Configuration”. On the “Introduction” page, click “Next”.

Figure 4:
HCW Introduction page

On the “Credentials” page, enter the credentials for the on-premise Exchange administrator as well as the Office 365 Global administrator. Note the format for each username. This is important. You see, if you for instance try to use domain\user when authenticating against the Office 365 tenant, authentication will fail.

When you have entered the credentials for each organization, click “Next”.

Figure 5:
HCW Credentials page

On the “Domains” page, we need to enter the respective accepted domain we want to federate with the MFG. In my case, it’s “” (as you should know by now :)), so I enter that and click “Next”.

Figure 6:
HCW Domains page

Okay, we have now reached the “Domain Proof of Ownership” page and as you can see in Figure 7, my domain name is in a “Pending” status. This is because the HCW cannot verify this domain as we first need to create a text (TXT) record in external DNS.

Figure 7:
HCW Domain Proof of Ownership page

So before you click “Next” on the “Domain Proof of Ownership” page, we need to create the TXT record in our external DNS. Basically, we need to create a TXT record in the root of our domain containing the text string shown under the “Record Value” column in Figure 7.

In order to speed things up, make sure to create the TXT record with a TTL value of 3600 or lower in order.

Figure 8:
TXT record in external DNS

If you wish to federate multiple accepted domains, you must create a TXT record for each.

Okay, back on the “Domain Proof of Ownership” page, tick “Check to confirm that the TXT records have been created in public DNS for the domains above” and then click “Next”.

This brings us to the “Servers” page, which is the place where we need to add our Exchange 2010 hybrid servers (Client Access and Hub Transport servers if you’re not using multi-role hybrid servers). The servers specified here will be used for sharing and mailbox moves. Do so and click “Next”.

Figure 9:
HCW Servers page

On the appearing “Mail Flow Settings” page, enter the public IP address(es) for the hybrid servers (Hub Transport servers if you are not using multi-role hybrid servers). Then add the FQDN of the hybrid servers (again if you do not use multi-role hybrid servers enter the FQDN for the Hub Transport servers) and then click “Next”.

Figure 10:
HCW Mail Flow Settings page

Bear in mind that the FQDN you specify on the “Mail Flow Settings” page should be a FQDN that points directly to your hybrid servers. I’ve talked to many Exchange administrators/consultants that thought, it was the MX record that should be entered here! I repeat this is not the case. You must instead create an A-record in external DNS, that points to public IP address that NAT’s to the virtual IP address (VIP) that is used to load balance incoming traffic to the hybrid servers.

Sidebar: Hybrid Deployment when using Edge Transport

As a consultant/architect with deep focus on Office 365, I configure a lot of Exchange hybrid deployments primarily for what can be considered large customers. A lot of the customers have Exchange 2003 or Exchange 2007 on-premise and wish to move to Exchange Online. Because of the size as well as requirements, these customers always choose the hybrid deployment based migration approach so that the migration is as transparent as possible for the end-users. However, I also see customers that simply want to keep some user mailboxes on-premise while moving others to Exchange Online. In addition, they would like to have the ability to be able to off board a mailbox.

So when it comes to hybrid configuration scenarios I rarely need to deal with an on-premise Exchange infrastructure where there are Edge Transport servers deployed in the perimeter network. Let’s face it, not many customers use this Exchange server role.

As you probably know, the hybrid deployment itself isn’t exactly rocket science, well depending on the infrastructure you deal with that is. We can have some tough challenges with the load balancing aspects, multiple forest, multiple UPN suffices etc. but the Exchange side of things has been made relatively simple now that we have the Hybrid Configuration Wizard (HCW).

Recently, I had a large customer that ran Exchange 2007 and had the Edge Transport role deployed in the perimeter network. And this introduces additional steps you need to account for when dealing with an Exchange hybrid deployment.

Most customers running Exchange 2007 that also have Edge Transport servers in the perimeter network usually use Exchange 2007 based Edge Transport servers. When this is the case, you not only need to deploy Exchange 2010 SP2 hybrid based servers with the Hub Transport and Client Access server roles (and the mailbox server role if the on-premise environment is Exchange 2003), but in order for mail flow to work properly, you must also use Exchange 2010 SP2 based Edge Transport servers.

Since the Hybrid Configuration Wizard (HCW) hasn't been developed with Edge Transport servers in mind, there are several post steps you need to go through after you have configured a standard hybrid deployment.

  1. Deploy the Exchange 2010 Edge Transport servers Obviously, one of the first post steps is to deploy the Exchange 2010 Edge Transport servers in the perimeter network.
  2. Configure EdgeSync After having deployed the Exchange 2010 Edge Transport servers, you must subscribe them to the respective Active Directory site that holds the Exchange hybrid servers using Edge Synchronization.
  3. Configure an Edge Transport DNS record You must create a CNAME or A-record (such as in external DNS that points to the Edge Transport servers public IP address.
  4. Update SPF You should also remember to update your SPF record to include the new Exchange 2010 Edge Transport servers.
  5. Import the hybrid configuration certificate on the Edge Transport servers You need to export the certificate used for the hybrid configuration from one of the hybrid servers and import it on the Edge Transport servers. When imported, you must assign it to SMTP (without overwriting the default self-signed certificate).
  6. Re-run the Hybrid Configuration Wizard You need to re-run the Hybrid Configuration Wizard and make sure the public IP address is associated with the Exchange 2010 Edge Transport servers and specify the FQDN for the Edge Transport servers (i.e.
  7. Modify the Office 365 Outbound Connector You need to modify the send connector created by the Hybrid Configuration Wizard (HCW) and, more specifically, change the source servers from the hybrid servers to the Edge Transport servers.
  8. Configure the default Receive Connector on the Edge Transport servers Finally, you need to configure the default Receive Connector on each Exchange 2010 Edge Transport server. More specifically, you need to enable support for the XOORG protocol.

As you can see, configuring a hybrid deployment that involves Edge Transport servers includes quite a few additional post-steps compared to a traditional hybrid deployment scenario without Edge Transport servers.

With the Exchange 2013, things have improved quite a bit even though the RTM version comes without the Edge Transport role. Because of this, the supported scenario is to use Exchange 2013 hybrid servers and Exchange 2010 Edge Transport servers.

Configuring Exchange 2010 Hybrid (continued)

Okay, the next page is “Mail Flow Security”. Here, we have to point to the certificate we wish to use for securing transport using TLS. Bear in mind, this must be a certificate issued by a trusted certificate authority provider. In this article, I use the wildcard certificate, which I have imported and configured on the Exchange 2010 hybrid servers in a previous article in this series.

On this page, we also need to decide whether we wish to route e-mail messages coming from mailboxes moved to Exchange Online via our on-premise environment or if they should route directly to the destination. In this case I choose the latter.

Click “Next”.

Figure 11:
HCW Mail Flow Security page

We have reached the “Configuration Summary” page. Click “Manage” in order to update the hybrid configuration with the settings we specified in the wizard.

Figure 12:
HCW Configuration Summary page

Hopefully, it completes successfully and you can click “Finish”. If not, well then you have some troubleshooting to do (in the next article, we will take a look at some of the most common errors you encounter when configuring hybrid with the HCW).

Figure 13:
HCW Completion page

This concludes part 11 of this multi-part article in which I explain how you configure Exchange hybrid deployment followed by migrating to Office 365 (Exchange Online).

If you would like to read the other parts of this article series please go to:

The Author — Henrik Walther

Henrik Walther avatar

Henrik Walther is a respected writer with special focus on Microsoft Exchange and Office 365 solutions. He works as a Principal Architect/Consultant on engagements of all sizes and complexity and have close to two decades of experience in the IT business.

Latest Contributions


Featured Links