How To Apply Updates To Exchange 2010

As you know, MS periodically releases updates for Exchange and at the time of this writing (9DEC13) the latest Exchange 2010 release is SP3 RU3. Assuming you have a DAG and CAS Array(s), you're users will experience no downtime.

Here's how to roll out updates across your Exchange servers, from start to finish.

The upgrade process always goes in this order:

1. Client Access Servers (with the internet-facing CAS first)
2. Hub Transport and Edge Transport servers
3. Mailbox servers
4. Unified Messaging servers
5. Any Exchange Management tools you have installed on other servers or workstations.

 **Note** To save time, I've never had any problems updating CAS and HT servers in separate sites concurrently. For instance, I always update CAS1A in Site A and CAS1B in Site B at the same time. Just make sure you have a good checklist so you know where you stand on each machine.

Updating Client Access Servers

First, you need to remove the CAS server you are updating from the Network Load Balancing (NLB) cluster.

You can remove a CAS array member from the NLB two different ways:
- Issue a Stop command
- Issue a Drainstop command 

The difference is: Stop will immediately kill all client connections; Drainstop will not accept new connections, but will continue serving existing connections until they disconnect.

To issue a Drainstop launch Network Load Balancing Manager, right-click on the desired server, choose Control Host and then Drainstop.

Alternately, choose Stop.

**Note** I always use the Stop command. Not to be "the typical mean admin", but clients will reconnect automatically with the user being none the wiser, and some users never disconnect so we'd be there forever. We've got better things to do, right? :)

Next, Right-click the server and choose Properties. Set the state of the server to Stopped. 

This will prevent it from automatically accepting client connections after a reboot (if the update requires a reboot), and it will allow you time to make sure that the updates went well and services start, before rejoining it to the NLB cluster.

Stop Conflicting Services

Non-Exchange services such as A/V, monitoring, backups and such interfere with Exchange updates, so we'll need to stop them first.

If you Run Forefront, to stop it just run the command:

  fscutility /disable

Disabling Monitoring

Monitoring should be disabled, or placed into maintenance mode before the update is performed. Otherwise false alarms will be driving you and the other Admins crazy.
 
Backing Up the Server

Make sure you have a good recent backup. I've never had an Exchange update kill a server, nor have I heard of anyone having that happen...but just to be safe, back it up.

Updating the Server

Update rollups come in an .MSP file (Windows Installer Patch) that is applied to the server. Run the file or launch it from a CMD.
Service packs come in an .exe. These are brand new Exchange setup files and they're installed by running setup in upgrade mode, which can be run in the GUI or CMD mode.

Go ahead and run the update.

Depending on the type of patch, it will run through pre-reqs, health checks, etc and then through the actual install.

 **Note** All Exchange updates take a while to install (roughly 20-30 minutes for each server in my experience, not including your prep work) and you'll want to install them across the entire organization so you don't have mismatched versions. So, allow enough time to complete.

Verifying the Update

After the update is finished and you've rebooted (if necessary) you'll need to check it's vitals.

Event Logs – look for errors or warnings in the Application Logs
Services – make sure that all Exchange services that you need running, are running (some are stopped if you don't use them like POP3).

Check Build Version

To check the build number to ensure that update installed, run the command:

  Get-ExchangeServer | fl name,edition,admindisplayversion

Also ensure that the patch is listed in the Installed Updates in Control Panel.

**Note** Every other time I've installed a Rollup, it doesn't report the correct build number, but the patch is listed in Installed Updates...I've heard of this happening to other Admins as well.

Returning the Server to Production

If the update went well, you can bring the server back into production.

Re-enable services such as A/V, and backups.

For Forefront, run:

  fscutility /enable

In the NLB Manager, right-click the server, then choose Control Host and then Start.

Right-click the server and choose Properties. Set the state of the server to Started.

Re-enable monitoring.

After you're done with the first CAS array member, move on to the next one until you've completed all CAS servers.

Updating Mailbox Servers

To update DAG members without causing downtime, you'll need to move the active databases off of the server so that it can be patched (and rebooted if needed).

In Exchange 2010 SP1, Microsoft included a couple scripts to make maintenance a lot easier. (I'm assuming you've at least got SP1 installed; if you're running RTM leave a comment and I'll put those instructions in here as well.)

Open the Exchange Management Shell then cd to the Scripts folder by running:

   cd $exscripts

Next put the DAG node into maintenance mode by running this script:

  .\StartDagServerMaintenance.ps1 -servername "ServerName"

**Note** Replace "Server Name" with the name of the Mailbox server you are patching.

The script will automatically:

- Execute Suspend-MailboxDatabaseCopy on the database copies.
- Pauses the node in Failover Clustering so that it can not become the Primary Active Manager.
- Suspends database activation on each mailbox database.
- Sets the DatabaseCopyAutoActivationPolicy to Blocked on the server.
- Moves databases and cluster group off of the designated server.

Stopping Conflicting Services

If the mailbox server is running any non-Exchange services, like A/V or backups, these need to be disabled.

If you Run Forefront, to stop it just run the command:

  fscutility /disable

Disabling Server Monitoring

Monitoring should be disabled, or placed into maintenance mode.

Updating the Server

Update rollups come in an .MSP file (Windows Installer Patch) that is applied to the server. Run the file or launch it from a CMD.
Service packs come in an .exe. These are brand new Exchange setup files and they're installed by running setup in upgrade mode, which can be run in the GUI or CMD mode.

**Note** All Exchange updates take a while to install (roughly 20-30 minutes for each server in my experience, not including your prep work) and you need to install them across the entire organization so you don't have mismatched versions. Allow enough time to complete.

Verifying the Update

After the update is finished and you've rebooted if needed, check it's vitals.

Event Logs – look for errors or warnings
Services – make sure that all Exchange services that you need to be running, are running.

Check Build Version

To check the build number to ensure that update installed, run the command:

  Get-ExchangeServer | fl name,edition,admindisplayversion

Also ensure that the patch is listed in the Installed Updates in Control Panel.

Returning a DAG Member to Production

Fire up the EMS and cd to the Scripts folder.

   cd $exscripts

Next take the DAG node out of maintenance mode by running:

   .\StopDagServerMaintenance.ps1 -serverName "Server Name"

**Note** Replace "Server Name" with the name of the Mailbox server you are patching

The script will automatically reverse each of the actions made by StartDagServerMaintenance.ps1 except that it will not move active mailbox databases back to the server.

To move the active mailbox databases go to the next mailbox server in the DAG that you plan to patch, run StartDagServerMaintenance.ps1 and specify the newly updated server as the target.
After you're done with the first DAG member, move on to the next one until you've completed all DAG and Standalone Mailbox servers.

Rebalance Mailbox Databases in the DAG

After you have completed the updates on all DAG members you can rebalance the DB's across the DAG easily with a PS script.

To rebalance the mailbox DB's back to their preferred homes, cd to the Scripts folder:
 
  cd $exscripts

Then to redistribute the DB's by activation preference, run:

  .\RedistributeActiveDatabases.ps1 -DagName "DAG Name" -BalanceDbsByActivationPreference -Confirm:$False

**Note** Change "DAG Name" to proper name of DAG

**Important** Once a database has been made active on a member of the DAG that has been updated, it cannot be made active on a prior patch-level DAG member again. This means that you will need to finish your entire DAG upgrades for your DAG to function properly.

When you've finished with all Mailbox servers, re-enable services such as A/V and backups. The reason you'll want to wait until you've finished and have all databases back in there preferred place is; backups will almost always effect database seeding and prevent you from moving them for quite a while...I unfortunately know this first-hand :(

Upgrading Other Server Roles

For Hub Transport, Edge Transport, and Unified Messaging servers there are not any special steps required aside from sticking to your high availability scheme.

That's it, you should be all patched up!