Install a software update (SharePoint Foundation 2010)

SharePoint 2010

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2011-08-05

This article describes how to install a software update on servers in a Microsoft SharePoint Foundation 2010 farm. Additionally, three example scenarios are discussed and an update procedure is provided for each scenario.

Before you start to deploy the software update, verify that the update strategy that you plan to use is optimal for your Microsoft SharePoint Foundation 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 a software update (SharePoint Foundation 2010) to verify the update strategy that you want to use: in-place, database attach, or a hybrid.

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.

SharePoint Foundation 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 Foundation 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 Foundation 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.

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 Foundation 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.

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 Foundation 2010).

The following illustration shows the sequence of steps to follow to install the update on the farm.

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 Web server that hosts Central Administration (WEB-4).

Verify that the server was 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 and WEB-3).

Verify that all the servers were updated successfully.

Run the SharePoint Products Configuration Wizard on the Central Administration server (WEB-4) to upgrade the configuration database and upgrade each content database serially.

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.

This scenario takes advantage of the backward compatibility of SharePoint Foundation 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.

The following illustration shows the sequence of steps that are required to install the update on the farm.

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.

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.

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.

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 6 and 7 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 6 and 7). 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 (WEB-4).

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 Web servers (WEB-1 to WEB-3).