If you would like to read the other parts in this article series please go to:
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 2)
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 3)
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 4)
Introduction
The Hybrid Configuration Wizard makes it easy to make the many changes required to connect your on-premises Exchange servers to Office 365 and extend your organization into the cloud.
Getting Exchange Hybrid up and running can be troublesome, but it doesn’t have to be. In this short series we will take you through the pre-requisite setup steps that make implementing Hybrid very easy, then show you some additional settings worth configuring once your Hybrid configuration completes and finally take you through basic tests that help you validate your implementation.
Choices to make before you execute the Hybrid Configuration Wizard
Before you run the Hybrid Configuration Wizard you need to make some decisions. These affect the configuration changes the wizard makes and affect the pre-requisite setup you need to perform.
Hybrid Domains
The easiest and most common option is to use all your on-premises accepted domains as Hybrid domain in Office 365. This ensures that email will be correctly received by Office 365 mailboxes.
To use all of your accepted domains you will need to also configure them as Custom Domains in the Office 365 portal. Any domain configured in Office 365 must be a valid internet domain that your organisation owns and controls.
Figure 1: Addition of custom domains to match on-premises accepted domains
Hybrid Exchange Servers
Every Exchange 2013 server includes Hybrid functionality, so you don’t usually need to install additional servers to fulfil this role. Existing servers can and usually should be chosen. The typical servers to choose for Hybrid are the same servers hosting the Client Access role that manage inbound and the same servers hosting the Mailbox role for outbound mail flow. Your primary HTTPS namespaces for Exchange Web Services and AutoDiscover will always be used by default.
Hybrid Mail Flow Options
When implementing Hybrid Exchange, a decision must be made concerning the flow of email from Office 365 to external recipients.
There are two main options available; mail can be configured to flow through the existing Exchange 2013 servers and out to the Internet via the on-premises Send Connectors, or the Hybrid configuration can be set so that mail is sent directly to external recipients.
Organisations looking to move all email to Office 365 typically choose to deliver email to external recipients directly as this represents the end goal. Long term hybrid organisations who are looking to switch their anti-spam solution to Exchange Online Protection will also typically choose this option. Organisations with an existing anti-spam, data loss prevention, encryption or other compliance solution and plan on a long-term Hybrid will often choose to route mail via on-premises.
Directory Synchronisation, Password Synchronisation and Active Directory Federation
A fundamental pre-requisite before implementing a Hybrid configuration is to implement directory synchronisation for Office 365. Directory sync ensures that a copy of all relevant Active Directory accounts on-premises exist in Azure AD, the back-end user database for Office 365.
When implementing Directory Sync two options are available; the traditional Windows Azure Directory Sync Tool (DirSync) or Azure Active Directory Sync Services (AADS). Both support Exchange 2013 Hybrid and copy relevant attributes to Office 365. However, during setup for either tool you must choose options for Exchange Hybrid. Either solution can be re-configured if these options were not selected when originally implemented.
Both solutions allow for use of a feature called Alternate Login ID. This allows users to login to Office 365 using their email address and AD password, rather than the default, their Active Directory User Principal Name. Organisations using Hybrid should check if Alternate Login ID is in use, because during a Hybrid co-existence this can cause problems with Autodiscover for non-domain joined clients, as the user will not be able to login to the on-premises Autodiscover endpoint using the email address and password.
Although it makes no difference whether Password Sync or AD FS is in use for the Hybrid Configuration itself, either solution should be chosen rather than cloud-based passwords. This ensures that during client setup and Autodiscover the same password can be sent to on-premises Autodiscover and the Office 365 service.
Checks to perform against your Exchange Environment
Preparation of the Exchange 2013 environment is key to ensuring that the Hybrid configuration works after the wizard completes. The following areas are key to ensuring success.
Checking Cumulative Update Versions
Office 365 is an ever-evolving service. It is important to ensure that the latest Cumulative Update is applied to the Exchange 2013 environment. As with any patch or update it is your responsibility to test before implementation for compatibility with clients and third-party add-ons. If plans include a long-term Hybrid co-existence then be prepared to keep the Exchange 2013 servers on the latest updates on an ongoing basis.
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 2: Examining an appropriate SSL certificate to use for Hybrid
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 3: Assigning the SSL certificate for SMTP and IIS usage
Reverse Proxy, Load Balancer or Threat Management Gateway Checks
The method that Exchange Server 2013 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 2013 when used in Hybrid do not differ greatly from standard requirements, so if Exchange is published using round robin DNS. Layer 4 or Layer 7 load balancing, with or without affinity 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.
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.
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 4: Starting Exchange Web Services tests using the Remote Connectivity Analyser
Using the credentials of a valid test user with an Exchange 2013 mailbox, execute the test ensuring that the option to Use Autodiscover to detect server settings is selected.
Figure 5: Entering test account credentials in the Remote Connectivity Analyser
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 6: Verification that Exchange Web Services Tests completed successfully
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 2013 organization, the on-premises Exchange 2013 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 7: Examining existing Proxy Server settings and addition of appropriate exclusions
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:
| netsh winhttp import proxy source=ie |
Figure 8: Using Netsh to import IE proxy 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:
| Set-ExchangeServer <Server Name> -InternetWebProxy:http://<Proxy Address>:<Proxy Port> |
Figure 9: Configuring Exchange Web Proxy settings
Intranet Zone Configuration
The Exchange Admin Center in Exchange 2013 and Office 365 is accessed using a web browser. When managing a Hybrid organization, both Exchange Admin Centers are accessible from the same session using a tab at the top of the browser to switch between each.
For this functionality to work, both the Exchange 2013 servers and Exchange Online addresses must be registered in the web browser Local intranet zone.
Whilst all Office 365 URLs can be added, to perform the Hybrid Configuration and manage Exchange in Hybrid mode, add *.outlook.com and *.office365.com to the Intranet zone in addition to the internal domain name, similar to shown below:
Figure 10: Addition of appropriate sites to the Intranet zone within IE
Summary
In part one of this series we have examined the pre-requisite checks and changes typically needed before executing the Hybrid Configuration Wizard. In part two we will examine the changes that will be made, before running the wizard against our Exchange Environment.
If you would like to read the other parts in this article series please go to:
