Instalar Cumulative Updates en Exchange 2016

This article will demonstrate the step by step process for installing cumulative updates for Exchange Server 2016.



Before you install any cumulative updates on your Exchange 2016 servers, you should first:

  • Download the cumulative update from Microsoft. Do not download from any third party websites. You can download the latest cumulative update and upgrade an Exchange 2016 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, such as custom OWA login pages, web.config changes, registry changes, or third party add-ons. Generally speaking you do not need to re-apply standard Exchange configurations that are set via the Exchange Admin Center or Exchange management shell (e.g. changing default message size limits).
  • Verify that your Exchange SSL certificates have not expired.


Comprehensive lists of known issues with cumulative update installation generally do not exist, however to improve your awareness of issues experienced by other customers, you should read the comments on the Exchange team blog entry for the relevant cumulative update, and check the TechNet forums for other reported issues.

You should also be aware of the following issues:


Cumulative updates for Exchange 2016 should be installed in the internet-facing site first, before installing in other sites in the organization.

  • Mailbox servers are updated first
  • Edge Transport servers can be updated last

For load-balanced servers and Exchange 2016 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.


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.


Most cumulative updates will include Active Directory schema changes, as well as other updates such as changed 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 in advance of 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.

  • Install-Windowsfeature RSAY-ADDS

Before applying the schema update follow the steps provided by Michael B Smith to retrieve the existing Exchange schema version, so that you can compare it before and after the AD preparation steps have been completed to verify that the schema update was applied.

  1. Run setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms (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)
  2. Run setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
  3. Run setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms in each domain in your forest that contains Exchange servers or mailboxes. If you have a single domain, the previous step has already done this for you.

When the Active Directory changes have been applied, on each server run the upgrade.


For Exchange 2016 Mailbox and Edge Transport servers, whether they are standalone, load-balanced, or part of a DAG, use the following procedure.

01..- Draining Hub Transport Component

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 EX2016SRV1 –Component HubTransport –State Draining –Requester Maintenance
  • Redirect-Message -Server EX2016SRV1 -Target

02.- If is a DAG member

If the server is a DAG member, run the following commands. If your server is not a DAG member, skip to the command for setting ServerWideOffline.

  • Suspend-ClusterNode –Name EX2016SRV1

Disable database copy auto-activation. This command will also move any active database copies to other DAG members, assuming there are other healthy DAG members available.

This is not instantaneous; it can take several minutes for the moves to occur. We’ll check on it shortly anyway.

  • Set-MailboxServer EX2016SRV1 –DatabaseCopyActivationDisabledAndMoveNow $true

Make a note of the database copy auto-activation policy on the server, so you can set it back to this value at the end of maintenance.

  • Get-MailboxServer EX2016SRV1 | Select DatabaseCopyAutoActivationPolicy

If the policy is not already set to “Blocked”, run the following command to set it.

  • Set-MailboxServer EX2016SRV1 –DatabaseCopyAutoActivationPolicy Blocked

Check for any database copies that are still mounted on the server. This command should return no results. If any database copies are still active on the server, and there are other DAG members that host copies of the database, perform a manual switchover.

  • Get-MailboxDatabaseCopyStatus -Server EX2016SRV1 | Where {$_.Status -eq “Mounted”}

Place the server into maintenance mode.

  • Set-ServerComponentState EX2016SRV1 –Component ServerWideOffline –State InActive –Requester Maintenance

For servers that are in a load-balanced pool:

  • Verify that the load balancer health checks have taken the server out of the pool or marked it as offline/inactive.
  • If the load balancer does not automatically do this, manually mark the server as offline/inactive.

For servers that are in a DNS round robin group, remove the DNS record for this server’s IP address.

Before you run Exchange setup to install the cumulative update:

  • Perform a restart of the server to clear any pending reboot status that will stop Exchange setup from running.
  • Verify that the PowerShell execution policy is set to Unrestricted as per KB981474.

After the restart, launch an elevated CMD prompt, and run the following command from the folder where the Exchange setup files are located:

  • setup /m:upgrade /IAcceptExchangeServerLicenseTerms

Install Cumulative Update (CU1)

After the cumulative update has installed, restart the server.

  • Restart-computer

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. Note, if the server is not a DAG member, then only the first and last commands are necessary.

If the server is a DAG member, use the database copy auto-activation policy value that was set on the server prior to being placed into maintenance mode (the default is “Unrestricted”).

  • Set-ServerComponentState EX2016SRV1 –Component ServerWideOffline –State Active –Requester Maintenance
  • Resume-ClusterNode –Name EX2016SRV1

  • Set-MailboxServer EX2016SRV1 –DatabaseCopyAutoActivationPolicy Unrestricted
  • Set-MailboxServer EX2016SRV1 –DatabaseCopyActivationDisabledAndMoveNow $false
  • Set-ServerComponentState EX2016SRV1 –Component HubTransport –State Active –Requester Maintenance


After deploying an Exchange 2016 cumulative update there are some post-installation tasks that you should perform.


Throughout the update process the database copies in your DAG will have been moved between DAG members, possibly multiple times. If you want to return your active database copies to their most preferred DAG member (aka “rebalancing the DAG”), use the PowerShell script supplied by Microsoft.

  • cd $exscripts
  • \RedistributeActiveDatabases.ps1 -DagName EX2016DAG01 -BalanceDbsByActivationPreference


After you have completed updating your servers you will need to re-apply any customizations that you had documented during the preparation steps above.


Here are some suggestions for health checking your Exchange 2013 servers after applying updates.

  • 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.
  • Check the database activation policy for each Mailbox server – verify that each Mailbox server that is in a DAG has the correct database activation policy for your environment.
  • Check server component status – use Get-ServerComponent to verify that you have not left any servers in maintenance mode.
  • Run Exchange Analyzer to check for best practices compliance.

The Test-ExchangeServerHealth.ps1 script can perform some of the steps above for you. You should also consider running one or more tests from to verify client connectivity and inbound mail flow are working.

Be the first to comment

Leave a Reply