Last month Microsoft released cumulative updates for Exchange 2016 and Exchange 2019. Once you get the H1 2022 cumulative updates, be sure to grab the security updates released in May.
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.
The security updates (SUs) are now available as self-extracting executables, which means they will automatically elevate with administrative rights. However, the MSP delivery method requires admins to manually instruct the update to run with administrative rights. If admins missed this step, the security update could apply incorrectly, causing an outage in Exchange. The MSP delivery method is still available via the Microsoft update catalog, should admins prefer it. However, the EXE delivery method is better for admins wanting to install the security update manually. Note that this does not change the delivery method for cumulative updates–that remains the same.
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:
Eliminating the last on-prem Exchange server (maybe)
Most organizations that leverage Exchange Online (and other Office 365 workloads) will synchronize their identities from on-premises to the cloud. This way, organizations can have a single set of credentials (username and password) for both on-prem and cloud workloads. This makes it significantly easier for users to consume resources regardless of where they are housed.
For Exchange Online, this model requires recipient management to be performed against the on-premises directory and then synchronized to the cloud. The challenge was that this previously required an Exchange server to be available on-premises to perform these actions.
With Exchange 2019 CU12, Microsoft made a number of advancements to the Exchange 2019 management tools. The Exchange 2019 management tools can now be used for recipient management without an on-premises Exchange server. If you were only keeping an Exchange server around for recipient management, you can now shut it down.
There are, however, some limitations.
The first is that the Management Tools are PowerShell only. Once you eliminate the last Exchange server, you will no longer have a GUI. This means your administrators and helpdesk must be comfortable with PowerShell. However, third-party products do exist to provide a GUI (such as this one from Steve Goodman).
The second is the loss of RBAC (“Role-Based Access Controls“) on-premises. As a result, only domain admins or members of the “Recipient Management EMT” security group will be able to manage Exchange Online recipient attributes.
Note: The Add-PermissionForEMT.ps1 script creates the Recipient Management EMT security group.
The third is that auditing and logging recipient management tasks are no longer captured. So, if you need to track who made a change to a mailbox, such as changing an email address, this will not be a fit for your organization.
The fourth is that Microsoft is still testing this in complex scenarios, such as multi-forest, multi-domain, and multi-tenant. Therefore, it might be best to hold off on shutting down Exchange for complex environments until Microsoft provides more support messaging for these scenarios.
Lastly, is if you use Exchange on-prem for mail relay. The benefit of using Exchange on-prem is it allows firewall administrators to lock down outbound SMTP to a known set of internal IPs. In addition, device and application owners do not need to worry about the relay requirements of Office 365. They can simply use an on-premises Exchange server for mail relay. Exchange Server then leverages a forced TLS connection to Office 365.
To eliminate the last Exchange server, you must use the Exchange 2019 CU12 management tools from a domain-joined workstation.
- For those using Exchange 2019 for recipient management, you will need to run /PrepareAllDomains from the Exchange 2019 CU12 ISO and install the Exchange 2019 CU12 management tools on a domain-joined workstation. If upgrading from CU9 or earlier, you will need to do a schema upgrade.
- For those maintaining older management servers, such as Exchange 2013 or 2016, you must upgrade your schema to Exchange 2019 CU12. You do not, however, need to deploy an Exchange 2019 server. Once your schema is upgraded, you can install the Exchange 2019 CU12 management tools on a domain-joined workstation.
- For those in a greenfield environment, you simply need to extend your schema to Exchange 2019 CU12 and then deploy the Exchange 2019 CU12 management tools on a domain-joined workstation.
Once you have the management tools installed and have confirmed they meet the needs of your organization, you can then determine whether you can eliminate your last on-prem Exchange server. For more information on that process, including the steps to make that happen, check the following article: Manage recipients in Exchange Server 2019 Hybrid environments
Exchange 2019 now eligible for a free hybrid key
For customers who need to maintain an Exchange Server on-premises for recipient management, Microsoft has now extended the free hybrid key to Exchange 2019 installations. This was previously only available for Exchange 2016.
To get this free hybrid key for Exchange 2019, update to CU12, and download the latest version of the Hybrid Configuration Wizard. You will be granted a key when you run the Hybrid Configuration Wizard.
Service Model Changes
As you may have noticed from the blog title, Microsoft has shifted its cumulative updates (CUs) from a quarterly to a semi-annual release cadence. Microsoft made this change based on feedback from its customers. The new update schedule with be March (for the H1 update) and September (for the H2 update).
This does not impact security updates (SUs) released monthly or hotfixes that are released as needed.
Support for Windows Server 2022
Exchange 2019 CU12 also includes support for Windows Server 2022. This means that Exchange 2019 can now be installed on Windows Server 2022. In a future Exchange update, Microsoft plans to add support for TLS 1.3, which is native to Windows Server 2022. Until then, Exchange 2019 will continue to leverage TLS 1.2. This update also supports Windows Server 2022 domain controllers for Exchange 2019.
New Bug Bounty for Exchange Server
Following the HAFNIUM exploits last year, Microsoft has added a new bug bounty program for Exchange Server. Individuals can now receive monetary rewards for submitting security vulnerabilities found on a supported version of Exchange Server running on the latest fully patched version of Windows.
If you are current on your Exchange updates, these cumulative updates will not extend the schema. You will, however, need to run /PrepareAllDomains after installing this cumulative update.
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAllDomains
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAllDomains
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 complete list of schema numbers, check this article.
Once you install the May security update, you will need to rerun the /PrepareAllDomains command listed above. However, rather than running it from the install file, you must run SETUP from your Exchange bin directory. This is located at “%ExchangeInstallPath%bin” or “C:\Program Files\Microsoft\Exchange Server\V15\Bin”.
Here are some articles I thought you might like.
- RunAs Radio #818 – Email Transport Security
- RPC/HTTP & Security Defaults may prevent Outlook reconfiguration after migrating to EXO
- Configure global mail flow settings from the new Exchange Admin Center
- Outlook 2013: Your account is in a bad state
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.