Install a software update (SharePoint Server 2010)
Applies to: SharePoint Server 2010, SharePoint Foundation 2010
This article describes how to install a software update on servers in a Microsoft SharePoint Server 2010 farm. Additionally, three example scenarios are discussed and an update procedure is provided for each scenario.
In this article:
Verify the update strategy
Monitor installation progress
Handle update failures
Review update scenarios
Use the in-place method without backward compatibility
Use the in-place method with backward compatibility
Use the database attach method for high availability of existing content
Verify update completion and success
Verify the update strategy
Before you start to deploy the software update, verify that the update strategy that you plan to use is optimal for your Microsoft SharePoint Server environment. There are several factors, such as downtime reduction, cost, and complexity that determine which strategy to use to deploy a software update. Use the flowchart in the "Determine Update Strategy" section of Prepare to deploy software updates (SharePoint Server 2010) to verify the update strategy that you want to use: in-place, database attach, or a hybrid.
Monitor installation progress
Monitor the update deployment process during the update to verify that the update is proceeding as planned. There may be issues that will block the update or that will result in an updated farm that has elements that do not work as expected. Pay extra attention to database synchronization and customizations.
We recommend that you use the Upgrade and Migration view in Central Administration as the primary tool for viewing product and patch installation status, data status, and upgrade status in real time.
After Setup runs, you can also view the log files and use Windows PowerShell to obtain the current results of the installation progress.
Handle update failures
SharePoint Server 2010 provides an improved approach to handling upgrade failures after the patching phase finishes. If an update fails and you are running in backward compatibility mode, you can restore the SharePoint Server database and continue to run in backward compatibility mode. After the update issue is resolved for the site, you can resume the upgrade. Any tasks that were completed are not run again. For more information, see Testing and troubleshooting upgrade (SharePoint Server 2010).
If an update failed in earlier SharePoint Products and Technologies environments, you usually had to uninstall the product, install the older version, and then restore from a backup.
Review update scenarios
The following software update scenarios are discussed in this article:
In-place without backward compatibility – The update is installed on all the farm servers at the same time and the content is upgraded without using backward compatibility.
In-place with backward compatibility to reduce downtime – The update is installed in stages and uses deferred upgrade with backward compatibility to reduce downtime.
Database attach for high content availability – This update uses two farms to provide high availability for existing content.
For more information about how the in-place and database attach processes work, see the diagrams in the following article: Upgrade process overview (SharePoint Server 2010). Note that these articles are about how to upgrade across software versions, not how to install software updates. However, the general process is very similar.
The following illustration shows the farm topology that is used as an example for each patching scenario that is described in this article.
.gif "Example farm for installing software update")
Initial state and required conditions
The preceding illustration shows the initial state of the farm before you install the update. Verify that the following conditions are true:
All the front-end Web servers are load balanced together and are in rotation with the load balancer.
All the farm servers are operating correctly.
All the databases are active and operating correctly.
Do not start the software if any of the preceding conditions are not true. Resolve all issues before you continue.
Use the in-place method without backward compatibility
In this scenario the complete farm is shut down by disabling incoming requests to the front-end Web servers and then installing the update on all the farm servers. This strategy combines the update and the upgrade phase described in the "Software Update Process" section in Software updates overview (SharePoint Server 2010).
The following illustration shows the sequence of steps to follow to install the update on the farm.
.gif "In-place update without backward compatibility")
Use the preceding illustration as a guide for using the recommended steps in the following procedure.
To install an update without backward compatibility
Remove the Web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
Run the executable file to install the update on the application server that hosts Central Administration (APP-1).
Run the executable file to install the update on the application server that hosts the search query component (APP-2).
Verify that all the servers were updated successfully.
Log on to the first Web server (WEB-1).
Run the executable file to install the update on the Web server.
Run the executable file to install the update on the remaining Web servers (WEB-2, WEB-3, and WEB-4).
Verify that all the servers were updated successfully.
Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1) to upgrade the configuration database and upgrade each content database serially.
Run the SharePoint Products Configuration Wizard on the application server that hosts the search query component (APP-2).
Run the SharePoint Products Configuration Wizard on the first Web server (WEB-1).
Note
Run the configuration wizard to ensure that if the update fails for a specific server, the error is not propagated to the other Web servers. For example, a failed upgrade for one server could make the upgrade fail for one or more site collections.
Repeat the preceding step for each remaining Web server.
Verify update completion and success. For more information, see Verify update completion and success.
Add the Web servers (WEB-1 to WEB-4) to the rotation in the load balancer, or start the load balancer to enable incoming requests to the servers.
Use the in-place method with backward compatibility
This scenario takes advantage of the backward compatibility of SharePoint Server 2010 and the deferred upgrade feature to reduce the downtime that is required to deploy a software update. However, downtime is not completely eliminated. The sites and services will not be available while the content is being upgraded.
This software update scenario uses two phases to install the update on farm servers. These phases are as follows:
Update to install the update on the farm servers.
Upgrade to complete the patching process.
During the update phase, the farm can continue to be in production with minimal to no downtime. However, during the upgrade phase, the farm will be unavailable. If you attempt to access content while the farm is upgrading, the result could be failed upgrades or excessive slowdowns in the upgrade process because of resource contention and locking. Such an attempt is unsupported and untested.
For more information about the software update process, see "The Software Update Process" section in Software updates overview (SharePoint Server 2010).
Update phase
The following illustration shows the sequence of steps that are required to install the update on the farm.
.gif "In-place update with backward compatibility")
Use the preceding illustration as a guide for using the recommended steps in the following procedure.
To install the update on farm servers
Remove half of the Web servers (WEB-1 and WEB-2) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
Run the executable file to install the update on each Web server that is out of the load-balancing rotation (WEB-1 and WEB-2). Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the Web servers were updated successfully.
Remove the remaining Web servers (WEB-3 and WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers. At this point none of the front-end Web servers are receiving requests for the farm.
Add the updated Web servers (WEB-1 and WEB-2) back into the load-balancing rotation.
Run the executable file to install the update on each Web server that is still out of the load-balancing rotation. Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the Web servers were updated successfully.
Add the updated Web servers (WEB-3 and WEB-4) back into the load-balancing rotation.
Run the executable file to install the update on the application server that hosts the search query component (APP-2). Do not run the SharePoint Products Configuration Wizard on this server.
Run the executable file to install the update on the Central Administration server (APP-1). Do not run the SharePoint Products Configuration Wizard on this server.
Verify that both of the application servers (APP-1 and APP-2) were updated successfully.
Verify update completion and success. For more information, see Verify update completion and success.
At this point in the process, the databases and other components such as settings, features, and site-level data must still be upgraded because the SharePoint Products Configuration Wizard was not run on any of the farm servers. However, the farm should be capable of running in backward compatibility mode.
Upgrade phase
The following illustration shows the sequence of steps that are required to finish the patching process by upgrading the farm servers. During this process, the sites that are being upgraded will not be available to users.
.gif "Upgrade phase of an in-place software update")
Use the preceding illustration as a guide for using the recommended steps in the following procedure.
Important
Monitor the status of the upgrade on each server before you upgrade the next server in the sequence. It is highly recommended that you create a backup of the farm before beginning upgrade.
The following procedure shows all the steps to upgrade the farm. You can upgrade all components within the same outage window, or you can take some smaller outage windows and upgrade separate parts of the farm at different times. If you want to break up the upgrade stage, you can upgrade the following components in separate outage windows:
Services
If the software update contains updates to services that must be applied, you can upgrade the service, and then resume operating the farm (steps 7 and 8 in the procedure) until it is possible to take a longer farm outage to complete the content and farm upgrade.
Content databases
You can take a short farm outage to upgrade only a few content databases (steps 1 through 3 in the procedure) each time and then resume farm operation (steps 7 and 8). You can repeat the process over successive outage windows until all content is upgraded and the farm servers are ready to be upgraded.
You can also upgrade individual content databases in parallel for a very small number of content databases at the same time. However, do not attempt to upgrade too many content databases in parallel because it will slow down the overall upgrade process and extend the outage time. We recommend that you do not upgrade more than two content databases on the same Microsoft SQL Server volume at a time and that you stage the starting time of the upgrade for each content database that will occur in parallel by several minutes to prevent lock contention as the upgrade process starts. In addition, limit the number of content databases that are being upgraded on a single Web or application server because each additional upgrade process will consume a relatively large amount of resources. The typical number of content databases that can be upgraded per Web or application server is four databases. However, be sure not to exceed the number of databases that are being upgraded per SQL Server volume, no matter which Web or application server originates the upgrade.
To upgrade the farm
Remove the Web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
Important
The sites and services will not be available until upgrade is complete and the servers are returned to an active load-balancing state.
Upgrade specific services, as needed.
Some updates might also require you to run additional Windows PowerShell cmdlets to upgrade specific service applications. If the notes for the software update indicate that a specific service must be upgraded so that it will continue to operate after patching, as in the case in which a service cannot operate in backward compatibility mode, a short farm outage can be taken so that the service can be upgraded without having to upgrade the complete farm. The additional Windows PowerShell cmdlets to upgrade specific service applications should be indicated in the notes if this is required.
Use the Windows PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database.
This is an optional step, but it will help ensure that all content databases are upgraded first. It has the advantage of enabling some parallelism to reduce the outage time. If it is not performed, all remaining non-upgraded content databases will be upgraded serially when you run the SharePoint Products Configuration Wizard to upgrade the farm servers.
Important
Run the Upgrade-SPContentDatabase cmdlet for each database. You can run this cmdlet from any of the upgraded Web servers or application servers. Note that the content for each database will be unavailable while this process is running on that database.
Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1).
Important
The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and any other databases that are not already upgraded. Because it is likely that the content databases are the only databases that have already been upgraded, as described in the previous step, all the service application databases are also upgraded in this step. Your sites will not be available while this process runs.
Run the SharePoint Products Configuration Wizard on the remaining application server (APP-2).
Run the SharePoint Products Configuration Wizard on the Web servers (WEB-1 to WEB-4).
Verify update completion and success. For more information, see Verify update completion and success.
Add the upgraded Web servers (WEB-1 to WEB-4) back into rotation in the load balancer.
Use the database attach method for high availability of existing content
To ensure high availability for existing content, this scenario uses read-only databases on the existing farm. The update is installed on a new farm and user traffic is rerouted to this farm.
The following illustration shows the sequence of steps to follow to install the update on a new farm by using the database attach method. For more information, see Attach databases and upgrade to SharePoint Server 2010.
.gif "Install a software update using database attach")
Use the preceding illustration as a guide for using the recommended steps in the following procedure.
To install the update by using database attach
Create a new farm where you will install the software update. This farm does not require front-end Web servers. For more information, see Prepare the new SharePoint Server 2010 environment for a database attach upgrade.
Note
If the original farm uses a database mirror, you must configure mirroring after you finish deploying the software update on the new farm.
Configure the databases on the existing farm so that they are in a read-only state.
Note
If the existing farm is mirrored, you must pause mirroring before setting the databases to read-only.
For more information about how to configure read-only databases, see the "Set the Previous Version Databases to Be Read-Only (Database Attach with Read-Only Databases)" section in Attach databases and upgrade to SharePoint Server 2010 and Run a farm that uses read-only databases (SharePoint Server 2010).
Configure the service application databases on the existing farm so that they are in a read-only state. This prevents unexpected changes to service applications.
If you are patching the User Profile Service service application database, then you must export the User Profile Synchronization Service encryption key from the old database and then import the key into the new database. This key is also known as the Microsoft Identity Integration Server (MIIS) key, the Synchronization Service encryption key, and the Forefront Identity Manager 2010 (FIM 2010) key. If you do not export and then import the key correctly, the Synchronization Service will not start. To export the encryption key, complete these steps:
Use farm administrator credentials to log on to the computer that contains the old User Profile Service service application database.
Open the Command Prompt window, and then change to the following folder:
%Program Files%\Microsoft Office Servers\14.0\Synchronization Service\Bin\
Type the following command, and then press Enter:
miiskmu.exe /e <Path>
Where <Path> is the full path of the file to which you want to export the key, and the user name and password are the credentials for the farm administrator.
Back up the content databases on the existing farm. For more information, see Backup and recovery for SharePoint Server 2010.
To import the encryption key, complete these steps:
Use farm administrator credentials to log on to the computer that contains the new User Profile Service service application database.
Attempt to start the User Profile Synchronization service. Because you have not yet imported the encryption key, the service will not start. Confirm that the service did not start by using the ULS log or by making sure that the status of the service is Stopped.
Open the Command Prompt window, and then change to the following folder:
%Program Files%\Microsoft Office Servers\14.0\Synchronization Service\Bin\
Type the following command, and then press Enter:
miiskmu.exe /i <Path> {0E19E162-827E-4077-82D4-E6ABD531636E}
Where <Path> is the full path of the file to which you exported the key.
(Optional) To check that the encryption key was imported correctly, at the command prompt, type the following command, and then press Enter:
miiskmu.exe /c {0E19E162-827E-4077-82D4-E6ABD531636E}
Restore the content databases to the new database server.
Create service applications on the new farm for each existing service application in the old farm.
You must duplicate all the settings from your existing farm.
Use database attach to create the databases on the new farm. For more information, see Perform a database attach upgrade to SharePoint Server 2010 and Attach and restore a read-only content database (SharePoint Server 2010).
Verify that there are no issues with the new farm.
Enable the new farm as the production farm by configuring DNS to point to the new farm or by making sure that the new farm is load balanced. Verify that users can access the new farm.
Allow time for users to switch from cached DNS, and then decommission the old farm.
Verify update completion and success. For more information, see Verify update completion and success.
Verify update completion and success
Regardless of the update strategy that you use and the monitoring that you do during the software update, you must verify update completion and success. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).