Applying Service Pack and Rollup Updates on Exchange Server 2010 (Part 1)

by [Published on 16 Jan. 2014 / Last Updated on 16 Jan. 2014]

In this series, the author covers the process of applying Service Packs and Rollup Updates on Exchange Server 2010.

If you would like to read the next part in this article series please go to Applying Service Pack and Rollup Updates on Exchange Server 2010 (Part 2).

In this article series we are going over the step-by-step process to upgrade your servers running Exchange Server 2010 to new Service Packs and Rollup Updates using either GUI (graphical user interface) or command line.

The Exchange Server 2010 Service Pack 3 is a milestone in the product because that is the basic requirement to allow a transition from Exchange Server 2010 to Exchange Server 2013 CU1. Besides the transition capabilities we can also install it on Windows Server 2012 (new deployments only, it is not supported on OS upgrades) and support for Internet Explorer 10.

Our scenario is simple and provides for great flexibility to test all possible scenarios. You may find yourself in one of the tests that we perform throughout this article series. In our article scenario we have 2 (two) servers with the Client Access and Hub Transport role and 2 (two) servers running Mailbox role in a DAG while all servers are running Exchange Server 2010 Service Pack 1. You can check out the current servers by clicking on Server Configuration (Figure 01) or running Get-ExchangeServer cmdlet (Figure 02).

Figure 01

Figure 02

That is just great… but Version and Build are all Greek to me, what should I do? No worries, if you are not sure which Service Pack and/or Rollup Update you have in your environment the Build Numbers can be scary at first glance, but using this page you can easily match the building number with the Service pack/Rollup Update.

Order to apply the Service Pack 3 and a few hints…

The first thing when you are planning is the order to apply Service Pack 3 on your servers. These are the key rules to apply a new Service Pack in your organization.

  1. Client Access Server (if you have multiple sites internet facing sites first)
  2. Hub Transport
  3. Mailbox
  4. Unified Messaging

Before going any further let’s go over a couple of items that can speed up your upgrade process in your environment, as follows:

  • Backup, backup, backup!

Before playing with production environments, please make sure that you have valid backups of your servers, Active Directory and Databases.

In addition, a good file-level backup of any Exchange (especially OWA customization) may be useful.

  • Document your environment

Make sure that you have all your server names, and most important information recorded. My fellow MVP Steve Goodman wrote a script that gives you a list of all servers, their versions, databases, roles, Operating system and so forth. You can check his Exchange Environment Report.

  • Plan your outage

Make sure that you test the process on an environment similar to production and plan well your outage time and communicate that to the end-users.

If you are upgrading your environment from RTM to Service Pack 3, then you should add 30 minutes per database due a Database Schema upgrade that was done on Service Pack 1 of the product and since Service Pack 3 is slipstream then those upgrades will be performed when you move from RTM to SP3. There is no database schema upgrade from SP1 or SP2 to SP3.

  • Test it first

Before going ahead and applying a new Service Pack in your production environment make sure that you validate in a test/lab environment.

  • Environment validation before and after the upgrade process

It does not matter if you are going to migrate one or several servers. I always suggest you create a spreadsheet with Test Case scenarios for each server upgrade. You can create a list with all the tests that you want to perform, you can start simple, such as Outlook internal and external access; you can also add several additional tests to your validation process such as mail flow and usage of Internet tools provided by Microsoft Exchange Team ( is a great tool for testing).

  • Read the Release Notes and the Knowledge Base article for the new update

Another best practice is to read the Release Notes and Knowledge Base of the new update. The KB and release notes are available on the same page of the update.

  • Hardware Load Balancer in front of your CAS/HUB servers

If you are using a Hardware Load Balancer solution, you should add a task to your planning to remove the server that will receive the upgrade from production. In Figure 03, we can see the option to Disable or Force Offline in a LTM (F5 device) at the pool member level. If you use a different Hardware Load Balancer they will have similar options, the same applies for Microsoft Load Balancer software solutions.

Figure 03

Exchange Server 2010 pre-requisites…

Now that we covered a couple of best practices, we can start the technical side of the prerequisites. In this section, we will cover the following key points in detail.

  • Download Exchange Server 2010 Service Pack 3
  • Add the IIS 6 WMI Compatibility
  • Remove the previous log files
  • Stop any third-party tool on Exchange
  • Stop SCOM maintenance

The first task of our list is the easiest one which is the downloading of Service Pack 3. Service Pack 3 can be found here.

The second item of our list is to add an IIS component. The new Service Pack 3 requires that this new component be installed, and we can install it either using GUI or command line. If you like the graphical user interface, just add a role service to the IIS component and select IIS 6 WMI Compatibility as shown in Figure 04.

Figure 04

If you like to automate you can always perform the same tasks using PowerShell, as shown in Figure 05.

Figure 05

The third item is not a big deal but if you want to keep your deployment logs separate for audit requirements it does not hurt to do it. It is most likely that we are upgrading an existent Exchange Server deployment to Service Pack 3 and for that reason we can go ahead and delete the C:\ExchangeSetupLogs folder because all log information was from the previous installation. By doing that we guarantee that all new log information will be related to our new upgrade process.

The fourth item of our list is to disable any services that interact with Exchange and it can be Antivirus, Backup, etc. If you are not sure what is running on the server a good start is to look at the System Configuration Utility (run the msconfig from command prompt or Run) and then go to the Services tab and check the option Hide all Microsoft services, as shown in Figure 06.

Figure 06

If you use SCOM (System Center Operations Manager) or any other Monitoring Tool make sure that you stop the service as well. If you are using SCOM, make sure to add the server in maintenance mode which can be done through SCOM Console or web interface.

The last point that I want to make before starting the process is to make sure that you disconnect any administrator connected to the server through RDP and make sure that you do not have an Exchange Management Console or Shell running on the server during the upgrade.


In this first article, we covered a couple of key points that should be visited before installing Service Pack 3 in a production environment. In our second article we will be installing Service Pack 3 on a standalone server and DAG members using either GUI or command line interfaces.

If you would like to read the next part in this article series please go to Applying Service Pack and Rollup Updates on Exchange Server 2010 (Part 2).

Featured Links