We're mid-flight on an Exchange hybrid for a 4,000-seat healthcare group right now — Exchange 2010 SP3 on-premises, ADFS 3.0 already federating the tenant, mailboxes moving to Office 365 in weekly batches of about 300. It's the same architecture we've run across the 15,000-plus mailboxes we've moved to Office 365 over the last few years, and it fails in the same handful of places every single time. So this post is the list we wish someone had handed us in 2014: what the Hybrid Configuration Wizard actually does, how autodiscover and free/busy really resolve in an exchange hybrid configuration, and the ten things that break in practice.
The context that makes hybrid worth its complexity: coexistence. For months — sometimes years — half your users are on-premises and half are in Exchange Online, and everyone expects free/busy lookups, calendar sharing, MailTips, unified GAL, and mail flow to behave as if nothing happened. Hybrid is the only architecture that delivers that. A cutover or staged migration is simpler precisely because it skips coexistence; at 4,000 seats with clinicians who schedule around shared calendars, skipping coexistence is not an option.
One era note: since late 2015 the Hybrid Configuration Wizard is a standalone, evergreen download — the Microsoft Hybrid Configuration Wizard — rather than the version baked into Exchange setup. Always run the current build. Half the "HCW is broken" posts you'll find describe bugs the standalone wizard fixed a year ago.
What the HCW actually configures — and what it never touches
Demystifying the wizard removes most of the fear. HCW is a configuration engine, not a migration tool, and everything it does you can inspect afterwards with plain PowerShell. On a typical run it:
- Creates the federation trust with the Microsoft Federation Gateway and proves domain ownership via TXT records
- Builds organization relationships in both directions (
Get-OrganizationRelationshipon-premises and in Exchange Online) — this is the free/busy plumbing - Creates send and receive connectors on-premises and inbound/outbound connectors in Exchange Online Protection, TLS-scoped to your certificate
- Sets up the remote domains and the coexistence routing domain (
tenant.mail.onmicrosoft.com) - Enables the MRS proxy endpoint on your Exchange Web Services virtual directory so mailbox moves can flow
- Stamps email address policies so new mailboxes get the routing address
What it does not do: touch autodiscover DNS, fix your certificates, configure ADFS or directory synchronization, publish anything through your firewall, or clean up the proxyAddresses attribute sprawl in your AD. Every one of those is a prerequisite, and every one of them is on the break list below. HCW completing with green checkmarks means the wizard's own objects exist — not that hybrid works. Treat the wizard's final screen as the start of testing, not the end of the project.
Run it from the newest Exchange server in the org, keep the log (%AppData%\Microsoft\Exchange Hybrid Configuration), and re-run it without fear after CU updates — it's designed to be re-run and will converge the configuration.
Autodiscover: the priority order everyone forgets
At least a third of the hybrid tickets we take end up being autodiscover. The client-side lookup order is boring and merciless, and Outlook on a domain-joined machine follows it exactly:
- SCP lookup in Active Directory — domain-joined clients find the Service Connection Point first, which points at your on-premises Exchange. This wins over everything else while the machine can reach AD.
https://yourdomain.com/autodiscover/autodiscover.xmlhttps://autodiscover.yourdomain.com/autodiscover/autodiscover.xml- HTTP redirect and SRV record fallbacks
The rule for hybrid is simple: autodiscover DNS stays pointed on-premises until the last mailbox leaves. On-premises Exchange knows how to issue a redirect for a moved mailbox — the mailbox's targetAddress points at tenant.mail.onmicrosoft.com and Outlook chases it happily. Point autodiscover at Office 365 too early and your remaining on-premises users start getting cloud answers for mailboxes that aren't there.
The classic failure we cleaned up in January: a well-meaning admin "pre-staged" the autodiscover CNAME to autodiscover.outlook.com during a change window, three months before mailboxes moved. Domain-joined Outlook kept working — SCP masked the mistake — while every ActiveSync phone and every off-network laptop quietly broke profile creation. It took two weeks for the pattern to surface through the help desk, because "my phone stopped syncing" tickets never mention DNS.
Free/busy: how it flows and why it stops
Cross-premises free/busy is the feature executives judge the whole migration by, and it has the longest dependency chain in the product. An on-premises user looking up a cloud user goes: Outlook asks on-premises EWS, the Availability service checks the organization relationship for the target domain, fetches a delegation token from the Microsoft Federation Gateway, then calls Exchange Online's EWS with it. Reverse the arrows for the other direction. Every hop is a place to fail.
When free/busy is not working in hybrid, we check in this order — it's sorted by hit rate:
# The organization relationship: enabled, right domains, right endpoint?
Get-OrganizationRelationship | Format-List Name, DomainNames,
FreeBusyAccessEnabled, TargetAutodiscoverEpr, TargetSharingEpr
# The federation trust certificate: present and not expired?
Test-FederationTrustCertificate
Test-FederationTrust -UserIdentity someone@yourdomain.com
# Can the org actually be reached from outside?
Test-OutlookWebServices -Identity someone@yourdomain.com
The recurring culprits: WSSecurity authentication silently missing from the EWS or autodiscover virtual directories after a CU (re-add it and reset IIS); the federation trust certificate expired because nobody put it in the renewals spreadsheet; TargetAutodiscoverEpr pointing at a host your firewall doesn't publish; and a proxy server that intercepts the outbound calls from the Exchange servers themselves. That last one is vicious — free/busy works one direction and not the other, and everyone stares at the wrong end. Remember the lookup originates from the server, not the client: your Exchange boxes need clean outbound HTTPS to Office 365, no authenticated proxy in the path.
Also worth knowing: a user who looks up a moved mailbox by its old habits — a cached local contact with the legacy X.500 address, say — can get hash-marks while the person next to them gets real data. Free/busy problems that affect "some users, sometimes" are almost always stale recipient cache or a remote mailbox object with a mangled targetAddress, not the org relationship.
Mail flow: centralized or not, and the certificate that runs it
HCW offers a choice it under-explains: centralized mail transport (all outbound mail from cloud mailboxes hairpins through your on-premises servers before hitting the internet) versus decentralized (Exchange Online sends directly via EOP). Default is decentralized, and that's correct for most estates. We enable centralized transport only when there's a hard requirement — a compliance appliance that must see every message, a data-loss-prevention gateway the regulator has blessed, or an on-premises encryption product. This healthcare client has exactly that, so their cloud mail hairpins. Everyone else: don't pay the latency and the dependency (your internet mail now dies when your datacenter does) for sentiment.
Whichever topology you choose, cross-premises mail rides mutual TLS between EOP and your Edge or Hub/CAS servers, matched on the certificate you named in HCW. Three certificate rules that come from scars: the certificate on the receive connector must be the exact one HCW knows (renew it and forget to re-run HCW, and hybrid mail queues with TLS errors — we watch for 454 4.7.5 in the SMTP logs); the FQDN the connector presents must match; and if a network team "helpfully" routes port 25 through a device that does SMTP inspection, mutual TLS dies and so does hybrid mail flow. Fix is always the same: exempt the EOP conversation from inspection, re-run HCW after certificate changes.
Test with headers, not with vibes: a message from an on-premises mailbox to a cloud mailbox should show your server handing off to EOP with X-MS-Exchange-Organization headers intact — that's what keeps cross-premises mail "internal" for resolution and MailTips.
Public folders, and the rest of the break list
Public folders refuse to die, so hybrid has to accommodate them. For this client — 2010 legacy public folders, 60 GB of them — we configured hybrid public folder access: cloud users reach back into the on-premises public folder hierarchy. The recipe is Microsoft's directory sync scripts for mail-enabled public folders plus:
Set-OrganizationConfig -PublicFoldersEnabled Remote `
-RemotePublicFolderMailboxes PFProxyMailbox01, PFProxyMailbox02
It works, with caveats users will find for you: cloud Outlook reaches legacy public folders over RPC/HTTP against on-premises (so those CAS URLs stay published), OWA in the cloud can't expand the legacy hierarchy, and permissions still resolve against on-premises objects — so directory sync hygiene matters. Migrate or retire the folders as a distinct project; don't let "temporarily accessible" become the permanent state. We use the coexistence window to shrink them: 60 GB is really 12 GB of live content and 48 GB of 2009.
The full break list, then — the ten things that actually break in hybrid, ranked by how often we've been paid to fix them: autodiscover DNS moved too early; free/busy dead in one direction (org relationship or WSSecurity); expired certificates nobody re-ran HCW for; SMTP inspection devices breaking TLS; proxy servers intercepting server-to-cloud EWS calls; stale targetAddress or missing routing addresses from email address policy opt-outs; recipient cache ghosts after moves; ActiveSync devices that never re-profile without a wipe-and-re-add; public folder permissions resolving against unsynced objects; and mailbox moves stalling because the MRS proxy endpoint was enabled on one CAS but not the ones the load balancer actually sends traffic to. None of these are exotic. All of them are findable in a two-day pre-flight — which is why our hybrid engagements start with a checklist, not with the wizard.
If you're facing this
We've built Exchange hybrid coexistence for government and enterprise estates from 400 seats to well past 10,000, with ADFS in front and zero data loss behind. If your free/busy is half-working, your HCW run ended in a certificate error, or you're still deciding between cutover and hybrid, we're glad to look at your topology and tell you which of the ten breaks you're about to hit. Get in touch — bring your autodiscover DNS records to the first call.