Exchange Emergency Mitigation (EM) service
The Exchange Emergency Mitigation service (EM service) helps to keep your Exchange Servers secure by applying mitigations to address any potential threats against your servers. It uses the cloud-based Office Config Service (OCS) to check for and download available mitigations and to send diagnostic data to Microsoft.
The EM service runs as a Windows service on an Exchange Mailbox server. When you install the September 2021 CU (or later) on Exchange Server 2016 or Exchange Server 2019, the EM service is installed automatically on servers with the Mailbox role. The EM service won't be installed on Edge Transport servers.
The use of the EM service is optional. If you don't want Microsoft to automatically apply mitigations to your Exchange servers, you can disable the feature.
Mitigations
A mitigation is an action or set of actions that are taken automatically to secure an Exchange server from a known threat that is being actively exploited in the wild. To help protect your organization and mitigate risk, the EM service might automatically disable features or functionality on an Exchange server.
The EM service can apply the following types of mitigations:
- IIS URL Rewrite rule mitigation: This mitigation is a rule that blocks specific patterns of malicious HTTP requests that can endanger an Exchange server.
- Exchange service mitigation: This mitigation disables a vulnerable service on an Exchange server.
- App Pool mitigation: This mitigation disables a vulnerable app pool on an Exchange server.
You have visibility and control over any applied mitigation by using Exchange PowerShell cmdlets and scripts.
How does it work
If Microsoft learns about a security threat, we might create and release a mitigation for the issue. If this happens, the mitigation is sent from the OCS to the EM service as a signed XML file containing the configuration settings that are required to apply the mitigation.
After the EM service has been installed, it checks the OCS for available mitigations every hour. The EM service then downloads the XML file and validates the signature to verify that the XML wasn't tampered with. The EM service checks the issuer, the Extended Key Usage, and the certificate chain. After successful validation, the EM service applies the mitigation.
Each mitigation is a temporary, interim fix until you can apply the Security Update that fixes the vulnerability. The EM service isn't a replacement for Exchange SUs. However, it's the fastest and easiest way to mitigate the highest risks to internet-connected, on-premises Exchange servers before updating.
List of mitigations released
The following table describes the repository of all released mitigations.
| Serial number | Mitigation ID | Description | Lowest version applicable | Highest version applicable | Rollback procedure |
|---|---|---|---|---|---|
| 1 | PING1 | EEMS heartbeat probe. Doesn't modify any Exchange settings. | Exchange 2019: September 2021 CU Exchange 2016: September 2021 CU |
- | No rollback required. |
| 2 | M1 | Mitigation of CVE-2022-41040 via a URL Rewrite configuration. | Exchange 2019: RTM Exchange 2016: RTM |
Exchange 2019: October 2022 SU Exchange 2016: October 2022 SU |
Remove the rule EEMS M1.1 PowerShell - inbound manually from IIS Url rewrite module inside Default Web Site. |
Prerequisites
If these prerequisites aren't already on the Windows Server where Exchange is installed or to be installed, Setup prompts you to install these prerequisites during the readiness check:
- IIS URL Rewrite Module
- Universal C Runtime in Windows (KB2999226) for Windows Server 2012 and Windows Server 2012 R2
Connectivity
The EM service needs outbound connectivity to the OCS to check for and download mitigations. If outbound connectivity to the OCS isn't available during the installation of Exchange Server, Setup issues a Warning during the readiness check.
While the EM service can be installed without connectivity to the OCS, it must have connectivity to the OCS in order to download and apply the latest mitigations. The OCS must be reachable from the computer on which Exchange Server is installed for the EM service to function correctly.
| Endpoint | Address | Port | Description |
|---|---|---|---|
| Office Config Service | officeclient.microsoft.com/* |
443 | Required endpoint for the Exchange EM service |
Important
Make sure to exclude connections to officeclient.microsoft.com from SSL inspection workflows performed by firewalls or third-party software like AntiVirus as this could break the certificate validation logic, which is build into the EM service.
If a network proxy is deployed for outbound connectivity, you need to configure the InternetWebProxy parameter on the Exchange server by running the following command:
Set-ExchangeServer -Identity <ServerName> -InternetWebProxy <http://proxy.contoso.com:port>
You must also configure the proxy address additionally in WinHTTP proxy settings:
netsh winhttp set proxy <proxy.contoso.com:port>
In addition to outbound connectivity to the OCS, EM service needs outbound connectivity to various Certificate Revocation List (CRL) endpoints mentioned here.
These are required to verify authenticity of certificates used to sign the mitigations XML file.
We strongly recommend letting Windows maintain the Certificate Trust List (CTL) on your machine. Otherwise, this must be maintained manually regularly. To allow Windows to maintain the CTL, the following URL must be reachable from the computer on which Exchange Server is installed.
| Endpoint | Address | Port | Description |
|---|---|---|---|
| Certificate Trust List Download | ctldl.windowsupdate.com/* |
80 | Certificate Trust List download |
Test-MitigationServiceConnectivity script
You can verify that an Exchange server has connectivity to the OCS by using the Test-MitigationServiceConnectivity.ps1 script in the V15\Scripts folder in the Exchange server directory.
If the server has connectivity, the output is:
Result: Success.
Message: The Mitigation Service endpoint is accessible from this computer.
If the server doesn't have connectivity, the output is:
Result: Failed.
Message: Unable to connect to the Mitigation Service endpoint from this computer. To learn about connectivity requirements, see https://aka.ms/HelpConnectivityEEMS.
Disabling auto apply of Mitigations through EM Service
One of the EM service functions is downloading mitigations from the OCS and automatically applying them to the Exchange Server. If your organization has an alternate means of mitigating a known threat, you might choose to disable automatic applications of mitigations. You can enable or disable automatic mitigation at an organizational level or at the Exchange server level.
To disable automatic mitigation for your entire organization, run the following command:
Set-OrganizationConfig -MitigationsEnabled $false
By default, MitigationsEnabled is set to $true. When set to $false, the EM service still checks for mitigations hourly but will not automatically apply mitigations to any Exchange server in the organization, regardless of the value of MitigationsEnabled parameter at the server level.
To disable automatic mitigation on a specific server, replace <ServerName> with the name of the server, and then run the following command:
Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false
By default, MitigationsEnabled is set to $true. When set to $false, the EM service checks for mitigations hourly but will not automatically apply them to the specified server.
The combination of the organization setting and the server settings determine the behavior of the EM service on each Exchange server. This behavior is described in the following table:
| Organization setting | Server setting | Result |
|---|---|---|
| True | True | EM service will automatically apply mitigations to the Exchange server. |
| True | False | EM service won't automatically apply mitigations to a specific Exchange server. |
| False | False | EM service won't automatically apply mitigations to any Exchange server. |
Note
The MitigationsEnabled parameter automatically applies to all servers in an organization. This parameter is set to the value $true as soon as the first Exchange server in your organization is upgraded to the September 2021 CU (or later). This behavior is by design. After the other Exchange servers in the organization are upgraded with the September 2021 CU (or later), only then will the EM service honor the value of MitigationsEnabled parameter.
Viewing Applied Mitigations
Once mitigations are applied to a server, you can view the applied mitigations by replacing <ServerName> with the name of the server, and then running the following command:
Get-ExchangeServer -Identity <ServerName> | Format-List Name,MitigationsApplied
Example output:
Name : Server1
MitigationsApplied : {M01.1, M01.2, M01.3}
To see the list of applied mitigations for all Exchange servers in your environment, run the following command:
Get-ExchangeServer | Format-List Name,MitigationsApplied
Example output:
Name : Server1
MitigationsApplied : {M01.1, M01.2, M01.3}
Name : Server2
MitigationsApplied : {M01.1, M01.2, M01.3}
Reapplying a Mitigation
If you accidentally reverse a mitigation, the EM service reapplies it when it performs its hourly check for new mitigations. To manually reapply any mitigation, restart the EM service on the Exchange server by running the following command:
Restart-Service MSExchangeMitigation
10 minutes after restarting, the EM service will run its check and apply any mitigations.
Blocking or Removing Mitigations
If a mitigation critically affects the functionality of your Exchange server, you can block the mitigation, and manually reverse it.
To block any mitigation, add the Mitigation ID in the MitigationsBlocked parameter:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @("M1")
The previous command blocks the M1 mitigation, which ensures that EM service won't reapply this mitigation in the next hourly cycle.
To block more than one mitigation, use the following syntax:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @("M1","M2")
Blocking a mitigation doesn't automatically remove it, but after blocking a mitigation, you can manually remove it. How a mitigation is removed depends on the type of mitigation. For example, to remove an IIS rewrite rule mitigation, delete the rule in IIS Manager. To remove a service or app pool mitigation, start the service or app pool manually.
You can also remove one or more mitigations from the blocked mitigations list by removing the Mitigation ID in the MitigationsBlocked parameter in the same command.
For example:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @()
After a mitigation is removed from the blocked mitigations list, the mitigation will be reapplied by the EM service on its next run. To manually reapply the mitigation, stop and restart the EM service by running the following command:
Restart-Service MSExchangeMitigation
10 minutes after restarting, the EM service will run its check and apply any mitigations.
Important
Refrain from making any changes to the MitigationsApplied parameter, as it is used by the EM service to store and track mitigation status.
Viewing Applied and Blocked Mitigations
You can view both applied and blocked mitigations for all Exchange servers in your organization by using the Get-ExchangeServer cmdlet.
To view the list of applied and blocked mitigations for all Exchange servers, run the following command:
Get-ExchangeServer | Format-List Name,MitigationsApplied,MitigationsBlocked
Example output:
Name : Server1
MitigationsApplied : {M01.1, M01.3}
MitigationsBlocked : {M01.2}
Name : Server2
MitigationsApplied : {M01.1, M01.2}
MitigationsBlocked : {M01.3}
To view the list of applied and blocked mitigations on a per-server basis, replace <ServerName> with the name of the server, and then run the following command:
Get-ExchangeServer -Identity <ServerName> | fl name, *Mitigations*
Example output:
Name : Server1
MitigationsEnabled : True
MitigationsApplied : {M01.1, M01.3}
MitigationsBlocked : {M01.2}
Get-Mitigation Script
You can use the Get-Mitigations.ps1 script to analyze and track the mitigations provided by Microsoft. This script is available in the V15\Scripts folder in the Exchange Server directory.
The script displays the ID, type, description, and status of each mitigation. The list includes any applied, blocked, or failed mitigations.
To view the details of a specific server, provide the server name in the Identity parameter. For example, .\Get-Mitigations.ps1 -Identity <ServerName>. To view the status of all the servers in your organization, omit the Identity parameter.
Example: Export the list of applied mitigations and their descriptions to a CSV file by using the ExportCSV parameter:
.\Get-Mitigations.ps1 -Identity <ServerName> -ExportCSV "C:\temp\CSVReport.csv"
Important
The Get-Mitigations script needs PowerShell version 4.0.
Removing Mitigations after SU or CU upgrade
After an SU or a CU has been installed, an admin must manually remove any mitigations that are no longer needed. For example, if a Mitigation named M1 is no longer relevant after installing an SU, the EM service will stop applying it, and it will be removed from the list of applied mitigations. Depending on the type of mitigation, it can be removed from the server if necessary.
Note
The Exchange Emergency Mitigation service can add IIS URL rewrite rule mitigations on a per-site/per-vDir level (for example, on the Default Web Site or only on the OWA vDir in Default Web Site) as well as on the server level. Site/vDir level mitigations are added to the corresponding web.config file for the site/vDir whereas mitigations on the server level are added to the applicationHost.config file. It's expected that site level mitigations are removed after a CU has been installed. However, mitigations on the server level stay in place and must be manually removed if they are no longer needed.
If a mitigation is applicable for the newly installed CU, it will be reapplied by the EM.
There might be a delay between the release of an Exchange Server Security Update (SU) or Cumulative Update (CU) and an update to the Mitigation XML file, excluding the security fixed build numbers from the Mitigations being applied. This is expected and shouldn't cause any problems. If you want to remove and block a Mitigation being applied in meantime, you can follow the steps outlined in the Blocking or Removing Mitigations section.
We update the table under List of mitigations released section with the rollback procedure for the specific Mitigation as soon as it's no longer applied to security fixed Exchange builds.
Audit and Logging
Any mitigations blocked by an admin will be logged in the Windows Application Event Log. In addition to logging blocked mitigations, the EM service also logs details about service startup, shutdown, and termination (like all services running on Windows) and details of its actions and any errors encountered by the EM service. For example, Events 1005 and 1006 with a source of "MSExchange Mitigation Service" will be logged for successful actions such as when a mitigation is applied. Event 1008 with the same source, will be logged for any encountered errors, such as when the EM service can't reach the OCS.
You can use Search-AdminAuditLog to review actions taken by yourself or other admins, including enabling and disabling automatic mitigations.
The EM service maintains a separate log file in the \V15\Logging\MitigationService folder in the Exchange Server installation directory. This log details the tasks performed by the EM service, including fetched, parsed, and applied mitigations and details about the information sent to the OCS (if sending diagnostic data is enabled).
Diagnostic Data
When data sharing is enabled, the EM service sends diagnostic data to the OCS. This data is used to identify and mitigate threats. To learn more about what is collected and how to disable data sharing, see Diagnostic Data collected for Exchange Server.