Configuring Exchange hybrid prior to the Hybrid Configuration Wizard (HCW) is just a distant memory at this point. The process that was a painfully long configuration was greatly simplified with the release of the HCW with SP2 for Exchange 2010 back in May 2011.
As much as the HCW has made my job easier, I’m always a bit hesitant about black box processes. Since an early age, I’ve always been one that needed to know how things work under the hood.
So what does the wizard do?
What does it change?
What is the impact?
If you submitted a change control request stating that you’re going to “run the hybrid wizard”, you’re probably being asked these same questions.
For those that are implementing Exchange hybrid on a regular basis, what the wizard does should not be a mystery at this point. If you’re new to Exchange hybrid, I’ve outlined below the individual commands run by the wizard and areas where there might be potential risk.
My Process
I gathered this data by running the HCW on an Exchange server using the “-verbose” switch. I’ve excluded anything that was just a “Get-” command and pulled out only the commands where a change is being made. When you run the HCW, you’ll find the log file in “C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration\
“.
This was done on an Exchange 2010 SP3 UR8 server, it’s possible that the HCW changes with updates and it has slightly changed over the years.
Six Stages
There essentially are six stages of the Exchange 2010 HCW:
- Check Prerequisites
- Configure Legacy Exchange Support
- Configure Recipient Settings
- Creating Organization Relationships
- Configuring Organization Relationship Settings
- Configure Mail Flow
Within each section, there are commands run in the tenant or on-premises, I’ve outlined those in the sections below.
Stage 1: Check Prerequisites
Nothing is actually changed in this stage. As the name implies, it’s a prerequisite check where you’ll see a lot of “Get-” commands in the log but no actual changes.
Stage 2: Configure Legacy Exchange Support
This stage is executed if you have Public Folders in your environment.
The command below is executed in the on-premises environment to create a folder in the Public Folder hierarchy called “OU=EXTERNAL (FYDIBOHF25SPDLT)”. This folder is used for sharing of free/busy information cross-premises when you have Exchange 2003 in the environment.
Install-FreeBusyFolder
Stage 3: Configure Recipient Settings
All of the commands in this stage are run in the on-premises environment.
First, the “coexistence domain” (tenant.mail.onmicrosoft.com) is setup as a remote domain and an accepted domain in the on-premises environment.
New-RemoteDomain -Name 'Hybrid Domain - tenant.mail.onmicrosoft.com' -DomainName 'tenant.mail.onmicrosoft.com'
Set-RemoteDomain -Identity 'Hybrid Domain - tenant.mail.onmicrosoft.com' -TargetDeliveryDomain 'True'
New-AcceptedDomain -DomainName 'tenant.mail.onmicrosoft.com' -Name 'tenant.mail.onmicrosoft.com'
The coexistence domain is then added to the email addresses policies that contain the SMTP domains selected in the wizard and those email address policies are applied.
Set-EmailAddressPolicy -Identity [Recipient Policy] -EnabledEmailAddressTemplates [Proxy Addresses] -ForceUpgrade 'True'
Update-EmailAddressPolicy -Identity [Recipient Policy]
Stage 4: Creating Organization Relationships
In this stage, commands are run both on-premises and in the tenant in order to setup the trust with the Microsoft Federation Gateway (if you don’t have one already). Organization Relationships are also created between on-premises and the cloud to support free/busy between the two environments. These commands should have virtually no impact in your environment.
These are run on-premises:
Set-Federationtrust -RefreshMetadata -Identity 'Microsoft Federation Gateway'
Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace 'company.com' -Enabled 'True'
New-OrganizationRelationship -Name 'On Premises to Exchange Online Organization Relationship' -TargetApplicationUri 'outlook.com' -TargetAutodiscoverEpr 'https://pod51060.outlook.com/autodiscover/autodiscover.svc/WSSecurity' -Enabled 'True' -DomainNames [SMTP Domains]
These are run in the tenant:
Enable-OrganizationCustomization
Set-FederatedOrganizationIdentifier -DefaultDomain 'tenant.mail.onmicrosoft.com'
New-OrganizationRelationship -Name 'Exchange Online to on premises Organization Relationship' -TargetApplicationUri 'FYDIBOHF25SPDLT.company.com' -TargetAutodiscoverEpr 'https://autodiscover.company.com/autodiscover/autodiscover.svc/WSSecurity' -Enabled 'True' -DomainNames [SMTP Domains]
Stage 5: Configuring Organization Relationship Settings
In this stage, commands are run both on-premises and in the tenant in order to enable the MRS Proxy (for mailbox moves) and configuration of the Organization Relationship for OWA redirection and free/busy. These commands should have virtually no impact in your environment.
These are run on-premises:
Set-WebServicesVirtualDirectory -Identity 'SERVER\EWS (Default Web Site)' -MRSProxyEnabled 'True'
Set-OrganizationRelationship -MailboxMoveEnabled 'True' -FreeBusyAccessEnabled 'True' -FreeBusyAccessLevel 'LimitedDetails' -ArchiveAccessEnabled 'True' -MailTipsAccessEnabled 'True' -MailTipsAccessLevel 'All' -DeliveryReportEnabled 'True' -TargetOwaURL 'http://outlook.com/owa/tenant.onmicrosoft.com' -Identity 'On Premises to Exchange Online Organization Relationship'
Add-AvailabilityAddressSpace -ForestName 'tenant.mail.onmicrosoft.com' -AccessMethod 'InternalProxy' -UseServiceAccount 'True' -ProxyUrl 'https://mail.company.com/ews/exchange.asmx'
These are run in the tenant:
Set-OrganizationRelationship -FreeBusyAccessEnabled 'True' -FreeBusyAccessLevel 'LimitedDetails' -MailTipsAccessEnabled 'True' -MailTipsAccessLevel 'All' -DeliveryReportEnabled 'True' -Identity 'Exchange Online to on premises Organization Relationship'
Stage 6: Configure Mail Flow
This stage configures the SMTP connectors in the on-premises environment and in Exchange Online Protection (EOP) in the tenant. These commands should have virtually no impact in your environment unless you are currently using EOP Standalone in which case there could be an impact to mail routing.
The commands below are run on-premises. A send connector called “Outbound to Office 365” is created it send messages with your coexistence domain (tenant.mail.onmicrosoft.com) to EOP using TLS. A receive connector is created that is restricted to the source IPs for EOP. The remote domain for your coexistence domain is then configured so that the appropriate out-of-office (OOF) is sent cross-premises.
New-SendConnector -Name 'Outbound to Office 365' -AddressSpaces [Coexistence Domain] -SourceTransportServers [Servers] -Fqdn 'mx1.company.com' -RequireTLS 'True' -TLSAuthLevel 'DomainValidation' -TLSDomain 'outlook.com' -ErrorPolicies 'DowngradeAuthFailures'
New-ReceiveConnector -Server 'SERVER' -Name 'Inbound from Office 365' -RequireTLS 'True' -PermissionGroups 'AnonymousUsers' -Fqdn 'mx1.company.com' -TLSDomainCapabilities 'outlook.com:AcceptOorgProtocol' -Bindings [0.0.0.0:25] -RemoteIPRanges [EOP IP Addresses] -AuthMechanism 'Tls'
New-RemoteDomain -Name 'Hybrid Domain - company.com' -DomainName 'company.com'
Set-RemoteDomain -Identity 'Hybrid Domain - company.com' -TrustedMailInbound 'True'
Set-RemoteDomain -Identity 'Hybrid Domain - tenant.mail.onmicrosoft.com' -TrustedMailOutbound 'True' -TargetDeliveryDomain 'True' -AllowedOOFType 'InternalLegacy' -AutoReplyEnabled 'True' -AutoForwardEnabled 'True' -DeliveryReportEnabled 'True' -DisplaySenderName 'True' -NDREnabled 'True' -TNEFEnabled 'True'
The commands below are run in the tenant. The remote domains in the cloud configured similar to the on-premises domains and then the hybrid mail flow is set. The “-CentralizedTransportEnabled” parameter here is dependent upon the option you selected during the wizard. When this is “True”, this means that messages from cloud users to the Internet are sent back on-premises as opposed to being sent direct from EOP to the Internet recipient.
New-RemoteDomain -Name 'Hybrid Domain - company.com' -DomainName 'company.com'
Set-RemoteDomain -Identity 'Hybrid Domain - company.com' -TrustedMailOutbound 'True' -AllowedOOFType 'InternalLegacy' -AutoReplyEnabled 'True' -AutoForwardEnabled 'True' -DeliveryReportEnabled 'True' -DisplaySenderName 'True' -NDREnabled 'True' -TNEFEnabled 'True'
New-RemoteDomain -Name 'Hybrid Domain - tenant.mail.onmicrosoft.com' -DomainName 'tenant.mail.onmicrosoft.com'
Set-RemoteDomain -Identity 'Hybrid Domain - tenant.mail.onmicrosoft.com' -TrustedMailInbound 'True'
Set-HybridMailflow -SecureMailEnabled 'True' -CentralizedTransportEnabled 'False' -OnPremisesFQDN 'mx1.company.com' -CertificateSubject 'mx1.company.com' -InboundIPs [X.X.X.X] -OutboundDomains [SMTP Domains]
What About Exchange 2013?
The HCW process in Exchange 2013 is slightly different in a couple areas. Look for a similar analysis of that process in a future post.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
Hello,
This is a very good breakdown of the processes performed when running the wizard. Maybe you could answer a question for me. We currently have a domain on our exchange 2010 server that we are phasing out over the next few months and we have a new domain for 365 which we are going to use. If I run the wizard would it make any changes that would prevent users from receiving mail to the old domain while we work on switching everything over and they communicate their new address to their contacts?