Software updates overview (SharePoint Server 2010)

Applies to: SharePoint Server 2010

This article provides an overview of deploying software updates on a Microsoft SharePoint Server 2010 farm.

In this article:

• Improvements and new features

• Intended audience and scope

• Software update process

• Software update strategy

• Software update deployment cycle

Improvements and new features

SharePoint Server 2010 introduces improvements and new features that facilitate a better end-to-end software update experience. Some of these features are as follows:

• There is support for backward compatibility between update versions on different servers, which enables you to install the update binary files and postpone update completion to a later time.

• You can update multiple Microsoft SharePoint Server servers concurrently to shift the workload to the database servers.

• There is full support for automatic updates that use Windows Server Update Services (WSUS), Windows Update, and Microsoft Update.

  Note

  An automatic update will install the binary files on the farm servers, but you must complete the software update by running the upgrade on the servers.

• Administrators can monitor the status of the update by using the Central Administration Web site or Windows PowerShell.

For more information about SharePoint Server improvements and new features, see What's new in upgrade (SharePoint Server 2010).

Intended audience and scope

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

Software update process

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.

Update phase

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.

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.

For more information about upgrades, see Upgrade process overview (SharePoint Server 2010).

Software update strategy

The update strategy that you select will be based primarily on one of the following factors:

• The amount of downtime that is acceptable for installing the update.

• The additional staff and computing resources that are available to reduce downtime.

When you are determining your update strategy, consider how the strategy enables you to manage and control the update.

In terms of downtime reduction, the following options, ordered from most to least downtime, are available:

• Install the update and do not postpone the upgrade phase.

• Install the update and postpone the upgrade phase.

• Install the update with the shortest possible downtime and postpone the upgrade phase.

Software update deployment cycle

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.

Learn

During this phase of the cycle the purpose is to learn what is required to install the update. This information also affects new servers that you want to update and then add to the farm.

Requirements and prerequisites

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.

Update strategy

Determine which strategy you want to use to update the farm. Depending on your requirements, you can use one of the following strategies:

• In-place

• Database attach

You can use either of the previous strategies to create a hybrid approach that is tailored to your environment. For more information, see Determine upgrade approach (SharePoint Server 2010).

Downtime reduction

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.

Common issues

Identify and address common issues such as missing or out-of-date dependencies and lack of space on the servers where the update will be installed.

Prepare

Prepare for the software update by documenting the environment and planning an update strategy to ensure that the update will go as planned in the expected downtime window.

Document the environment

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.

Document, as appropriate, the following elements of the environment:

• Farm topology and site hierarchy

• Language packs and filter packs that are installed

• Customizations that could be affected by the update

Manage customizations

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.

For more information, see Determine how to handle customizations (SharePoint Server 2010).

Plan the update strategy

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 update sequence for the farm servers

• The order of operations

• The downtime limits and how you plan to reduce downtime

• A rollback process if there is a major problem

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.

Make farm items update-ready

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:

• Solutions

• Features

• Site definitions

• Web Parts

Test

The rigor, thoroughness, and detail of your tests determine the success or failure of the software update deployment. In a production computer environment there are no safe shortcuts, and there are consequences from insufficient testing. For more information, see Use a trial upgrade to find potential issues (SharePoint Server 2010).

Build a test farm

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.

Evaluate techniques

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.

Implement

The update strategy that you use will determine whether you have to build a new farm or deploy the update on the current farm servers.

Build or update farms

Whether you build a new farm or do an in-place update, the most important farm elements to consider are as follows:

• Content

• Services

• Service applications

Deploy customizations

Use solutions whenever possible so that you can quickly deploy any customizations.

Reduce downtime

Reduce downtime by using techniques such as read-only databases and update parallelism. For more information, see Determine upgrade approach (SharePoint Server 2010).

Monitor progress

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.

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

Validate

You can start to validate the success of the update during the implementation phase and continue validation after the update is implemented.

Logged event failures

Review the event logs to discover any issues that occurred during the deployment. Resolve these issues and then resume or restart the update as appropriate.

User interface or experience issues

Any user interface or user experience issues will surface on site pages. Look for the following issues:

• Ghosting

• User interface version mismatch

• HTML and XHTML compliance

Additional issues may include missing templates, user identifiers, and content issues such as large lists.

Data issues

Data issues result from the condition of the farm databases and can include all or some of the following:

• Connectivity issues to data sources

• Database corruption

• Orphaned items

• Hidden column data

In some cases there may be minor issues that you can troubleshoot and then resume or restart the update. Be prepared to roll back the update as soon as there are issues that cannot be easily resolved.

See Also

Other Resources

Resource Center: Updates for SharePoint 2010 Products