Last month Microsoft released cumulative updates for Exchange 2016 and Exchange 2019. Once you get the September cumulative updates, be sure to grab the security updates released in October.
While Exchange 2013 did not have a cumulative update, it did receive a security update, which can be applied to Exchange 2013 Cumulative Update 23.
A security update was not released for Exchange 2010. The latest update for Exchange 2010 is still Rollup 32 (March 2nd, 2021). Keep in mind that Exchange 2010 was out of support as of October 13th, 2020.
If you need guidance on migrating from a specific CU to the latest, check out Microsoft’s Exchange Update Wizard for step-by-step instructions.
The updates are as follows:
The new Microsoft Exchange Emergency Mitigation Service
As a response to the HAFNIUM exploits the Exchange team developed a new Exchange Emergency Mitigation service to be included with Exchange Server. Emergency Mitigation is a new Windows service that is deployed by the Exchange Server setup utility.
It is effectively a built-in version of the previously released standalone Emergency Online Mitigation Tool (EOMT) that administrators could run on-demand. The standalone tool was a way for administrators to apply interim remediation until they could apply the needed patches.
In much the same way the Emergency Mitigation Service checks the Office Config Service (OCS) for new mitigation XMLs every hour. It then applies the interim remediation specified in the XML file. The mitigation service can apply the following three actions.
- Block malicious patterns in HTTP requests via the IIS URL rewrite service
- Disable vulnerable Exchange services
- Disable vulnerable App Pools in IIS
Should you accidentally undo any mitigations, restart the Emergency Mitigation Service on the Exchange Server. Within 10 minutes the service will check OCS for the latest XML and reapply any mitigations.
At the time of writing, only a test XML file exists at the Office Config Service for heartbeat purposes. That said, your Exchange Server now requires an outbound connection to https://officeclient.microsoft.com to access these mitigation XML files. To verify Exchange can reach the Office Config Service, you can leverage the Test-MitigationServiceConnectivity.ps1 script located in the Exchange scripts folder.
Once you apply a cumulative or security update that addresses the vulnerability, you will need to manually undo any actions taken by the Emergency Mitigation Service.
Choosing to enable or disable the mitigation service
You may wish to prevent the mitigation service from taking any actions on your server or in your environment. It is possible to disable the mitigation service globally by using the following command.
C:\> Set-OrganizationConfig -MitigationsEnabled $false
Alternatively, if you want to disable this for specific servers (e.g., disable for any non-internet facing servers), you can run the following command.
C:\> Set-ExchangeServer -Identity -MitigationsEnabled $false
Blocking a specific mitigation
There may be a scenario where you want the mitigation service to be available for mitigation but only wanted to block the application of specific mitigations. For example, to block mitigations with IDs 10 and 15 from a server the command would be as follows.
C:\> Set-ExchangeServer -Identity -MitigationsBlocked @("M10", "M15")
Once blocked, you will have to undo any action previously taken by the mitigation. For example, start any disabled Exchange Service, start a stopped app pool, remove the IIS URL rewrite rule.
To get a list of all mitigations posted to the Office Config Service and their appropriate IDs, run the Get-Mitigations.ps1 script within the Exchange scripts directory.
How to determine applied and blocked mitigations
If you want to determine which mitigations are currently being applied in your environment you can run the following command. The command below shows all mitigations currently applied and any you chose to block.
C:\> Get-ExchangeServer | fl name, MitigationsApplied, MitigationsBlocked
Choosing to whether to send diagnostic data to Microsoft
One of the other new features of this cumulative update is the transmission of diagnostic data back to Microsoft. It is this diagnostic data that feeds the Office Config Service about unusual behavior and potential zero-day exploits. You can choose whether you want to enable or disable the transmission of this data during setup by running either of the following commands.
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON OR Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
Alternatively, you can enable or disable the transmission of diagnostic data after setup by using the Set-ExchangeServer cmdlet with the DataCollectionEnabled parameter. For example, to disable diagnostic data collection and transmission against a sever named EX16 your command would be as follows:
C:\> Set-ExchangeServer -Identity EX16 -DataCollectionEnabled:$false
Note: You will need to run this against each Exchange server in your environment.
To enable diagnostic data collection and transmission reverse the parameter.
C:\> Set-ExchangeServer -Identity EX16 -DataCollectionEnabled:$true
For more depth and details, be sure to check out Microsoft’s full article: Exchange Emergency Mitigation Service (Exchange EM Service)
This cumulative update now requires the IIS URL Rewrite service as a prerequisite. This is required regardless of whether you have enabled or disabled the mitigation service.
If you are current on your Exchange updates, then these cumulative updates will not extend the schema. If you are running Exchange 2016 CU20 or earlier, or Exchange 2019 CU9 or earlier, you will need to perform a schema update. For a full list of schema numbers, check this article.
If you run multiple versions of Exchange in coexistence, run SETUP /PrepareAD from the newest Exchange version. For example, if you have Exchange 2013 and Exchange 2019, run SETUP /PrepareAD from Exchange 2019.
Note: If you are running in a multi-domain environment, you will need to perform SETUP /PrepareDomain in each domain. You do not need to run /PrepareDomain in the domain where you performed /PrepareAD. /PrepareAD also invokes the /PrepareDomain process.
Need a refresher from Ignite 2020?
Unfortunately, Ignite 2021 did not give us much in the way of Exchange or Outlook news. If you need a refresher on all the Exchange features announced at Ignite 2020, I highly recommend checking out the article 15 Ignite sessions every Exchange admin should see (2020 edition). In this article, there are extensive notes on what each session contained. Also, those notes include timers if you need to jump to a specific topic.
Here are some articles I thought you might like.
- On the Line with Cohesity #44: Updates on M365 and more!
- How to enroll in the Microsoft Teams public preview program
- How to enroll in the Windows Insiders Program (and get Windows 11)
- 15 Ignite sessions every Exchange admin should see (2020 Edition)
So what do you think is coming next? What would you like to see? Drop a comment below or join the conversation on Twitter @SuperTekBoy.