Exchange Queue & A: Handling hybrid environments

Configuring Exchange hybrid deployments with Office 365-related functionality can be confusing at best, but it’s worth the effort.

Henrik Walther

Hybrid coexistence

Q. We’re currently configuring an Exchange 2010-based hybrid deployment. We’re preparing to migrate mailboxes from our on-premises Exchange 2007 organization to Exchange Online in Office 365. We’re using Exchange 2010-based servers for the hybrid deployment, because we haven’t yet upgraded our Office 365 tenant.

We’re a large enterprise with Exchange users using more than 30 different SMTP domains. We have users with many different primary e-mail address domains. Some use alias@contoso.com, others use alias@fabrikam.com and so on. We want coexistence when working with both Exchange Online and the on-premises Exchange 2007 organization for all users.

Would this require us to create an autodiscover DNS record for all SMTP domains, as well as add the autodiscover Fully Qualified Domain Name (FQDN) to the Subject Alternative Name (SAN) certificate we’re planning to use on the Exchange 2010 hybrid servers?

A. With older hybrid servers—that is, hybrid servers running Exchange 2010—you need to create an Autodiscover record in DNS for all SMTP domains. Also, the SAN certificate has to include all used autodiscover DNS records in the SAN list. For example, if you used three SMTP domains (contoso.com, fabrikam.com and wingtiptoys.com) in your Exchange organization and you wanted to configure coexistence for all three with Exchange Online in Office 365, you’d need to create the following Autodiscover records in DNS:

• Autodiscover.contoso.com
• Autodiscover.fabrikam.com
• Autodiscover.wingtiptoys.com

You’d also need to include these records in the SAN certificate. You could use CNAME records for Autodiscover redirection, but that wouldn’t change the fact that you have to add all Autodiscover records to the SAN certificate. Also, Exchange hybrid deployments don’t support SRV-based Autodiscover redirection.

With the Autodiscover domain feature, you have the option of setting one of your SMTP domains as the Autodiscover domain. When doing so, you remove the following requirements:

• The need to create an Autodiscover record for all SMTP domains in DNS, except for the domain you set as the Autodiscover domain
• The need to include the Autodiscover FQDN for all SMTP domains used in the SAN certificate

This is indeed a great new feature of Exchange Server 2013. The Exchange product group always introduces new features in the latest version, but now and then they also choose to back-port a feature to a previous Exchange version. When it comes to the Autodiscover domain feature, this happened with the release of Exchange 2010 SP3 RU1 (you can download it here). Yes, when applying RU1, you can use the Autodiscover domain feature in an Exchange 2010-based hybrid configuration. To set the Autodiscover domain, use the following command:

Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

You can then see the Autodiscover domain has been set by running the Get-HybridConfiguration cmdlet (see Figure 1).

Figure 1 Run the Get-HybridConfiguration cmdlet to confirm the Autodiscover domain is set.

Missing messages

Q. We’ve just configured an Exchange 2010-based hybrid deployment in order to get Exchange coexistence up and running between Exchange 2003 and Exchange Online in Office 365. Because we require mail flow in and out of Exchange Online to go through our on-premises Exchange 2010 hybrid servers, we chose the following option in the Hybrid Configuration wizard in order to configure centralized transport: “Route all Internet-bound messages through your on-premises Exchange servers. This is typically done for compliance reasons.”

We’ve configured the hybrid deployment by the book. We see the Hybrid Configuration wizard created the necessary receive and send connector on-premises and the inbound and outbound connectors in Forefront Online Protection for Exchange (FOPE). The domain name that’s used to force TLS from FOPE to the on-premises hybrid servers is in the third-party certificate on the hybrid servers. It’s correctly set on “receive for connector that accepts SMTP sessions from the FOPE IP ranges.”

Despite all this, e-mails sent from Exchange Online in Office 365 to recipients in the on-premises Exchange organizations (as well as external recipients) are never delivered. When using message tracking in the FOPE admin center, we see the following error:

“451 4.4.0 Primary target IP address responded with: ‘454 4.7.5 Certificate validation failure.’ Attempted failover to alternate host, but that did not succeed.”

We’re really stuck here. We’re wondering if you have any ideas on how to troubleshoot this further?

A. Actually, I’ve seen this error message in an Exchange 2010 hybrid deployment scenario. When configuring a hybrid configuration using the Hybrid Configuration wizard, one of the things it creates is a new receive connector named “Inbound from Office 365” on each hybrid transport server (see Figure 2).

Figure 2 The Hybrid Configuration wizard creates the new Inbound from Office 365 Receive Connector.

This connector is set to only accept incoming SMTP sessions from a specific set of IP ranges, which are associated with the FOPE service used in Office 365 (see Figure 3).

Figure 3 The Inbound from Office 365 Receive Connector only receives messages from a specific set of IP addresses.

This receive connector will also be set to the FQDN that matches the FQDN on the certificate used for the hybrid deployment (see Figure 4).

Figure 4 The Inbound from Office 365 Receive Connector settings match the FQDN on the hybrid certificate.

This is also set at the certificate to match the FQDN on the outbound connector in FOPE, so you can use forced TLS. All of this was set up by the book, as you explain you did, but still generates the same error message you received for outbound messages from Exchange Online.

While looking at the protocol log for the receive connector on the hybrid servers, I saw something strange. Incoming SMTP sessions from FOPE were going to the default receive connector. Because the correct IP ranges and other settings were correct on the Office 365 receive connector, this made no sense. Then, I noticed that although the incoming SMTP sessions presented themselves as FOPE, the source IP address was a private IP address. It turns out it was a virtual IP address (VIP) on a load balancer that distributed incoming SMTP sessions across the hybrid Exchange 2010 servers.

I added the private VIP to the remote server IP ranges list on the Office 365 receive connector. Then messages were successfully delivered. If you’re using a load balancer for SMTP, check to see if you’re dealing with the same issue.

The right key

Q. We’ve just configured two Exchange Server 2013 hybrid servers. We’re wondering if we can use an Exchange Server 2013 hybrid edition key for these servers like we can with Exchange 2010 hybrid servers?

A. Things are still being sorted out right now when it comes to the product key used for properly licensing Exchange Server 2013 as a hybrid server. So for now, just use Exchange Server 2013 in trial mode. When the trial expires, it shouldn’t have any impact on your hybrid deployment. It will just result in extra nag screens.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 18 years of experience in the IT business. He works as a senior consultant on the Office 365 cloud team with Microsoft Services Denmark, and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services). He has more than 14 years of experience writing books, articles, columns, white papers and newsletters.

Related Content

• Exchange Queue & A: Workable Work-Arounds
• Exchange Queue & A: Migration Management
• Exchange Queue & A: Exchange Is Always Changing