Exchange Server: HowTo for installing updates

Testing, testing, testing and checking requirements

As Exchange is a central and important system in many companies, it is advisable to test new updates in a test environment. The test environment should correspond as closely as possible to the productive environment. Of course, other applications/processes/services that are dependent on Exchange must also be tested as far as possible. Everyone must decide for themselves how far they want to or can go in the tests.

The compatibility of all dependent software (e.g. backup software, virus scanner, archive solution, etc.) must also be checked, especially in the case of major updates or many changes in the release notes.

Also very important: Read the release notes and check whether there are changes to important functions that are important for the company.

Download updates

Exchange 2013/2016 updates are quite large, as they are always the complete installation sources. This has the advantage that the updates can also be used for reinstallation without having to download the RTM version, service pack or update rollup first.

On the other hand, you don't want to waste unnecessary time during the maintenance window waiting for the download. The CU2 for Exchange 2016 has just under 7 GB.

Create backup

Before installing the updates, a current backup should be created, not only of the Exchange servers and databases, but also of the domain controllers and the Active Directory. At this point, you can also briefly consider whether the restore has already been tested and whether it is known what to do in the event of a restore.

Preparation for the update

The preparation of Exchange 2013/2016 for the import of updates depends on the environment.

In an Exchange 2013 organization that contains dedicated Client Access and Mailbox Servers, all Mailbox Servers should be updated first, followed by the Client Access Servers.

In an Exchange 2016 organization, it is best to start with the server that is currently least busy.

If there are upstream load balancers for the client access servers, the server to be updated should be removed from the load balancing network. The procedure for this varies depending on the load balancer used.

Before the update, the event log should also be checked for entries that do not belong there. Errors in the event log that occur before the update process should be corrected or at least noted. Otherwise, in the event of a problem, you may end up going through "unimportant events" that have been there for years...

Before starting the update procedure, you should also take a look at the databases: which databases are mounted and is the index OK?

Start Exchange Maintenance Mode

From here it gets serious. Exchange 2013 / 2016

Set-MailboxServer "SERVERNAME" -DatabaseCopyActivationDisabledAndMoveNow $True
Set-ServerComponentState -Identity "SERVERNAME" -Component HubTransport -State Draining -Requester Maintenance
Suspend-ClusterNode -Name "SERVERNAME"
Set-MailboxServer -Identity "SERVERNAME" -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState "SERVERNAME" -Component ServerWideOffline -State InActive -Requester Maintenance

 

Install updates

The server is offline. For larger environments with several locations and possibly distributed Exchange servers, the schema should first be updated manually when the update performs a schema update. The Active Directory schema can be updated manually with the following command:

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms 

After updating the schema, the replication of the domain controllers must be awaited.

Note: The schema update is also carried out by the update process. If there is only one Exchange server and only one small Active Directory with one location, the schema update can also be updated directly via the Exchange update process. The Exchange does not have to be in maintenance mode for the schema update either, so the schema update can also be carried out in the "Preparing for the update" section.

The updates can now be installed on the first server.

Exit Exchange Maintenance Mode

Maintenance mode must be ended after installing the updates.

Important: Don't forget to exit maintenance mode! Otherwise all databases will be offline on the last server at the latest

Set-MailboxServer -Identity "SERVERNAME" -DatabaseCopyAutoActivationPolicy Unrestricted
Resume-ClusterNode -Name "SERVERNAME"
Set-ServerComponentState -Identity "SERVERNAME" -Component HubTransport -State Active -Requester Maintenance
Set-MailboxServer -Identity "SERVERNAME" -DatabaseCopyActivationDisabledAndMoveNow $False
Set-ServerComponentState "SERVERNAME" -Component ServerWideOffline -State Active -Requester Maintenance

 

The server is now back in normal operation. The event log should now also be checked for entries. It is also advisable to take another look at the databases and their index.

If the server was previously removed from a load balancing network, it can be resumed.

Update additional servers / update servers in parallel

Updates on Exchange servers can be installed in parallel on several servers. However, with Exchange 2013 it is important to ensure that the mailbox servers are only updated when the Exchange roles are running on separate servers. If the update includes a schema update, the schema must be updated first and then the replication must be waited for, only then should further servers be updated. Depending on the environment, attention must be paid to the databases and mailbox servers. With 10 servers, it is certainly not advisable to update 9 at the same time and concentrate the entire load on one Exchange server.

Possible errors during the update

Errors can of course also occur during the update process. Here is a small selection of common problems and their solutions:

Error:
Setup can't continue with the upgrade because the powershell (15352) has open files. Close the process, and then restart Setup.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.ProcessNeedsToBeClosedOnUpgrade.aspx

Error:
All Unified Messaging language packs other than US English (en-US) must be uninstalled before you can upgrade the Mailbox server role. Detected language packs: de-DE"
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdditionalUMLangPackExists.aspx

Warning:
Setup can't verify that the 'Host' (A) record for this computer exists within the DNS database on server 172.16.14.10.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.HostRecordMissing.aspx

The first error can be rectified quickly, as all relevant information is already mentioned here. A PowerShell process with the ID 15352 is still running and is interfering with the update. The process is therefore terminated:

Stop-Process -Id "Process ID from error message"

The second error is a bit trickier. Exchange Setup expects all UM language packs except en-US to be uninstalled. In this case, the language pack de-DE interferes. All language packs can be displayed with the following command:

Get-UMService

However, the ISO or setup of the currently installed Exchange version is required for uninstallation. If the Exchange server is at patch level CU1, as in this case, the installation sources of CU1 are required to uninstall the language pack. It is therefore advisable to keep the corresponding CUs. In my case, I need the CU1 to uninstall the language pack. The uninstallation can then be initiated with the following command:

setup.exe /RemoveUMLanguagePack:Language pack

The last entry is a warning. The setup cannot determine whether there is a HOST-A entry for this server on the DNS server. You should therefore check here whether the DNS server has a corresponding entry:

The screenshot above shows my test environment, the entry exists, Exchange is installed on a domain controller in this case, so I can skip the warning. However, there are problems if an alternative DNS server is stored in the DNS configuration of the Exchange server that is not a domain controller, for example a router or public DNS server:

This entry should be removed beforehand and should not be set again later.