Now that the September 2021 Cumulative Updates (CUs) for Exchange Server 2019 and Exchange Server 2016 have been released, customers around the world now have access to a new security feature in Exchange Server called the Microsoft Exchange Emergency Mitigation service (EEMS). We want to address some of the initial feedback we’ve received about EEMS, which we’re thrilled to say has been very positive.
Customers and partners alike have said that EEMS is a great step forward for on-premises Exchange customers, and there is widespread support for Microsoft’s efforts in this ever-changing security landscape. But there is always room for improvement, and we very much appreciate the constructive feedback we’ve received.
Manually removing mitigations
Most of the constructive feedback has centered around the need for admins to manually remove mitigations after an applicable Exchange Server Security Update (SU) has been installed. Installing an SU that fixes a mitigated issue does not currently remove the mitigation from the server. Instead, an admin must first apply the SU and then remove any mitigations which no longer apply.
We understand that the need for manual removal of something that was added to the server automatically creates a burden for the admin. We also know that figuring out which mitigations can be removed, and which ones cannot, poses a problem. We want to provide added protections to customers, but we also want to do that in a frictionless way. So, we are looking into ways in which we can address this, including the possibility of the SU itself automatically removing any mitigations that no longer apply.
Notifying admins when a mitigation is applied
Other feedback we received is about letting the admin know when a mitigation is available or has been applied. As we detailed in our original blog post and in the documentation for EEMS, mitigation activity is logged in the Windows Event Log. 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 1001 with the same source will be logged when the EM service is started;
- Event 1002 with the same source will be logged when the EM service is stopped; and
- Event 1008 with the same source will be logged for any errors that are encountered, such as when the EM service cannot reach the OCS.
You can use Search-AdminAuditLog to review mitigation-related events. For example, to see when a mitigation was applied, you can run:
Search-AdminAuditLog -Cmdlets Set-ExchangeServer -Parameters MitigationsApplied
As shown below, the EM service also creates log files named Mitigation-Service_<Date> in the in the “V15\Logging\MitigationService” folder under the Exchange Server installation directory.
The log rolls over daily, and each daily log should contain 24 entries (one per hour every day). The logs contain details of the tasks performed by the EM service, including fetching mitigations, parsing mitigations, and applying mitigations, as well as details about the information sent to the OCS if sending diagnostic data is enabled. A sample log file is shown below.
This level of logging exists because we want to be completely transparent about the activity performed by the EM service. But we also understand the need for admins to know, in real time, when a mitigation has been applied or not. So, we are looking into ways in which we can address this, including the possibility of alerting an admin when a significant action occurs or fails to occur.
Mitigations may be disabled org-wide by default
As detailed in our original blog post, an admin can enable and disable mitigations at an organizational level or at the Exchange server level. The combination of the two available settings determines the behavior of the EM service on each Exchange server in the organization.
A couple of customers have reported that, after installing the September 2021 CU on their Exchange servers, the MitigationsEnabled property at the organizational level (which is configured using Set-OrganizationConfig) had a value of False, instead of the expected default value of True. When set to False, the EM service still checks for mitigations hourly, but it won’t automatically apply mitigations to any Exchange server in the organization.
We’re currently investigating this issue, but in the meantime, if you see this happen in your environment and you want automatic mitigation to take place, you can easily update the value to True by running the following command:
Set-OrganizationConfig -MitigationsEnabled $True
This re-enables automatic mitigation at the organization level.
Thanks again for all the feedback so far on EEMS. We hope you keep it coming!
The Exchange Team