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
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.
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.
Warning
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.
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.
.gif "The software update deployment cycle")
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.
Important
We strongly advise against using alternate access mapping URL redirection (AAM) with database attach as an option for downtime reduction. AAM was not designed to deploy software updates. For more information, see Using AAM URL redirection as part of the upgrade process (SharePoint Server 2010) (white paper).
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
Tip
Clean up the farm environment before you deploy the update. The benefits of a cleanup are improved update installation performance and the elimination of potential issues during and after the software update. For more information, see Clean up an environment before upgrade (SharePoint Server 2010).
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.
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.
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.
| 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.
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.