In this guide, we’ll take you through the process of installing cumulative updates for Exchange Server 2019, using new features to simplify the update process introduced in the 2023 H1 CU13 patch.
The process of installing cumulative updates on Exchange 2019 involves the following steps:
- Prepare by downloading update files, checking backups, and reviewing known issues.
- Update mailbox servers in internet-facing sites.
- Update mailbox servers in the remaining internal sites (if any).
- Update Edge Transport servers (if any).
- Perform health checks after the upgrade.
Preparation
Before you install any cumulative updates on your Exchange 2019 servers, there are several things you should do to prepare:
- Download the cumulative update from Microsoft directly. Exchange Server 2019 CU files are now available without sign-in from the official list of Exchange Server updates.
- You can download the latest cumulative update and upgrade an Exchange Server 2019 to the latest version in one update – you do not need to install all of the cumulative updates released between your current version and the latest version.
- Verify that you have confirmed working backups of your Active Directory.
- Verify that you have confirmed working backups of your Exchange servers and databases.
- Verify that you have documented any customizations to your Exchange server that will need to be re-applied. As of the 2023 H1 Cumulative Update (CU13), custom configuration preservation backs up and restores the most common configuration.
- Verify that third-party add-ons and integrations are compatible with the cumulative update you will be installing.
- Temporarily disable anti-virus software on the server, as this can interfere with the update process.
- Verify that your Exchange SSL certificates have not expired.
- Check the Exchange System Requirements to ensure that any new prerequisites or other changes since your last CU are applied to the server.
Order of Installation
Cumulative updates for Exchange 2019 should be installed on the internet-facing site first before installing on other sites in the organization.
- Mailbox servers are updated first.
- Edge Transport servers can be updated last.
For load-balanced servers and Exchange 2019 DAG members, there will be a period of time during which all servers are not at the same version.
This is expected and supported, but you should plan to continue upgrading servers so that they are all updated within a reasonable period of time.
You can balance that recommendation with the need for caution, e.g. waiting for issues to arise on the first upgraded server before deploying to the other servers. As a rule of thumb, aim for “days or weeks” rather than “months” between server upgrades, depending on the size of your environment.
TEC Talk: What to Do About Exchange On-Premises After Microsoft Starts to Block Messages
Hear what Tony Redmond has to say about what might happen if your org is using older on-premises Exchange servers.
Deploying Exchange 2019 Cumulative Updates
The process for installation is as follows:
- Perform the Active Directory schema changes and updates. This is performed once for the entire Active Directory environment. You do not need to repeat this for each server being upgraded.
- Upgrade servers. For each server in turn:
- Place the server into maintenance mode.
- Install the update.
- Perform testing.
- Take the server out of maintenance mode.
- Perform post-installation tasks:
- Rebalance database availability groups.
- Restore customizations.
- Perform a health check of the environment.
Active Directory Schema Changes and Updates
Most cumulative updates will include Active Directory schema changes, as well as other updates, such as changes to RBAC roles. In some cases, the existence of changes will depend on which previous CU you’re upgrading from. So as a general rule, you should plan for AD schema changes and updates to occur.
The AD preparation tasks can be run before your server upgrades, or they can be allowed to run automatically as part of the first server upgrade process. In either case, Enterprise Admins’ and Schema Admins’ rights will be required. And if you’re running the update from an Exchange server, the RSAT-ADDS feature must be installed.
To prepare the AD schema, run the following command, which requires Enterprise Admins and Schema Admins permissions, and must be performed in the same AD Site as the Schema Master on a server with the RSAT-ADDS-Tools feature installed – the Schema Master itself would meet these requirements.
Note that as of the September 2021 updates, you need to suffix /IAcceptExchangeServerLicenseTerms with either _DiagnosticDataON or _DiagnosticDataON depending upon your preference for the collection of diagnostic data.
setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Then, run the following command to prepare the AD:
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Finally, run the following command in each domain in your AD forest that contains Exchange servers or mailboxes. If you have a single domain, the previous step has already done this for you:
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
When the Active Directory changes have been applied on each server, run the upgrade.
Upgrading Exchange 2019 Servers
For Exchange 2019 Mailbox servers, whether they are standalone, load-balanced, or part of a DAG, use the following procedure. For Edge Servers, only use the Transport-related sections.
Exchange Mailbox servers process HTTPS requests from clients, and if your server is a member of a DAG, then it’s also likely you’ll have a network load balancer distributing requests to members. Whilst beginning the DAG server maintenance process should trigger your load balancer’s capabilities to detect an offline node; before you continue, verify that this is configured via your load balancer’s control panel. If it isn’t, consider marking the server offline prior to placing the server in maintenance.
For servers that are in a DNS round-robin group, remove the DNS record for this server’s IP address temporarily. If you don’t, client requests will still attempt to connect to running IIS services on the Exchange Server, even if Exchange isn’t online. If the DNS TTL record is too long (for example, 3600 seconds), consider reducing this before removing the DNS record. During the patching window, a low TTL value, such as 300 seconds, should be appropriate.
To stop mail flow from being processed by the Mailbox or Edge Server, drain the transport services prior to beginning the patching process. This will ensure that a message being processed as patching begins isn’t delayed mid-flow whilst patching completes.
First, from an Exchange Management Shell, Set the HubTransport component to “Draining” and redirect any messages currently in the queue to another server. If you’re running a single Exchange server, you can skip the redirect command.
Set-ServerComponentState <Exchange Server Name> -Component HubTransport -State Draining -Requester Maintenance Redirect-Message -Server <Exchange Server Name> -Target <FQDN of Alternative Exchange Server> Restart-Service MSExchangeTransport
Next, we’ll place the server into maintenance mode and set the server component status to offline. This will disable activation of mailbox copies should a database failover occur. Move active database copies to other DAG nodes, and in the second command, ensure the server components are marked as offline.
cd $exscripts .\StartDagServerMaintenance.ps1 -ServerName < Exchange Server Name> -MoveComment Maintenance -PauseClusterNode Set-ServerComponentState EXCHANGE02 -Component ServerWideOffline -State Inactive -Requester Maintenance
As a final check prior to running the update, validate that the databases on the server are not marked to automatically activate, and that the mail queue is empty:
Get-MailboxServer <Exchange Server Name> | Format-List DatabaseCopyAutoActivationPolicy Get-Queue
Before you run Exchange setup to install the cumulative update:
- Perform a server restart to clear any pending reboot status that will stop the Exchange setup from running.
- Verify that the PowerShell execution policy is set to Unrestricted.
After the restart, launch an elevated CMD prompt from the folder where the Exchange setup files are located:
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade
After the cumulative update has installed, restart the server. When the server has been restarted, perform a basic health check of the server:
- Review event logs for new or excessive errors and warnings.
- Check that auto-start services on the server have started.
You can now remove the server from maintenance mode, mark components on the server as active and after enabling components, restart the transport services to re-enable mail flow. As before, use the Exchange Management Shell:
cd $exscripts .\StopDagServerMaintenance.ps1 -serverName <Exchange Server Name> Set-ServerComponentState <Exchange Server Name>-Component HubTransport -State Active -Requester Maintenance Restart-Service MSExchangeTransport
Validate that the components are active using the following command:
Get-ServerComponentState <Exchange Server Name>| Format-Table Component,State -Autosize
If you have a preference for the database auto activation policy, ensure you restore those settings, and then re-balance the mailbox databases using the following command:
cd $exscripts .\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference:$True
Finally, if you had to manually disable HTTPS traffic reaching the Exchange Server on your load balancer, re-enable the node using its control panel. If you used your load balancer capabilities for node failure detection, then validate that the node is marked as online again and receiving traffic. If you use DNS round robin, ensure you re-add the IP address of the patched node to DNS. Leave the low TTL value while you patch all servers, then consider raising the TTL value to its original value after the patching process for all DAG members is complete.
Post Installation Tasks
After deploying an Exchange 2019 cumulative update, there are some post-installation tasks that you should perform before moving onto the next node.
If you are running Exchange Hybrid, validate mail flow to and from Hybrid Connectors works as expected and that mailbox moves still function correctly when using this node. In the event of an issue, re-running the Office 365 Hybrid Configuration Wizard should re-enable functionality such as the MRSProxy and ensure the Transport connector configuration is correctly set.
Check the cluster nodes are all up – verify that you have not left any DAG members suspended in the cluster by running the Get-ClusterNode cmdlet on one of the DAG members.
Test service health – use the Test-ServiceHealth cmdlet to verify that all required services are running on each server.
Test MAPI connectivity to every database – use the Test-MAPIConnectivity cmdlet to verify that all databases are mounted and accessible.
Check the database copy status for DAGs – use the Get-MailboxDatabaseCopyStatus cmdlet to verify that all database copies, copy/replay queues, and content indexes are healthy.
Test replication health for DAGs – use the Test-ReplicationHealth cmdlet on each DAG member to verify replication health is good.
Summary
Keeping up to date with Exchange Server 2019 Cumulative Updates is essential – as is ensuring security updates are applied. New changes in the most recent cumulative updates reduce the need for backup and restore of common configuration changes. However, you still need to follow basic steps to ensure that you avoid a service outage during planned patching.
You’re missing a command when bringing the server out of maintenance mode – you need to run the below after installing the CU and rebooting
Set-ServerComponentState -Component ServerWideOffline -State Active -Requester Maintenance
Why we should re update the schema and AD domain before updating or upgrading the exchange server, taking in consideration that we have already extended the schema and updated all domains prior the Exchange server deploymnent
Some cumulative updates in Exchange Server are doing changes in the AD schema too.
For more information, you can check this link : https://learn.microsoft.com/en-us/exchange/plan-and-deploy/active-directory/ad-schema-changes?view=exchserver-2019