If you would like to read the first part in this article series please go to Applying Service Pack and Rollup Updates on Exchange Server 2010 (Part 1).
Upgrading a standalone server
If you have a single server in your environment you can follow this section to upgrade them to Service Pack 3 and the same applies for Rollup Updates.
If you read the first article of this series then we should have a folder called SP3 with all Exchange Service Pack 3 files on the C: drive.
The entire upgrade process does not require too much decision making from the Administrator side. It is just a matter of waiting for the completion of the process.
Our first upgrade of this series is going to be on a server that has CAS/HUB installed and we are going to use the graphical user interface. Let’s open the SP3 folder and double click setup.exe, the initial page will be displayed (Figure 01), click Install Microsoft Exchange Server upgrade and follow these steps.
Figure 01
- On the Introduction page, click Next.
- On the License Agreement page, if you agree with the terms, please accept it and click Next.
- The Readiness Checks page is the most important page of the setup process. All your prerequisites hard work should be paid off at this stage where you should not get any critical issues that would affect the move forward with the upgrade process.
However, if you do get a critical (red) status, the setup will give you some additional information to fix it and you can run the same wizard again. If everything goes well, just click Upgrade (Figure 02)
Figure 02
- On the Completion page, you will see several completed tasks (each one involving a setup process, such as roles upgrade, copy/prepare/remove exchange files and so forth), just click on Finish (Figure 03).
Figure 03
Another possible way to perform a Service Pack upgrade is using the command line. If that is your favorite method, just go to the command prompt as Administrator, then go to the Service Pack folder (in this specific example the extracted files are located in the folder C:\2010SP3 folder).
Then we just need to run a single command, which is setup.com /mode:upgrade and if everything goes well the upgrade will be completed successfully, as shown in Figure 04. If there is any outstanding issue the setup upgrade will not continue and the readiness section will display all warning/critical issues that you will have to deal with in order to complete the upgrade.
Figure 04
Upgrading DAG servers…
If you are upgrading an environment with a single server you have to plan for an outage however, when you are using a DAG you can organize your upgrade process in a way that your end-users are not affected from a mailbox perspective.
The upgrade process is simple and can be summarized in a few steps as described below. Bear in mind that a Database can be moved among servers running different Service Pack versions but it is good practice to keep all servers running the same version sooner rather than later.
- Make sure that your DAG replication/environment is healthy prior to the upgrade
- Define the first server to receive the upgrade, and move all databases from that server (there are a couple of ways to do that)
- Add the desired server in maintenance mode to prevent it from becoming active
- Apply the Service Pack and/or rollup update on the server
- Remove the server from maintenance mode
- Validate and move the desired databases back to the server
The first item should be part of your daily activities or at least be part of your ongoing monitoring. There are several ways to monitor your DAG health status. We can start simple using the Test-ReplicationHealth cmdlet, as shown in Figure 05. This cmdlet will check several components involved in the replication process, such as Cluster Services, Exchange Replication services, DAG members, witness server and Database replication information as well.
If we run the Test-ReplicationHealth without parameters, it will run against the local server, if we want to check another DAG members we can always use the parameter –Identity <ServerName> .
Figure 05
A second useful cmdlet is the Get-MailboxDatabaseCopyStatus that will give us details about the Databases, their current status, and also Copy and Replay queue length when appropriate (Figure 06). Like the previous cmdlet when we run it without parameters then the current server is used.
Figure 06
We can mofify that cmdlet to retrieve information about a specific server (-Server parameter), Database (-Identity or leave out the parameter and just add the DB name) or a specific instance (use DatabaseName\Servername with –Identity parameter). In Figure 07, we performed the same cmdlet using 3 (three) different parameters, we started without any parameters, then we checked the status from a remote server and finally we get the details where the Database is mounted and so forth.
Figure 07
We have just finished the validation of our DAG and if everything is ok, then we can choose a server to start the upgrade process. The server chosen may have some active databases and here we have a couple of options to deal with, as follows:
- Move each databases manually to different servers running Database Failover (right click on the Database and then Move Active Mailbox Database)
- Move all databases in a single shot using the Switchover Server… option (expand Server Configuration, and select Mailbox item and then right-click on the desired server)
- Use a built-in script that is available since Service Pack 1 to do all the work for us.
We have done all the hard word to check all prerequisites for this Service Pack and DAG health checks, so the script will come handy. There are two scripts: StartDAGServerMaintenance.ps1 and StopDAGServerMaintenance.ps1 and their name gives us a good idea what they do.
The beauty of the scripts is that they move all databases remaining on that server, pauses the node on the Failover Clustering, suspends and blocks activation of any database in a single line!
In order to add the server in maintenance mode follow these steps:
- Open Exchange Management Shell
- Type in cd $exscripts and press <enter>
- Run .\StartDagServerMaintenance.ps1 –serverName <ServerName> as shown in Figure 08.
Figure 08
- Close the Exchange Management Shell
Now the process is similar to any regular upgrade, just follow the same procedures to upgrade as described in the previous section (Figure 09).
Figure 09
After completing the setup, we can check the servers version again in our organization and one of the DAG members should have Service Pack 3 listed (Figure 10).
Figure 10
In order to bring that server back to production we can run the StopDagServerMaintenance.ps1 –serverName <ServerName> and after that we can move the database(s) back to that server and validate if everything goes well accordingly to the plan.
A simple test to validate the new upgraded DAG member is to move a database and check if there are any issues (additional tests to validate if the server can be moved into production are listed in the following section of this article).
Tasks after the Service Pack/Rollup Update completion…
It is not stated in the official documentation but a restart of the affected server seems a reasonable idea and after that the administrator can run a couple of simple tasks to validate if the upgrade went well, as follows:
- Use Test-ServiceHealth to check if all services are up and running
- Check event viewer to validate any possible issues
- Check the installation log files, you can always check from the final page of the upgrade assistant by clicking the View Setup log link or you can go back anytime and run the get-setuplog.ps1 (Figure 11) found in the Scripts folder and analyze for any errors.
Most of the time if you see that all components being upgraded completed in the wizard, you may not want to spend your time on this one.
Figure 11
Conclusion
In this final article of our series, we went through the process of upgrading an existent Exchange Server 2010 environment to Service Pack 3. The same procedures listed here can be used to upgrade to latest service packs, and rollup updates as well.
If you would like to read the first part in this article series please go to Applying Service Pack and Rollup Updates on Exchange Server 2010 (Part 1).
