In the second week of September 2026, Exchange Online will start throttling email from on-premises Exchange Server 2016 and 2019 systems that have not reached the October 2025 public-update baseline. After throttling comes rejection. The enforcement mechanism is precise: Microsoft is targeting hybrid servers that deliver mail to Exchange Online through an OnPremises inbound connector.
If you run a hybrid Exchange environment — and if you migrated mailboxes to Microsoft 365 in the last five years, you almost certainly do — this is your problem. And here is the uncomfortable question that matters more than the deadline itself: if someone asked you right now to list every on-premises server feeding mail into your tenant, along with the exact patch level of each one, how long would it take you to answer with confidence?
For most IT teams the honest answer is a day of digging. For a worrying number of teams, the answer includes at least one server they do not know about. That is the real story here. Microsoft is about to audit your hybrid environment whether you are ready or not. The teams with live network visibility will treat September 2026 as a routine patch cycle. The teams relying on spreadsheets and quarterly scans will find out about their forgotten Exchange server the same way their users do.
What Is Actually Happening in September 2026
The enforcement is not a cliff, which makes it more dangerous, not less.
Phase one: throttling. Microsoft begins slowing mail flow from non-compliant servers. On your end, that does not look like an outage. It looks like email that is mysteriously slow, delayed delivery warnings, and users complaining that a customer's message took forty minutes to arrive. Nobody gets paged for slow email — unless you are explicitly monitoring mail flow.
Phase two: rejection. Mail from below-baseline servers gets rejected outright. Now the helpdesk fills up. Users notice bounced email instantly; it is one of the highest ticket-generating failures in all of IT, because for most of the business, email is the service.
The scope: OnPremises inbound connectors. Enforcement targets the specific servers registered as the on-premises side of your hybrid mail flow. Here is the catch: that connector configuration lives in Exchange Online, not on the server you monitor every day. Your on-prem monitoring sees EX01's disk and CPU. Exchange Online knows nothing about EX01's patch level. The connector — the exact mechanism Microsoft will enforce against — sits in the gap between the two systems. No single tool owns it, so in most shops, no tool watches it.
One more reason to care: below-baseline Exchange servers are precisely the ones known public exploits target. The build that gets your mail blocked in September 2026 is the same build you should have patched for far better reasons.
Why Your Current Tooling Will Not Catch This
Your RMM sees the machine, not the mail flow path. Ninja, ConnectWise, N-able, Datto — pick yours. The agent knows EX01 exists and can report a pending KB. But almost nobody builds an Exchange-build compliance policy in the RMM, because Exchange servicing has always been the messaging admin's private spreadsheet. So the RMM holds the data, and nobody acts on it.
Quarterly scans and stale diagrams miss the server that actually matters. Every hybrid environment I have reviewed has the same cast of characters: the primary Exchange server everyone knows about, plus a second box — the DR site server, the old lab machine, the legacy system the previous admin half-decommissioned — sitting two or three cumulative updates behind, still registered as a source transport server or inside the connector's accepted IP range. Quarterly scans either skip the DR VLAN or produce a report that lands in a folder nobody opens. The Visio diagram is a decorated archive of a network that stopped existing two reorgs ago.
MSPs: multiply everything by client count. If you manage 25 tenants with hybrid Exchange, September 2026 means 25 connector audits. The workflow today is: connect to each tenant, run Get-InboundConnector, export the IP list, map each IP back to an on-prem server, remote in and check builds, update the spreadsheet. Thirty to forty-five minutes per tenant, done by a tech who also has a queue of tickets. Realistically it gets done for the three clients you are already nervous about and skipped for the rest — including the client whose DR server you have never actually seen.
The failure mode is silent until it is loud. Throttling degrades gradually. There is no event ID in your SIEM and no service-down alert from a basic ping monitor. By the time anyone notices, users are already filing tickets and you are reverse-engineering mail flow from the Microsoft 365 admin center under pressure.
What This Actually Costs
- A ticket spike you cannot triage. A throttling event at a 1,000-user organization can generate dozens of duplicate tickets within the first hour, all describing a root cause nobody has identified yet.
- Emergency patching under duress. Exchange CU servicing takes planning, a maintenance window, and hours. Doing it reactively, mid-incident, on Microsoft's timeline — that is how maintenance turns into an outage.
- SLA reports nobody trusts. When mail degrades, the ticket timestamps and the actual incident window never line up, because your helpdesk and your monitoring live in different tools with different clocks.
- Technician morale. Nothing burns out a sysadmin faster than being the last to know about a problem in their own environment.
How AlertMonitor Closes the Gap
This is exactly the scenario AlertMonitor was built for: you cannot patch, audit, or defend what you cannot see.
Continuous discovery finds the server your documentation forgot. AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Deploy it and the honest list appears within hours: not the intended list, the real one. The DR Exchange box quietly serving as a hybrid source server shows up on the map. So does the lab machine someone stood up last year and never told anyone about.
The live topology map makes hybrid mail flow visible. When you audit your OnPremises inbound connector's IP list, you match every IP to a live device on the map — with its switch, port, and VLAN context — instead of squinting at a spreadsheet. When a link drops, a device goes offline, or a new device appears, an alert fires instantly with full network context. No more quarterly scan discovering the problem four months late.
Patch management lives in the same platform. Set the October 2025 public-update baseline as a compliance policy. AlertMonitor tracks update state across your Windows estate, alerts on drift, and produces compliance reports per site — or per client, if you are an MSP. The audit that used to take a full day per environment becomes a dashboard check.
Alerts and helpdesk work together. When an Exchange-tagged device goes offline or mail-flow conditions degrade, AlertMonitor opens a ticket with device context attached. The tech starts with the topology and recent history in front of them — not a blank ticket and a guess. For an MSP with 25 hybrid tenants, that is the difference between three weeks of connector audits and one afternoon.
Practical Steps: Get Ahead of September 2026
You can start today with tools you already have, then let AlertMonitor keep the answer from going stale.
Step 1 — Inventory every Exchange 2016/2019 server on-premises:
# Run in the Exchange Management Shell
Get-ExchangeServer |
Where-Object { $_.AdminDisplayVersion -match '15\.(1|2)' } |
Select-Object Name,
@{n='Build';e={ $_.AdminDisplayVersion.ToString() }},
Site |
Format-Table -AutoSize
If the output surprises you, you have just identified the exact risk Microsoft's enforcement will hit.
Step 2 — Check every build against the October 2025 baseline:
# Set these to the October 2025 PU build numbers from Microsoft's release notes:
# https://learn.microsoft.com/exchange/new-features/build-numbers-and-release-dates
$baseline = @{
'15.1' = 15.1.2507.0 # Exchange 2016 baseline - PLACEHOLDER, verify
'15.2' = 15.2.1745.0 # Exchange 2019 baseline - PLACEHOLDER, verify
}
Get-ExchangeServer |
Where-Object { $_.AdminDisplayVersion -match '15\.(1|2)' } |
ForEach-Object {
$raw = $_.AdminDisplayVersion.ToString()
if ($raw -match 'Version (15\.\d) \\(Build (\\d+)\\.(\\d+)\\)') {
$key = $Matches[1]
$build = [double]"$($Matches[2]).$($Matches[3])"
[pscustomobject]@{
Server = $_.Name
Major = $key
Build = $build
Required = $baseline[$key]
Compliant = ($build -ge $baseline[$key])
}
}
} |
Sort-Object Compliant, Server |
Format-Table -AutoSize
Every line that reads False is a server that will be throttled in September 2026 if you do nothing.
Step 3 — Audit the OnPremises inbound connectors in Exchange Online:
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-InboundConnector |
Where-Object { $_.ConnectorType -eq 'OnPremises' } |
Select-Object Name, Enabled, TlsSenderCertificateName,
@{n='OnPremIPs';e={ $_.OnPremisesIPAddress -join ', ' }} |
Format-List
MSPs — run it across every tenant from one script:
# clients.csv columns: TenantName, AdminUPN
Import-Csv .\clients.csv | ForEach-Object {
Write-Host "=== $($_.TenantName) ===" -ForegroundColor Cyan
Connect-ExchangeOnline -UserPrincipalName $_.AdminUPN -ShowBanner:$false
Get-InboundConnector |
Where-Object { $_.ConnectorType -eq 'OnPremises' } |
Select-Object Name, Enabled,
@{n='OnPremIPs';e={ $_.OnPremisesIPAddress -join ', ' }}
Disconnect-ExchangeOnline -Confirm:$false
}
Step 4 — Cross-reference connector IPs against your live map. In AlertMonitor, open the topology map and confirm every IP from the connector output maps to a known, compliant device. Any IP in that list without a device behind it — or with a device that failed the build check in Step 2 — is your remediation list. Tag the confirmed hybrid servers (for example, exchange-hybrid) so alert policies and compliance reports follow them automatically.
Step 5 — Verify the path still works:
Test-NetConnection -ComputerName mail.contoso.com -Port 25 -InformationLevel Quiet
Step 6 — Watch queues as the early-warning indicator. Throttling shows up as queue growth before users notice:
Get-TransportService | Get-Queue |
Where-Object { $_.MessageCount -gt 50 } |
Select-Object Server, DeliveryType, MessageCount, LastError
In AlertMonitor, this becomes an automated check with an alert threshold — and a ticket if it trips.
Step 7 — Make it continuous. Build the patch-compliance policy around the October 2025 baseline, set alerting on your exchange-hybrid tagged devices (offline state, service state, queue depth), and schedule a monthly compliance report per site or per client. September 2026 becomes a line in a report, not an incident.
The Bottom Line
Microsoft has put a hard, dated enforcement mechanism on hybrid Exchange environments, aimed at the one piece of configuration — the OnPremises inbound connector — that most tooling cannot see. The gap it exposes is not really a patching gap. It is a visibility gap. If your inventory is a spreadsheet, your map is a Visio file, and your monitoring stops at the server agent, you will learn about your forgotten Exchange server from a bounced email in September 2026.
If your map is live, your discovery is continuous, and your patch compliance is a policy instead of a promise, you will already know exactly which servers matter, what builds they run, and what to fix — months before the first throttle.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.