On October 12, 2021 Microsoft released Security Updates for vulnerabilities found in Exchange server 2013 CU23, Exchange server 2016 (CU21/CU22) and Exchange server 2019 (CU10/CU11). Severity is marked as ‘important’.
If you are running one of these versions, it is recommended to apply these security updates. Please note that the security updates are CU specific, and these are not interchangeable. Security updates are also cumulative, so these security updates contain all previous security updates for the same cumulative update. If you are running an older version of Exchange, it is strongly recommended to upgrade to the latest Cumulative Update and apply the security updates. You can use the healthchecker script to inventory your environment.
As always, after downloading the security updates, start the installation from an elevated command prompt (‘run as administrator’). This does not apply when installing from Windows Update or WSUS. And of course, please the security updates in a test environment first before installing in production.
You can download the security updates for the following products here:
When uninstalling an Exchange server that is part of a Database Availability Group, you perform several steps to remove the server from the DAG and maybe even delete the DAG itself.
So, after decommissioning the DAG I wanted to uninstall Exchange, but the readiness check failed with the following error message:
Unfortunately this link has not been updates since 2015, and does not contain any useful information.
I decommissioned the DAG earlier as you can see in the following screenshot, but it still failed the readiness check:
When using the Get-DatabaseAvailabilityGroup command nothing showed up, and also when checking Active Directory with ADSI Edit (CN=Organization, CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Database Availability Groups) nothing is shown.
The DAG is using bits of Windows failover clustering, so the culprit must be there. When executing the Get-ClusterNode and Get-Cluster commands in PowerShell, some DAG leftovers (on this particular machine) showed up:
Something must have gone wrong during decommissioning of the DAG, although no error were shown on the console.
To remove the cluster node (and thus the cluster) from this machine, execute the following command in PowerShell:
On September 28, 2021 Microsoft released their quarterly updates for Exchange server, Exchange 2019 CU11 and Exchange 2016 CU22. Despite earlier communications a new CU for Exchange 2016 is released as well.
Besides normal fixes, a new feature is introduced in these CUs as well, the Exchange Emergency Mitigation Server or EEMS. EEMS is a new service that can mitigate new security breaches when they arise. EEMS connects to a Microsoft endpoint (https://officeclient.microsoft.com/getexchangemitigations) and when needed, downloads and installs available mitigations. It performs a check once an hour. If you don’t feel comfortable with this, it is possible to disable this on an organization level 😉
Also new in Exchange 2019 CU11 and Exchange 2016 CU22 is telemetry regarding the mitigation service. When configured, it will automatically upload mitigation related service to Microsoft. Again, this can be disabled as well using the license agreement (enabled by default).
When installing this update you will see change in the License Agreement:
The default is I accept the license agreement and will share diagnostics data with Microsoft (recommended), but you can select other as well of course.
When using the unattended install, a new switch is used for accepting the License Agreement.
/IAcceptExchangeServerLicenseTerms_DiagnosticDataON – when you allow to upload diagnostics data to Microsoft
/IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF – when you do not allow to update diagnostics data to Microsoft.
There are also two new prerequisites when installing Exchange 2019 CU11 or Exchange 2016 CU22. Prerequisite software contains now the ‘IIS URL Rewrite Module’ which needs to be installed. The second one is connectivity to the internet for accessing the mitigation service endpoint.
The setup application will check for these prerequisites and will generate an error when they are not met:
Note. The internet connectivity is not shown in this screenshot.
Note. There are no schema changes when upgrading from Exchange 2019 CU10 or Exchange 2016 CU21, but there are changes when upgrading from previous releases.
After installing the updates, you will see the new services when opening the services MMC snap-in:
Or when using the Get-Service MSExchange* PowerShell command:
To check the status in the Exchange organization, you can use the Get-OrganizationConfig | Select mitigations command:
To disable the mitigation service, execute the following command:
Set-OrganizationConfig -MitigationsEnabled:$False
By default, only one mitigation is installed, this is the EEMS heartbeat probe. You can check the installed mitigations by navigating to the Exchange scripts directory and execute the Get-Mitigations.ps1 script:
As with any Cumulative Update, please test this CU in your lab to see if all works well for your environment. Also have a look at the telemetry configuration (is that allowed in your organization?) and at the automatic configuration changes made by the EEMS (I can hear CISO starting to complain).
More information and downloads regarding the Cumulative Updates can be found here:
When you want to check which updates are installed on an Exchange server you can navigate to Control Panel | Programs | View Installed Updates and you will see a list of installed updates, including the Exchange Security Updates.
When running Exchange 2019 on Windows 2019 Server Core there is no Control Panel and you can view the registry to check which updates are installed. Use the following command to view all installed Updates:
When installing a Database Availability Group in Exchange 2019 running on Windows 2019 Server Core, I got IP address configuration errors when creating the DAG. It did succeed, but when running the Get-DatabaseAvailabilityGroupNetwork command in EMS is get a ‘Misconfigured’ warning:
This will be a DAG with two networks. One Mapi network (10.38.96.0/24) for clients, and one replication network (192.168.0.0/24).
The requirements for an additional replication network in a DAG are:
No default gateway configured
No DNS servers configured
IP address must not be registered in DNS
When using Windows 2019 Server Core, the first two can be configured using the SCONFIG utility, but the last one is not that simple (but in Windows 2019 Desktop Experience it is just a matter of deselection the “Register this connection’s address in DNS” option when configuring the network interface).
When using Windows Server Core, you can use the Set-DnsClient command to configure this setting, combined with the Get-NetAdapter command.
Execute the Get-NetAdapter command to retrieve the network interfaces. In the following screenshot “Ethernet” is the regular Mapi network interface, “Ethernet 2” is the replication network interface.
To configure the DNS registration option, execute the following command:
Jaap Wesselius 
You must be logged in to post a comment.