Using the Office 365 Hybrid Configuration Wizard (Part 2)

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

• Using the Office 365 Hybrid Configuration Wizard (Part 1)
• Using the Office 365 Hybrid Configuration Wizard (Part 3)
• Using the Office 365 Hybrid Configuration Wizard (Part 4)
• Using the Office 365 Hybrid Configuration Wizard (Part 5)
• Using the Office 365 Hybrid Configuration Wizard (Part 6)

Checks to perform against your Exchange Environment

We previously began by examining update levels within the environment. Next, we’ll examine SSL certificates, reverse proxy, load balancing, autodiscover services and proxy settings.

SSL Certificate Checks

Valid, third party SSL certificates are required for Exchange Hybrid. These need to include the external DNS names that you use for HTTPS services like Autodiscover, Outlook Anywhere and Exchange Web Services. The SSL certificate also needs to include the name (or names) that you will use for secured SMTP communications.

Individual SSL certificates for HTTPS and SMTP can be used, but it is typical to use a single certificate across all Hybrid servers for both services. A Subject Alternative Name (SAN) certificate specifying each name can be used, as can a Wildcard certificate.

In the example below our example Exchange environment uses a Wildcard certificate for the organisation’s single domain name:

Figure 1: Exchange 2016 SAN Certificate

The Wildcard certificate is then assigned to SMTP and IIS on relevant servers that will participate in Hybrid. When assigning the certificate for SMTP usage, note that it does not need to override the default SMTP certificate used for Exchange internal SMTP.

Figure 2: Services assigned to the SSL certificate

Reverse Proxy, Load Balancer or Threat Management Gateway Checks

The method that Exchange Server is published to the Internet is important as it is often in the middle between Exchange and Exchange Online and responsible for passing through requests from Exchange Online to on-premises including Free/Busy, Calendar Sharing, Mailbox Moves and SMTP mail flow.

Requirements for publishing Exchange when used in Hybrid do not differ greatly from standard requirements.

If you are running a highly available Exchange 2013 or 2016 environment, using round robin DNS. Layer 4 or Layer 7 load balancing, with or without affinity it should work with Hybrid.

There are a small number of requirements that must be in place for Hybrid functionality to function:

• SSL offloading must not be used.
• Autodiscover must be published to the Internet.
• Exchange Web Services must be published to the Internet, or as a minimum the Office 365 IP address ranges.
• The following URL paths (or /ews/* and /autodiscover/*) must be published without pre-authentication enabled:
  • /autodiscover/autodiscover.svc
  • /autodiscover/autodiscover.svc/wssecurity
  • /ews/mrsproxy.svc
  • /ews/exchange.asmx/wssecurity
• SMTP port 25, TCP, must be published to the Office 365 Exchange Online Protection IP address ranges.
• Flood or Denial of Service Attack prevention features must exclude the Office 365 IP address ranges.

With Exchange 2010 highly available environments it is slightly more complex. In addition to the list above, you should ensure that

• Exchange Web Services uses source IP affinity rather than cookie-based affinity. This is to ensure that Mailbox moves remain attached to the correct Mailbox Replication Service instance.
• Inbound SMTP connections from Exchange Online Protection show the real source IP, rather than the internal IP address of the Load Balancer. This is because Exchange 2010 uses the source IP address to determine which receive connector to use.

Each load balancer or reverse proxy device will have a different method to configure these features. For organizations that publish HTTPS services to the Internet without pre-authentication minimal reconfiguration will be required.

AutoDiscover and Exchange Web Services Checks

A great test of Exchange HTTPS services externally before running the Hybrid Configuration wizard is to use Microsoft’s Remote Connectivity Analyser to verify that Autodiscover and Exchange Web Services function correctly.

Services that should be discoverable and have correct External URL values include:

• Exchange Web Services, for Free/Busy functionality and Federated Sharing
• Optionally, Outlook Anywhere. This is required to support Public Folder access, may be used by clients using cross-Hybrid shared mailboxes and assists with discovery of the Migration Endpoint.

To perform this test, visit http://testconnectivity.microsoft.com and within the Microsoft Exchange Web Services Connectivity Tests section choose the Synchronization, Notification, Availability, and Automatic Replies test as shown below:

Figure 3: Choosing to perform an EWS test

Using the credentials of a valid test user with an Exchange mailbox, execute the test ensuring that the option to Use Autodiscover to detect server settings is selected.

Figure 4: Entering test credentials

The expected result will be that the Connectivity test succeeds both for Autodiscover and the subsequent Exchange Web Services test. A successful test is shown below:

Figure 5: An example test

Outbound HTTPS, SMTP and Forward Proxy Checks

The Hybrid Exchange relationship is two-way, therefore in addition to Office 365 communicating with the on-premises Exchange organization, the on-premises Exchange organization will need to communicate with Office 365 to perform the same tasks like Free/Busy lookup.

Ideally HTTPS outbound requests from the Exchange Servers will be allowed to route directly to the Office 365 service IP address ranges. If your Exchange Servers can contact any web page over SSL in the web browser without a proxy server set, then there are potentially no changes needed.

If a proxy server is required to access HTTP and HTTPS locations on the internet then a number of changes will be required.

Firstly, the Exchange Servers will need to bypass the proxy server authentication when communicating with Office 365 URLs and IP address ranges. This is a setting that will be required for clients too, so many organizations who require a proxy will bypass authentication for any client contact Office 365.

In the Proxy Server settings in Internet Explorer the settings should be checked to ensure that communication with internal resources bypasses the proxy server, so ensure the correct exemptions are set, as shown below. We’ll need to set this correctly before moving onto the next step.

Figure 6: Updating proxy server configuration

After configuring and testing the Proxy Server settings in Internet Explorer, these must be imported into Windows and Exchange.

To import Proxy Server settings into Windows Server, use the following netsh cmdlet shown below:

Figure 7: Importing Proxy Server settings

The netsh command ensures underlying Windows components use the Proxy settings for HTTPS communications and will be used, for example, when the Hybrid Configuration Wizard connects to Exchange Online PowerShell.

Exchange Server also needs the Proxy Server configured for internal services, including Federated Free/Busy lookups. This is configured using the Set-ExchangeServer cmdlet, as shown below:

Figure 8: Setting Exchange Proxy Settings

Understanding the changes that the Office 365 Hybrid Configuration Wizard performs

Many organizations will wish to understand the changes that the Hybrid Configuration Wizard will make before executing it within a production environment.

Because the Hybrid Configuration Wizard makes slightly different changes depending on the configuration chosen and other factors, such as the number of accepted domains, the changes are slightly different for each environment.

At a high level the changes made are as follows:

• A new Hybrid Configuration object is created in the Configuration container within the local Active Directory forest.
• Settings chosen within the Hybrid Configuration Wizard are stored in the new Hybrid Configuration object.
• The Office 365 tenant is “rehydrated” by enabling organizational customization settings. This exposes all advanced features needed for Hybrid.
• A New Remote Domain is created on-premises in the format “<tenant name>.mail.onmicrosoft.com” and set as the Target Delivery Domain for Office 365.
• The same “<tenant name>.mail.onmicrosoft.com” domain is created as an accepted domain on-premises.
• Email address policies are updated with an additional SMTP proxy address in the format “<alias>@<tenant name>.mail.onmicrosoft.com”, with the option to only update secondary addresses.
• If one doesn’t exist, a Federation Trust certificate is created and the feature enabled on-premises.
• Federated domains are configured on-premises and in Office 365.
• Matching organization relationships are created both in Office 365 and on-premises with settings enabled to allow Free/Busy, Mail Tips, Remote Moves, Contact Photos, Delivery Reports and on-premises, settings to ensure that when mailboxes are moved the correct OWA URL is shown to users.
• An Availability Address Space is configured to ensure that the Hybrid servers are registered as “proxies” for Free/Busy lookups.
• The MRS Proxy is enabled on each on-premises Exchange Hybrid server.
• A new Send Connector is created to send mail destined for the <tenant name>.mail.onmicrosoft.com routing domain to Office 365 with TLS enforced, and selected Hybrid Exchange Mailbox servers are bound to it.
• The Default Front End receive connector on each selected Hybrid Client Access server is configured so that email received by TLS from trusted Office 365 SSL certificates is treated as Hybrid mail.
• Inbound and Outbound connectors are created in Office 365 to ensure internal email passes through the on-premises connectors and inbound mail from on-premises is received and classified correctly.
• If the additional OAuth configuration is applied, new partner OAuth applications are registered along with associated certificates and a new Intra Organization Connector is created both on-premises and in Office 365.

Other changes, such as configuration or copying of policies (such as Sharing Policies, In-Place Hold Policies, Mobile Device Policies) is not performed and should be configured and tested after the Hybrid configuration is complete. We’ll show how to make typical changes in this guide, after the Hybrid configuration is completed.

Summary

In this part of the series, we’ve completed some basic checks against the environment and took time to understand what changes will be made by the Hybrid Configuration Wizard. In the next part of the series we’ll run the Office 365 Hybrid Configuration Wizard.

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

• Using the Office 365 Hybrid Configuration Wizard (Part 1)
• Using the Office 365 Hybrid Configuration Wizard (Part 3)
• Using the Office 365 Hybrid Configuration Wizard (Part 4)
• Using the Office 365 Hybrid Configuration Wizard (Part 5)
• Using the Office 365 Hybrid Configuration Wizard (Part 6)