In my previous blog post I explained about an Exchange 2013 hybrid configuration, and what the prerequisites are for such a configuration and how to implement and configure one (or more) Exchange 2013 Hybrid servers.
In this blog post we’ll continue with the Hybrid Configuration and we will run the Hybrid Configuration Wizard (HCW) to actually create the Exchange 2013 Hybrid configuration.
Note. For simplicity I assume your Exchange 2013 is fully operational without any (certificate) issues on the Internet, which means you have configured all your Virtual Directories, Outlook Anywhere and Autodiscover. Everything must be working correctly to prevent any issues during configuration, possibly resulting in a misconfigured and not working hybrid configuration.
Run the Hybrid Configuration Wizard
Configuring Exchange 2013 is relatively easy and can be started from the Exchange Admin Center (EAC). The wizard that’s used here is known as the Hybrid Configuration Wizard (HCW) and in my experience a very stable (although there have been some glitches with the HCW in earlier CU’s of Exchange 2013) and efficient wizard, providing you have met all prerequisites of course.
Login to the Exchange 2013 Hybrid server and start the Exchange Admin Center locally. The reason for doing this locally on the server is that during the wizard some additional software needs to be installed for the OAuth part of the Hybrid configuration.
In the Exchange Admin Center in the navigation pane select hybrid. In the hybrid setup window click the enable button to initially enable the hybrid mode in your organization. The option My Office 365 organzation is hosted by 21Vianet should be left unchecked. Office 365 in China is hosted by 21Vianet so this option does not apply to us (unless you are in China and your organization is hosted by 21Vianet of course).
When you click enable you are prompted to logon to your Office 365 tenant. Click the sign in to Office 365 option and enter your Office 365 Global Admin credentials.
At this point it looks like we’re back in the original situation, the only difference is that we’re logged on the Office 365 tenant which you can see in the address bar. In the Exchange Control Panel click the enable button again to enable Exchange Online for a hybrid configuration. Again, don’t check the My Office 365 organization is hosted by 21Vianet checkbox.
Once enabled you get an information message saying local forest “Enterprise” is currently not configured. Would you like to setup Exchange hybrid? Well, this is what we’re here for, so click Yes to continue.
The HCW will detect all configured domains that can be used in a hybrid configuration and these are all shown in the wizard as can be seen in the following screenshot:
You can add or remove domains here as appropriate. When you want to use these domains in a Hybrid configuration they have to be validated. This is a different validation process compared to adding a domain to your Office 365 tenant, and the TXT records are different as well. When you click Next all validation records are shown, as can be seen in the following screenshot:
These are serious tokens and you better not try to type them manually in your DNS console but copy-and-past them since they are prone to error. Once added to public DNS you can use NSLOOKUP to see if they are returned properly:
When all DNS records are configured properly and replicated click Next in the HCW to continue.
You can use the Edge Transport server for SMTP traffic (secured) between your Exchange 2013 on-premises and Exchange Online, but you can also opt to use the (dedicated) Exchange 2013 hybrid server for this. I typically configure these servers, so select the Configure my Client Access and Mailbox servers for secure mail transport (typical) radio button and click Next to continue.
The next step is to point out which servers can be used as a source server for the new Send Connector and Receive Connector (to/from Exchange Online). Since we’re using a dedicated hybrid server use the Browse button to select the appropriate server as shown in the following screenshot:
Click Next and do the same for selecting the hybrid server for the new Send Connector.
The SMTP communication between Exchange 2013 on-premises and Exchange Online is encrypted (TLS) and a 3rd party certificate needs to be configured on your Exchange 2013 hybrid server. As mentioned before, do not forget to bind this SSL certificate to the SMTP Service. If you omit this step the HCW will detect the SSL certificate and continue, but when configuring the actual hybrid relationship it will fail. The error message shown is obvious as easy to fix as described in this blog post.
In the HCW, select the appropriate SSL certificate and click Next to continue.
Enter the FQDN of the Exchange 2013 hybrid server (hybrid.exchangelabs.nl) which will be used to route SMTP message from Exchange Online (Exchange Online Protection, EOP) to your Exchange 2013 on-premises environment, and click Next to continue.
The HCW needs credentials to configure the Hybrid Relationship, both in Exchange 2013 on-premises as well as Exchange Online. Enter an administrative account on-premises (CONTOSO\Administrator) and an administrative account online (Admin@contoso.onmicrosoft.com). Both accounts need to be a member of the respective Organization Management Role Groups. Click Next twice (once in every window in the HCW).
At this moment all information that’s needed for the Hybrid Configuration Wizard is gathered and when you click Update the wizard is run.
When you click Update the HWC will configure the hybrid relationship between your Exchange 2013 on-premises environment and Exchange Online. One step will be the creation of a hybrid configuration object in Active Directory:
You can find this hybrid configuration object in the Exchange services container in the Organization Partition of Active Directory as shown in the following screenshot:
When the HCW has finished the hybrid configuration is created and configured and only one step remains, the configuration of OAuth (server validation).
During configuration of OAuth additional software (the Microsoft Office 365 Support Assistant 3.5) is downloaded and installed on the server, so you have to run this part of the HCW on the Exchange 2013 hybrid server itself.
Click Configure to continue and start the configuration wizard and download the additional software. When the Security Warning appears click Run to continue, this will trigger the download of the software.
When the Security Warning appears again, click Run again to continue with the wizard. After two or three minutes the Exchange 2013 hybrid server is configured with OAuth and the HCW is finished:
Click Done to continue and close the browser. Your hybrid configuration is now fully configured.
How do you know your Exchange 2013 Hybrid configuration is working properly? Mailboxes in Exchange 2013 on-premises correspond to Mail-Enabled Users in Office 365. So, for all Mailboxes in your on-premises environment you should find a Mail-Enabled user in Office 365 (the user accounts themselves are synchronized with DirSync or WAADSync of course) as shown in the following figure:
In this blogpost I discussed how to build an Exchange 2013 hybrid scenario where Exchange Online and Exchange 2013 on-premises are tightly integrated. For a successful deployment you need to have all your prerequisites as outlined in the first blog post configured correctly, otherwise it will fail utterly. But if you have it configured properly the Hybrid Configuration Wizard will run smoothly without any issues and you will see all Mailboxes appear in Exchange Online as Mail-Enabled users.
In the next blog post we’ll discuss moving Mailboxes from Exchange on-premises to Exchange Online and how they integrate.
21 thoughts on “Exchange 2013 Hybrid Configuration Wizard (Part II)”
What if your using this hybrid solution as a pilot and not all O365 licenses are in place (only for a couple). Will this impact the way of implementation/configuration?
from an infrastructure point of view there’s no difference, the only thing is that some time after the trial ends the service is discontinued and you won’t be able to access anything. The user accounts will continue to exist, but cannot access anything.
Thx Jaap for the quick response!
Hi, Jaap. I have 5 SMTP domains (accepted domains) in my environment. Will it necessary include them in the certificate (SAN)? Thanks
For communication purposes between Exchange Online and Exchange on-premises (i.e. the ‘hybrid server’) you only need one FQDN (like hybrid.exchangelabs.nl in my environment), this is sufficient for all other domains as well.
Same question but If we have 5 SMTP domains (accepted domains) in my environment. Will it necessary include them in the certificate (SAN)? You say ‘No’ but what about autodiscover (if someone has primary mail address @5thdomain.com) ?
That’s a completely different discussion. For the hybrid server you only need one name in the SSL certificate. In this scenario autodiscover and regular webmail were handled by another server, and these have names like webmail.contoso.com and autodiscover.contoso.com. If you have five SMTP domains, you can add autodiscover FQDN’s for these domains as well. This is the easiest way to configure autodiscover for multiple domains.
But remember, in the scenario in my blogpost I was differentiating between regular traffic (webmail and autodiscover) and hybrid traffic between Exchange Online and Exchange on-premises, hence the different SSL certificate with only one name.
You can use autodiscover redirect to set autodiscover for other smtp domains.You only need one autodiscover name in the SSL certificate.
I even wrote a blog post on this some time ago 🙂
But redirect based on http give a popup on user side and using a SRV autodiscover record is not supported for Hybrid Exchange.
Hmmmm…. I haven’t thought about that. Do you have a Microsoft kb article about SRV not being supported?
and on TechNet https://technet.microsoft.com/en-us/magazine/dn249970.aspx
nice post, thanks. Would you recommend to use a dedicated CAS Hybrid Server with a dedicated SSL cerificate? I have a customer with a wildcard cert and they don’t like to use a this for the hybrid deployment. From my point of view ist looks the easies way to go with a dedicated hybrid / cas (2013 CU13) server and a new SAN cert containing the new hybrid url. Any other suggestions?
Is there a need to offload certain hybrid traffic from the regular Exchange 2013 servers?
It is possible to use additional servers (for example hybrid.contoso.com) and use these as dedicated migration endpoints. Autodiscover, Web Services, Outlook Anywhere continue to go through the original CAS servers. And you have to be careful when configuring Exchange 2013 servers as hybrid servers, especially when configuring Virtual Directories and Outlook Anywhere. If misconfigured, clients will try to connect to servers you don’t expect them to connect to. So no, I would not recommend doing this, and just the regular Exchange 2013 servers. If these servers are not sufficient from a performance point of view, just add one or two and configure them as the original servers.
Thanks Jaap, Something like this I thought or expected to run into. Can you confirm, that the TLS hybrid connection is not using the private key of the wildcard in any cases? As i unsderstand, TLS is using the public key of the on-prem wildcard cert to connect and encript the mailflow.
I always confuse the two…. Signing is done using the private key, encryption is done using the public key. Certificate information is exchanged when setting up the handshake between the two. You can see this in the protocol logfile on the Exchange information (interesting to check).
Yes thanks. Typically, the public key encrypts and the private key decrypts. So Exchange Online / Hybrid does not need any private keys to encript? Cheers, Al
I don’t have sufficient in-depth knowledge about TLS, but Exchange on-premises uses the public key of EOL to encrypt, and EOL uses its private key to decrypt (and vice versa of course).
Why are you wondering (worrying?) about the private key stuff? I’ve never worried about that in a regular environment.
Actually I’m not worried about :-). A customer does not like to exchange the *wildcard cert with EOL. But mailboxes and data can be transferd to O365 & Azure :-). So there is no issue with that but with the cert… Thanks for your help. Are you aware of the SCU Europe http://www.systemcenteruniverse.ch/ ? If you have a chance… visit us. Great speakers and tracks. Cheers, Al