If you would like to read the other parts in this article series please go to:
In part one of this article series, we looked at the checks you often need to perform before running the Hybrid Configuration Wizard to help ensure it runs through smoothly.
In part two we’re going to take a look at what happens under the hood when you run the wizard so you have a clear idea of what changes the Hybrid Configuration Wizard will make to your Exchange on-premises organization and Office 365 tenant.
Under the hood of the Hybrid Configuration Wizard
Before implementing our Hybrid Configuration, it’s useful to understand what the wizard will do to both our Exchange environment, and our Office 365 tenant. Prior to Service Pack 2, all this configuration was performed manually, and required more configuration; however if you’re not had to perform these tasks manually, it can all be a bit of a mystery.
Hybrid Configuration Object
The first action that the Hybrid Configuration Wizard will perform is the creation of an object within Active Directory.
This object stores the configuration settings that are used each time the Hybrid Configuration Wizard is ran, and can be examined either by using the Get-HybridConfiguration cmdlet or stepping through the Wizard within the Exchange Management Console. The object itself is stored within the Configuration partition of your Active Directory alongside your other Exchange organization-wide settings. As you’ll see in the screenshot below, it acts as a reference to what configuration should be performed, rather than a list of the configuration actually in place:
Figure 1: Hybrid Configuration viewed via the Exchange Management Shell
Email Address Policy Updates
We touched upon this in part one of this article, but as Email Address Policies can be an area many organizations don’t edit very often, it’s worth re-iterating.
As part of the configuration of the Hybrid Configuration, the wizard will update existing Email Address Policies to add the address of what was known prior to Service Pack 2 as the service domain. This domain, now based upon your tenant name, is used for mail flow between your on premises Exchange server and Office 365.
The service domain address is added to each Email Address Policy that includes the domains you are sharing with your Office 365 tenant in the following format:
You can see how this is displayed within an existing policy edited by the Hybrid Configuration Wizard, below:
Figure 2: Email Address Policy Changes Implemented by the Hybrid Configuration Wizard
Federation Trust Creation
Both the on-premises Exchange organization and Office 365 make use of the Microsoft Federation Gateway to act as the trust provider for features like Calendar sharing and Free/Busy.
If you already have a Federation Trust in place, the Hybrid Configuration Wizard will need to add your shared accepted domain, otherwise a new self-signed certificate will be created, distributed to Exchange 2010 servers within your organization and a new Federation trust will be created.
This part of the wizard, as you will see later on in this article, is exposed quite clearly within the Exchange Management Console; this is because after creating the Federation Trust, validation records need to be created in the external DNS to prove ownership of the domain.
Mutual Organizational Relationship Creation
In addition to a federation trust, organization relationships are created to define the relationship between the on premises Exchange organization to and from Office 365. This includes settings that define whether the following are enabled:
- Free/Busy Sharing Levels
- Whether Mailbox Moves are enabled
- Whether Exchange online archive enabled
- Whether Delivery reports are enabled for message tracking
- Enabling Mailtips and the associated access level
- URLs for AutoDiscover and the other side of the relationship’s OWA URL for redirecting users to the correct OWA location.
Configuring the Availability Address Space
As part of enabling free/busy, an Availability Address Space is created for the service domain, using Exchange Web Services as an internal proxy. This configuration enables users on older versions of Exchange, such as Exchange 2007 to view free/busy for recipients with mailboxes on Office 365 without further configuration.
Enabling Mailbox Moves
In addition to specifying that Mailbox moves are enabled between on-premises and Office 365, mailbox moves are enabled at Exchange Web Services virtual directory level, by enabling the Mailbox Replication Service (MRS) Proxy on each external facing Client Access Server.
Configure mail flow
As part of the configuration process, mail flow is configured between the on-premises Exchange organization and Office 365.
On the on-premises side, this consists of creation and configuration of two components; firstly a send connector for mail destined to Office 365 recipients, and a receive connector for messages from Office 365 – which may be, depending on the options you choose, be just to on-premises users, or all outbound mail from your Office 365 recipients.
The send connector, “Outbound to Office 365” created is scoped for your Tenant service domain, as explained about under Email Address Policy Updates.
Figure 3: The Outbound to Office 365 Send Connector
The receive connector(s), “<servername>\Inbound from Office 365” are configured to accept requests from Office 365’s FOPE address ranges and include specific settings for best compatibility with Office 365.
Figure 4: The Inbound from Office 365 Receive Connector
In Office 365, PowerShell cmdlets in Exchange Online are used to configure Forefront Online Protection for Exchange (FOPE). In particular, this configuration determines the outbound mail flow from Office 365 to your Exchange on-premises organization and the rest of the world; along with configuration to ensure your on-premises organization communicates with FOPE securely.
After configuration, you’ll be able to view your FOPE settings by visiting your Office 365’s tenant’s Exchange Control Panel, selecting the “Rules” tab, then selecting the “Configure IP safelisting, perimeter message tracing and email policies” link, as shown below:
Figure 5: Access the FOPE Administration Centre
Creation and configuration of Remote Domains
Complementing the creation of the Organizational Relationship, mail flow and email address policies is the configuration of the Remote Domains in both the Exchange on-premises organization and Office 365:
Figure 6: On-premises Remote Domains
The remote domains are created for each Hybrid domain (or to put it another way, each domain shared with both Exchange on-premises and Office 365) along with the service domain. These contain settings including:
- Out of Office boundary settings, to ensure that users in respective Exchange on-premises and Office 365 environments send internal Out of Office messages to on another.
- Message format settings, ensuring features such as automatic replies, forwarding and delivery reports work correctly; and additionally configuring messages to use Exchange rich text format whilst they remain with the organization.
- And for the service domain, configuring the relevant on-premises Remote Domain to use it as the Office 365 tenant domain. This setting is used when creating Remote Mailboxes either from the Exchange Management Shell or Console to automatically populate the correct routing address for mail.
In the second part of this series, we’ve looked at what the Hybrid Configuration Wizard will change within your Exchange environment – in a word – lots; however most of these are low impact, relatively safe and if you’ve planned properly should cause no ill effects.
In part three of this series we’ll run through the wizard itself, and then in the final two parts of this series we’ll look at what tests are worth performing against your Hybrid environment and how to begin troubleshooting errors.
If you would like to read the other parts in this article series please go to: