Exchange modern hybrid and the Hybrid Agent: when to use it and how to troubleshoot it

Classic Exchange hybrid needs Exchange Online to reach your on-premises EWS endpoint from the internet. Modern hybrid topology replaces that inbound path with the Microsoft Hybrid Agent, which only makes outbound connections. In this post I'll explain what the agent carries and what it doesn't, when modern hybrid is the right choice, and how to troubleshoot the agent when free/busy or mailbox moves stop working.

How it works#

The agent uses the same technology as Microsoft Entra application proxy. If you choose Use Exchange Modern Hybrid Topology in the Hybrid Configuration Wizard (HCW), the wizard installs the agent (the Microsoft Hybrid Service, mshybridsvc), registers it in Microsoft Entra ID and creates a unique endpoint, <GUID>.resource.mailboxmigration.his.msappproxy.net. It then points Exchange Online at that URL in two places:

• the RemoteServer of the hybrid migration endpoint, which mailbox moves use;
• TargetSharingEpr on the organization relationship and/or IntraOrganization connector, which free/busy lookups from Exchange Online use.

Requests to that URL travel down the agent's outbound connection to the internal FQDN of the Exchange server you picked in HCW. Free/busy in the other direction, when on-premises users look up cloud mailboxes, never touches the agent: your Mailbox servers call Microsoft 365 directly over TCP 443.

Classic vs modern: what actually changes#

Modern hybrid doesn't remove every inbound requirement. Exchange Online still delivers mail to your on-premises hybrid endpoint over SMTP, and users who reach on-premises mailboxes from outside still need your normal client publishing. Publishing OWA or ECP through Microsoft Entra application proxy isn't supported.

When to choose modern hybrid#

It's a good fit when you can't publish EWS to the internet, the hybrid exists mainly to move mailboxes and share free/busy, and you have a single Exchange organization. It's a poor fit if you need HMA (for example, Outlook mobile against on-premises mailboxes), Teams calendar access to on-premises mailboxes, cross-premises search, several Exchange organizations or several migration endpoints. If classic hybrid already works, Microsoft recommends switching only when you're blocked from migrating. Switching means deleting the existing migration batches and the migration endpoint in Exchange Online, then rerunning HCW.

Step-by-step: deploy it with redundancy#

1. Prepare the agent server#

• Domain-joined Windows Server (the documented list runs from 2012 R2 to 2022), .NET Framework 4.7.2 or later and TLS 1.2. The installing account needs Organization Management plus local administrator rights.
• Outbound TCP 80 and 443 to the internet, and TCP 80, 443, 5985 and 5986 to the Exchange server you'll select in HCW.
• Proxies must be unauthenticated. After installation, run .\ConfigureOutBoundProxy.ps1 -ProxyAddress http://proxy:8080 from C:\Program Files\Microsoft Hybrid Service.
• Optionally, import the HybridManagement.psm1 sample script linked from Microsoft's Hybrid Agent page and run Test-HybridConnectivity -TestO365Endpoints to confirm the required endpoints are reachable.
• Enable MRS Proxy on each Mailbox server before you run HCW:

Set-WebServicesVirtualDirectory -Identity "EX01\EWS (Default Web Site)" -MRSProxyEnabled $true

2. Run HCW on the agent server#

Run HCW on the computer that should host the agent, pick Full or Minimal, then select Use Exchange Modern Hybrid Topology. Downloading, installing, registering and testing the agent can take up to 10 minutes. The remaining pages, including the mail flow connectors and the SMTP certificate, are the same as in classic hybrid.

3. Remove the single points of failure#

Rerun HCW on a second server and choose Install an additional agent. Also note that the agent registers one Exchange server's internal FQDN: if that server goes offline, free/busy and moves stop. Point the registration at your load-balanced namespace instead. The AppId is the GUID in your msappproxy.net URL, not the agent ID:

Set-Location "C:\Program Files\Microsoft Hybrid Service"
Import-Module .\HybridManagement.psm1
Get-HybridAgent -UserPrincipalName admin@contoso.onmicrosoft.com
Update-HybridApplication -AppId "<endpoint GUID>" -TargetUri "https://mail.contoso.com" `
    -UserPrincipalName admin@contoso.onmicrosoft.com

Troubleshooting the agent#

Then confirm the Exchange Online side in Exchange Online PowerShell:

Get-MigrationEndpoint | Format-List Identity, RemoteServer
Get-OrganizationRelationship | Format-List Name, TargetSharingEpr
Test-MigrationServerAvailability -ExchangeRemoteMove:$true `
    -RemoteServer "<GUID>.resource.mailboxmigration.his.msappproxy.net" -Credentials (Get-Credential)

Good looks like this: both values carry the same msappproxy.net GUID, and the availability test, run with on-premises credentials, returns success.

Verify#

• In Performance Monitor on the agent server, add the Microsoft AD App Proxy Connector object's # requests counter. It should rise when you run the migration test.
• From a cloud mailbox, invite an on-premises user to a test meeting: the Scheduling Assistant shows their availability.
• A test mailbox move completes; see my migration batch guide if it doesn't.

Tips and gotchas#

• The agent's documented OS list ends at Windows Server 2022. If your Exchange SE servers run Windows Server 2025, put the agent on a supported server.
• Where Extended Protection is enabled, read Microsoft's Extended Protection guidance for the Hybrid Agent before you install.
• The HybridManagement module needs the Azure PowerShell module. Use -UserPrincipalName for MFA-enabled admins; -Credential falls back to basic authentication.
• To remove the agent, rerun HCW on the same computer and choose classic connectivity. This uninstalls the agent and unregisters it.
• Free/busy still broken after the agent checks out? Work through my hybrid free/busy guide.

References#

• Microsoft Hybrid Agent
• Hybrid deployment prerequisites