The information that is provided about the software update process is intended for all IT professionals who maintain SharePoint Server 2010. However, the specific instructions for installing a software update are intended for IT professionals who have to deploy software updates on a SharePoint Server server farm.

The information in this article applies to the following products:

SharePoint Server 2010

SharePoint Server 2010 language pack

Microsoft Filter Pack

Note

The process for installing software updates in stand-alone environments of SharePoint Server is a simpler process than the process for installing software updates in a server farm and does not require all the steps that are required for a server farm.

It is important to understand that deploying updates in a SharePoint Server 2010 environment is a two-phase process: patching and upgrading. The term patch is used in this article to differentiate between updating the software and upgrading the software.

Each phase has specific steps and results. It is possible to postpone the upgrade phase.

Caution

Inconsistent farm behavior may result from postponing the upgrade for more than several days. The longer the postponement, the larger the risk is that farm behavior issues will occur.

The patch phase has two steps, the patching step and the deployment step. During the patching step, new binary files are copied to the Central Administration server. Any services that are using files that have to be replaced are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used. However, there are some instances when you must restart the server.

The second step in the patch phase is the deployment step. In this step, the installer copies support files to the appropriate directories on the server that is running SharePoint Server. This step ensures that all the Web applications are running the correct binary files and will function correctly after the update is installed. The update phase is complete after the deployment step.

The next and final phase to deploy software updates is the upgrade phase.

After you finish the patch phase, you must complete the update installation by starting the upgrade phase. The upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint Server processes that are running. After the processes are upgraded, the databases are crawled and upgraded. Because the upgrade process can run on a single server, the other servers in the farm can continue to serve requests.

The cycle that is used for upgrading SharePoint Server farms and servers also applies to deploying software updates, which are a subset of an upgrade. We recommend that you use the update cycle that is shown in the following illustration as a guide to deploy software updates.

First, ensure that the system can be provisioned as a farm server. For more information, see Hardware and software requirements (SharePoint Server 2010). Ensure that any server that you plan to update is running the same version of the operating system as the other farm servers. This includes updates, service packs, and security hotfixes.

Research and assess the options that are available for reducing downtime. The first thing to check for is missing dependencies, which may extend the amount of downtime. Identify all the dependencies for the update and either address these dependencies before you start to deploy the update, or factor the time cost into your schedule. Consider using read-only content databases and doing parallel upgrades to reduce downtime.

The purpose of documenting the environment is to determine what is unique in your farm. You can use several techniques to gather information about your farm, such as manual inspection, comparisons by using WinDiff, and Windows PowerShell commands.

Customizations are typically one of the top issues during a farm upgrade or software update. Identify your farm customizations and determine whether they might be affected by the update. If in doubt, err on the side of caution and determine how you will manage the customizations. You must ensure that customizations will work after the software update. You can use the Stsadm command, ExportIPFSAdminObjects, to collect and export customizations.

During the Learn phase of the update cycle, you should have determined an update strategy and the required downtime minimization. In addition to determining hardware, space, and software requirements, you must include the following in your update strategy:

The two final requirements for the update strategy are a communication plan and an update schedule.

It is very important to communicate with site owners and users about what to expect during an upgrade. The administrator should inform them about downtime and the risk that the upgrade may take longer than expected or that some sites may need some rework after upgrade. For more information, see Create a communication plan (SharePoint Server 2010).

Create a benchmark update operations schedule that contains the start times of operations related to the update deployment. At a minimum, the plan should include the following operations:

Back up the farm.

Start the update of the farm servers.

Start the upgrade of the farm databases.

Start a rollback of the environment, if it is required.

Resume the upgrade, if it is required.

Verify that the environment is completely working, either as the original version if you rolled back or the new version if you completed the upgrade.

Ensure that farm items are ready for the update. Farm items are ready if they are backed up, documented, or updated to ensure that the update can be installed. Verify that the following aspects of a farm are update-ready:

Build a test farm that is representative of the production environment. We recommend that you use a copy of the production data to determine potential problem areas and monitor overview system performance during the upgrade. The key indicator is the length of time it takes from the beginning to the end of the deployment process. This should include backup and validation. You can incorporate this information into the update schedule.

If possible, use hardware in the test environment that has equivalent performance capabilities to the production servers.

Tip

Consider the use of a test farm in a virtual environment. After you finish the tests, you can shut down the virtual farm and use it later for future updates.

A test farm also enables you to evaluate the techniques that you plan to use to update the production environment. In addition to testing and assessing your downtime reduction strategy, you can refine update monitoring. This is especially important in the areas of validating and troubleshooting the software update.

The refined techniques that you use to monitor the software update in the test environment carry over to deploying the update in the production environment. Use the Upgrade and Migration page in Central Administration to monitor the status indicators that are available. This feature enables live monitoring and provides a single location to view the patch status for all farm servers. Additionally, you can use the Upgrade and Migration page to view the update status for individual servers and the status and type of farm databases. Finally, a valuable aspect of monitoring by using Central Administration is identifying farm servers that must be updated.

The following tables describe the status information that is available in Central Administration.

Status value

Description

Hyperlink

No action required

Farm server does not currently require any action to be taken by
the administrator.

No hyperlink

Installation required

Farm server is missing an .msi file that is set to mandatory for all farm servers, or has a patch level below the individual farm-wide effective patch version.

Hyperlink to the Patch Deployment State page

Upgrade in progress

Farm server is currently undergoing an upgrade operation.

Hyperlink to the Upgrade Status page

Upgrade available

Farm server is running in backward-compatibility mode.

Hyperlink to the Upgrade and Migration page

Upgrade required

Farm server is outside the backward-compatibility mode range with one or more databases.

Hyperlink to the Upgrade and Migration page

Upgrade blocked

If an upgrade is available and any farm server requires installation, the remaining servers that do not require installation will be set to this status unless they are currently undergoing an upgrade.

Hyperlink to the Patch Deployment State page

Status value

Description

Installed

Indicates that no action is required

Missing/Required

Displayed if a product is required on each server or if a patch for a specific .msi file is located on one server but not on the server for which this status is shown

Missing/Optional

Displayed if a product is not required on each server

Superseded

Displayed if an update is no longer required on a server because a newer patch supersedes it

Other tools to monitor the update process are log files and Windows PowerShell commands.

Important

Remember to monitor the length of time that the update is taking. Compare current update processes against the benchmark schedule to determine whether the update will meet the downtime window. If not, you should communicate this information to the farm users.