Exchange Emergency Mitigation service and AMSI: how they protect on-premises servers

Two Exchange Server features keep working between your patch cycles: the Exchange Emergency Mitigation (EM) service, which applies Microsoft-supplied mitigations soon after a threat appears, and AMSI integration, which lets your antivirus inspect HTTP requests before Exchange acts on them. In this post I'll explain how each one works, what it needs from your network and antivirus, and the commands that show whether it's actually protecting your servers.

How it works#

The Emergency Mitigation service#

• It runs as the MSExchangeMitigation Windows service on every Mailbox server, but not on Edge Transport servers. It arrived with the September 2021 CUs for Exchange 2016 and 2019 and is part of Exchange SE.
• Every hour it asks the cloud-based Office Config Service (OCS) for mitigations. Each one arrives as a signed XML file, and the service checks the issuer, Extended Key Usage and certificate chain before applying anything.
• A mitigation is an IIS URL Rewrite rule that blocks malicious request patterns, a service mitigation that disables a vulnerable service, or an app pool mitigation that disables an app pool.
• Mitigations are temporary fixes for actively exploited threats, not a replacement for security updates. Microsoft's table also lists PING1, a heartbeat probe that changes no settings.

AMSI integration#

• The Windows Antimalware Scan Interface lets an application hand content to whichever AMSI-capable antimalware product is installed. Exchange's HttpRequestFilteringModule, registered in the web.config of most FrontEnd and ClientAccess virtual directories, passes HTTP request content to that provider, and malicious requests are blocked before Exchange processes them.
• It needs Windows Server 2016 or later and Exchange 2016 CU21, Exchange 2019 CU10 or any SE build; it isn't available on Edge Transport. The provider can be Microsoft Defender Antivirus (engine 1.1.18300.4 or later) or a compatible third-party product.
• It covers HTTP only, so it doesn't replace server antivirus or mail hygiene.
• Body scanning, added in the November 2024 SU, is off by default and only works when AMSI itself is enabled.

Step-by-step: check and tune both features#

1. Prove the EM service can reach Microsoft#

Get-Service MSExchangeMitigation
cd $ExScripts
.\Test-MitigationServiceConnectivity.ps1

Good looks like a running service and Result: Success. Run the script on a Mailbox server, because it doesn't work on a management-tools-only machine. If it fails, allow outbound 443 to officeclient.microsoft.com and exclude it from SSL inspection, which breaks certificate validation. Also allow the certificate revocation endpoints and ctldl.windowsupdate.com on port 80. Behind a proxy, set both of these:

Set-ExchangeServer -Identity EX01 -InternetWebProxy http://proxy.contoso.com:8080
netsh winhttp set proxy proxy.contoso.com:8080

2. Review what's enabled, applied and blocked#

Get-OrganizationConfig | Format-List MitigationsEnabled
Get-ExchangeServer | Format-List Name,MitigationsEnabled,MitigationsApplied,MitigationsBlocked
.\Get-Mitigations.ps1 -Identity EX01

With automatic mitigation off, the service still checks hourly; it just doesn't apply anything. Get-Mitigations.ps1 lists each mitigation's ID, type, description and status (applied, blocked or failed), and -ExportCSV saves a report.

3. Block a mitigation only if it breaks something#

Set-ExchangeServer -Identity EX01 -MitigationsBlocked @("M1")

Blocking stops the service reapplying a mitigation but doesn't remove it: delete the rewrite rule in IIS Manager, or start the disabled service or app pool. To undo the block, set -MitigationsBlocked @() and run Restart-Service MSExchangeMitigation; the service checks again about ten minutes after it starts. Never edit MitigationsApplied, because the service uses it to track state.

4. Clean up after you patch#

Once you install the update that fixes a vulnerability, removing the mitigation is your job. Site and virtual-directory rules live in web.config and disappear when a CU installs, but server-level rules in applicationHost.config stay until you remove them. Block the mitigation first, then follow Microsoft's rollback steps for that ID (for M2, removing an outbound rewrite rule and its precondition from the OWA web.config).

5. Confirm AMSI is on and has a provider#

Get-SettingOverride | Where-Object { $_.ComponentName -eq "Cafe" -and $_.SectionName -eq "HttpRequestFiltering" }
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\AMSI\Providers"

The first command should return nothing (no override switching AMSI off), and the second should list at least one provider GUID. Microsoft's AMSI page shows how to resolve the GUID to a DLL; MpOav.dll means Defender Antivirus. Microsoft's Test-AMSI.ps1 script wraps this up: -CheckAMSIConfig lists providers, -TestAMSI tests whether the integration is working, and -EnableAMSI turns AMSI back on (restart IIS afterwards, which its -RestartIIS switch can do).

6. Decide on body scanning#

Turn it on with the New-SettingOverride command on Microsoft's AMSI page, on one server first. The Health Checker warns if body scanning is on while AMSI is off, if the option to block requests larger than the maximum scan size is set, or if the server's build doesn't support the setting.

Verify#

Get-ExchangeServer EX01 | Format-List Name,*Mitigations*
Get-WinEvent -FilterHashtable @{ LogName = "Application"; ProviderName = "MSExchange Mitigation Service" } -MaxEvents 20 |
  Format-Table TimeCreated,Id,Message -Wrap
Search-AdminAuditLog -Cmdlets Set-OrganizationConfig,Set-ExchangeServer -Parameters MitigationsEnabled,MitigationsBlocked

Good looks like this:

• MitigationsEnabled is True, the applied list matches what Microsoft's table says applies to your build, and anything blocked was blocked on purpose.
• Recent events 1005 and 1006 (successful actions such as an applied mitigation) and no event 1008, which signals errors such as an unreachable OCS. The detailed log is in V15\Logging\MitigationService under the Exchange installation folder.
• The audit search shows who changed automatic mitigation settings, and when.
• The Exchange Health Checker report shows no AMSI warnings and no disabling override.

Tips and gotchas#

• Don't switch EEMS off just because you patch quickly. The gap between a disclosure and your next maintenance window is exactly what it covers. Disable it only where you have another way to mitigate.
• Event 1008 often points to the network. SSL inspection, a missing WinHTTP proxy or blocked revocation checks are the first things to rule out.
• Replacing web.config files? Keep the HttpRequestFilteringModule entry, or AMSI won't work correctly for that virtual directory.
• Third-party antivirus must register as an AMSI provider; if it doesn't, nothing inspects the requests.
• Both features are layers, not a patch strategy. Install updates promptly, using a DAG-safe maintenance process.

References#

• Exchange Emergency Mitigation (EM) service (Microsoft Learn)
• Exchange Server AMSI integration (Microsoft Learn)