SuperTekBoy

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:

Exchange 2019 Cumulative Update 12 | KB5011156 | May 2022 Security Update

Exchange 2016 Cumulative Update 23 | KB5011155 | May 2022 Security Update

Exchange 2013 May 2022 Security Update | KB5014260

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