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
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.
Installation tips
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
or
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”.
Further Reading
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.
Hi Gareth
Is it possible to decommission the Exchange Hybrid server without installing the Exchange 2019 straight away? I have a scenario where I have an Exchange 2016 Hybrid I want to get rid of but the Forest and Domain Functional level are 2012 rather than 2012 R2. The customer will have to upgrade their environment in the future and I would like to install the 2019 tools when they upgrade their forest and domain functional level. However I wish to decommission the Hybrid 2016 Exchange before that happens.
Is this possible?
Hey David,
It’s possible, but you will put yourself in an unsupported configuration. For example, during the period that Exchange 2016 is decommissioned and before you install the Exchange 2019 management tools, the only way to manage synced user objects in Exchange Online will be by direct attribute manipulation through the attribute editor in Active Directory Users and Computer (or ADSI Edit). This is unsupported by Microsoft and prone to misconfiguration.
I assume you are not using Exchange 2016 for mail relay purposes either? This is the most common block I see for many organizations who want to eliminate their last Exchange server on-prem. For example, no on-prem devices or applications using Exchange 2016 to relay to Exchange Online?
I recommend keeping the Exchange 2016 server active until you can raise the forest/domain functional levels and then deploy the Exchange 2019 management tools. That said, if the concern is around the security of the Exchange 2016 server (and assuming you have migrated all mailboxes to Exchange Online, moved Autodiscover to Exchange Online, and don’t need to route mail to an on-prem application), you can remove all inbound access (HTTPS and SMTP) to your Exchange 2016 server.
Hello Gareth,
I have 2 questions, if I may:
– I have installed the EMT on a jump server, and everything seems to be working fine, but we are trying to make the onboarding script, running on a different server, to remotely call the “Add-PSSnapin *RecipientManagement” command, and then to “Enable-RemoteMailbox”. This does not work. I did not install the RSAT tools in the process of installing EMT, can this be the reason?
– Can the EMT be installed on multiple servers, or would that be an issue? I can’t find this info anywhere, and if it is possible, I would install it on the scripting server as well, so the onboarding script does not have to remotely call the commands, and all our issues would be solved :).
Thanks a bunch in advance!
Hey Emil,
You can install the Exchange Management Tools on as many machines as you want. It does not just have to be servers either; it can totally be workstations. Think of the Exchange Management Tools as no different than if you installed the RSAT tools on your own workstation.
I am fairly certain Remote PowerShell will not work because there is no PowerShell virtual directory installed or listening as part of these tools. It would be similar to trying to remote to the RSAT tools on a machine. I hope that helps.
Hi Gareth,
Excellent site. Quick question, can we install the latest exchange 2019 management tools (only) and continue to run the latest Exchange 2013 (Latest CU fully up to date) ? We have an exchange 2013/EXO hybrid environment, and I’d like to start using the management tools, but I just want to confirm running the AD schema update (for 2019) won’t break my 2013 install, as that server is currently the only way I have to manage mail related attributes (directory sync’d using Azure AD Connect V2) and adding the management tools on a windows 10 64bit workstation would hopefully give me a secondary way…. as long as doing so doesn’t break my 2013 server, as we still have a few mailboxes that have not been migrated yet.. Any gotcha’s to be aware of? Everything I’ve read about coexistence says this should be supported, but just wanted to run it by you as you seem you’ve already done the legwork on this.
Hi Gerry,
Yes, Exchange 2013 can coexist with an Exchange 2019 schema and the Exchange 2019 management tools. As long as Exchange 2013 is CU21 or later. I recommend being on the latest CU/SU for 2013. More info on coexistence here – https://docs.microsoft.com/en-us/exchange/plan-and-deploy/system-requirements?view=exchserver-2019#supported-coexistence-scenarios-for-exchange-2019
I have a rare situation: Win Defender from Hyper-V host .. delete the VM containing Exchange 2019. I undelete the VM file but was unusable. Now looking to clean Exchange Organization from AD to be able to start like very first Exchange setup. Please please advice !. ANY but ANY advice will be warm welcomed. I’m like this since 2 weeks, it is a huge disaster.
Hi Bogdan,
You can treat the server as a total loss and try this recovery method. https://supertekboy.com/2017/06/26/recover-exchange-server-total-loss/.
Otherwise, you may want to open a case with Microsoft support as it will likely involve cleanup in ADSI Edit. I wouldn’t recommend tackling this yourself, but if you do, ensure you have a very good backup of Active Directory that you are 100% sure you can restore from if needed. That said, I would never recommend deleting the Exchange Organization.