Installing Exchange 2013 CU1 on DAG member servers - some care and maintenance mode required

Once Microsoft released Exchange 2013 CU1 on April 2, thoughts turned to installing the new software. If you already have Exchange 2013 RTM on your servers, CU1 is installed using a build-to-build (B2B) upgrade (setup /m:upgrade). Because a cumulative update is essentially a brand new version of Exchange that can be installed on a new server without the need to first install the RTM version of Exchange 2013, it takes a little longer for the installation to complete than when you apply a roll-up update to Exchange 2007 or Exchange 2010. However, the installation is straightforward and with a little planning, should not cause any concern.

These are the steps that I followed to successfully update a number of multi-role Exchange 2013 servers running on Windows 2012:

The only issue I ran into was when Setup queried the lack of the Microsoft Office 2010 Filter Pack on the server. This is technically correct insofar as transport rules and content indexing won’t be able to process OneNote and Publisher attachments if you do not install the filter pack. However, it’s safe to ignore the warning as Search Foundation includes the necessary filters for the vast majority of file formats encountered in email, which is what I did.

If you run Exchange 2013 servers in a DAG, you need to put the server into maintenance mode before you apply the CU1 update to inform Exchange’s Managed Availability monitoring and recovery infrastructure that the server is under administrator control and is not a candidate to accept workload. For example, you would not want Active Manager to attempt to activate a database copy on the server while the update is proceeding.

Exchange 2013 includes the Set-ServerComponentState cmdlet to control server components. These commands instruct server ExServer1 to drain down its transport queues and not accept any further messages, redirect any new messages to another transport server, suspend it from the cluster that underpins the DAG, block database activation and move any databases that are currently active on the server, and then set the server into an “inactive” state for maintenance.

Set-ServerComponentState –Identity ExServer1 –Component HubTransport –State Draining –Requester Maintenance

Redirect-Message -Server ExServer1 -Target ExServer2

Suspend-ClusterNode –Name ExServer1

Set-MailboxServer –Identity ExServer1 –DatabaseCopyActivationDisabledAndMoveNow $True

Set-MailboxServer –Identity ExServer1 –DatabaseCopyAutoActivationPolicy Blocked

Set-ServerComponentState –Identity ExServer1 –Component ServerWideOffline –State InActive –Requester Maintenance

Once CU1 is successfully installed, you can reverse the process with commands to bring the server back into an active state, resume it within the cluster, allow database activation within the DAG, and resume normal transport processing.

Set-ServerComponentState –Identity ExServer1 –Component ServerWideOffline –State Active –Requester Maintenance

Resume-ClusterNode –Name ExServer1

Set-MailboxServer –Identity ExServer1 –DatabaseCopyAutoActivationPolicy Unrestricted

Set-MailboxServer –Identity ExServer1 –DatabaseCopyActivationDisabledAndMoveNow $False

Set-ServerComponentState –Identity ExServer1 –Component HubTransport –State Active –Requester Maintenance

If you want some scripts to do the typing for you, check out the ones published by Michael van Horenbeeck.

Servers that return from maintenance mode won’t support any active databases so you should consider rebalancing workload within the DAG by switching over active databases from other servers, not least the server that is next due for the upgrade.

All in all, the Exchange B2B upgrade mechanism is now a pretty well-oiled machine that works without too much fuss and bother. Upgrading an Exchange 2013 server to CU1 won’t be painful; coping with the need to update servers every thirteen weeksto keep current might be a different matter.

Follow Tony @12Knocksinna