SharePoint Server 2010 Update Testing Procedure

Article
12/08/2011

SharePoint Server 2010 Service Pack and Cumulative Update Testing Process

Contents

Disclaimer 3

1. Software Updates Overview.. 4

2. Documentation and Testing Schedule. 5

2.1 This Document 5

2.2 Document the Environment 5

2.3 Validated Current/Future Service Packs and Cumulative Updates Doc. 6

2.4 Schedule of Testing and Maintenance Windows. 6

3. Installation Procedures - SharePoint 2010 Service Packs and Cumulative Updates. 7

3.1 Pre-installation Steps. 7

3.2 SharePoint Server 2010 Service Pack Installation. 8

3.3 SharePoint Server Cumulative Update Installation. 8

4. Verify Installation. 9

5. Testing Project Server 2010. 10

6. Cumulative Updates Links. 10

Disclaimer

This Instruction Set is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS INSTRUCTION SET AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. We grant You a nonexclusive, royalty-free right to use and modify the Instruction Set and to reproduce and distribute the Instruction Set, provided that You agree: (i) to not use Our name, logo, or trademarks to market Your software product in which the Instruction Set is embedded; (ii) to include a valid copyright notice on Your software product in which the Instruction Set is embedded; and (iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits, including attorneys’ fees, that arise or result from the use or distribution of the Instruction Set.

1. Software Updates Overview

Microsoft periodically releases software updates for Microsoft SharePoint Server 2010. It is important to understand what these updates are and how to deploy them to servers or server farms. It is recommended that you use the update cycle that is shown in the following illustration as a guide to deploy software updates.

2. Documentation and Testing Schedule

2.1 This Document

You should update this document as you see fit to customize it for your organization. Additionally, every new update will require you to change the expected version numbers. Use this document over and over to ensure you perform the same steps in TEST, DEV, and PROD. You should add your own notes about what to expect in the install steps.

2.2 Document the Environment

Document all the server names, IP addresses, and logon information for each environment, such as Test, Development, and Production, where updates will be installed. The purpose of documenting the environment is to determine what is unique in your farm and make accessing those servers easier for the people testing the updates. Include whether servers are virtual Machines or physical servers so that they can be located easily.

Environment : <>

Server Name	Role	IP Address	Logon information	Virtual / Physical

2.3 Validated Current/Future Service Packs and Cumulative Updates Doc

Document the location of the “Current and Future Service Packs and Cumulative Updates Tested” document here. This document should include all service packs and cumulative updates (and may include Windows Updates), when they were installed in the development, test, and production environments and the version number of the patch, along with whatever other information is valuable to you. You may consider storing testing validation results in this “updates tested” document or linking to a separate testing validation results document or folder.

2.4 Schedule of Testing and Maintenance Windows

Update testing should occur at least three weeks prior to the regularly scheduled maintenance window of the month. The tester will note the test environment patches to be installed in the current and future patches tested spreadsheet and install the patches in the DEV environment. At the appropriate interval, the updates should then be installed in TEST and eventually in PROD.

Two weeks prior to a regularly scheduled maintenance window, a change request should be created which includes the list of patches to be installed on each server in production. At this point, patch testing is frozen to ensure the test systems do not develop any problems and to limit the number of patches being applied to only those that have been tested and allowed to run for more than one week.

It is best practice to test Windows Updates separately from SharePoint and Project Server updates to better pinpoint the change that may have caused a new problem.

3. Installation Procedures - SharePoint 2010 Service Packs and Cumulative Updates

3.1 Pre-installation Steps

Document the time it takes to run the individual installation steps in DEV and TEST so you know what to expect in production and so you can build an accurate down time window to be relayed to your customers in your maintenance window downtime notifications.

Run the validation test steps listed in Section 5 below. This will establish a baseline of what functionality works prior to installing the update. Based on pre-update testing, you will know if anything breaks that was functioning previously.

Two weeks before the installation (in PROD, not DEV and TEST), contact your TAM at Microsoft and request a tech support person be on the phone during the maintenance window (at least, after the full farm backup has run, which takes a little time in the production environment).

One week before the installation (in PROD, not in DEV and TEST), confirm the appointment with the tech support person and the TAM via email and include this instruction set. The goal is NO surprises when the call actually occurs and the tech support representative should already be aware of your action plan.

On the day of the installation, see steps below.

On the Central Admin server, launch the SharePoint Central Administration site and choose System Settings > Manager Servers in this Farm. The Farm Information section has a “Configuration Database Version:” listing which should be 14.x.x.x (whatever the current version is) .

Copy the Service Pack and/or Cumulative Update to the web front end server and the Central Admin server (if it is a different server).

Quiesce the SharePoint 2010 farm so that users will not be connected to the sites.

Back up databases in SQL Server at the start of the maintenance window after the farm has quiesced when no new users can connect. NOTE: This may be impractical due to the size of the internal farm full farm backup and you may have to just verify that the SQL Server backup did run the night before. You can test the farm access by attempting to access your PWA URL. You will get an error message like below after the farm has quiesced, “Error: The administrator has taken this farm offline.”

Verify the regular nightly SQL Server backups ran successfully.

Note: As a best practice, you should test restoring production tape backups to a test server and provisioning PWA to the databases to ensure that you actually can restore backups from tape and successfully configure Project Server on a different system – once per quarter is probably sufficient to ensure you have good backups, but this decision is ultimately up the customer.

On the web front end and the Central Admin server, go to C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\LOGS and change the name of upgrade.log to upgrade.log.old, if it exists.

Run the SharePoint Configuration Wizard on the Central Admin server as a step to be sure the current installation is in good condition.

3.2 SharePoint Server 2010 Service Pack Installation

For Project Server 2010, you will need the SharePoint 2010 Foundation SP and SharePoint Server 2010 SP. The Project Server updates are usually rolled into the SharePoint Server updates, but you will need to verify this by reading the KB article for the SharePoint service pack.

On the Central Administration server, run the SharePoint 2010 Foundation service pack file.

Run the SharePoint 2010 Foundation service pack file on the app servers and WFE servers.

Reboot the servers, if prompted.

Repeat the above steps for the SharePoint Server 2010 service pack.

Run the SharePoint Configuration Wizard one at a time in all servers, starting first in Central Admin server and verify no errors occur. Do not run this wizard simultaneously in all the servers.

If you experience any error, go to C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\LOGS and check the upgrade.log for errors.

3.3 SharePoint Server Cumulative Update Installation

On the Central Administration server, run the cumulative update (CU) installation file.

Repeat the install of CU on the application and WFE servers

Reboot the servers, if prompted.

Run the SharePoint Configuration Wizard one at a time in all servers, starting first in Central Admin server and verify no errors occur. Do not run this wizard simultaneously in all the servers.

If you experience any error, go to C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\LOGS and check the upgrade.log for errors.

Apply the client updates to Project Professional 2010.

4. Verify Installation

On the Central Administration server, launch the SharePoint Central Administration site and choose Operations > Manage Servers in Farm. The Farm Information section has a “Version:” listing which should be 14.x.x.x (the new version) .

In all application and WFE servers, view "Add or Remove Programs" in Control Panel to see if it is listed in the currently installed programs list. Make sure that Show Updates is selected. Otherwise, the updates will not display. Look under Microsoft Office SharePoint Server 2010 for hotfixes from the cumulative update. The hotfix files should be identified with the applied hot fix KB number.

Verify the databases by querying the VERSIONS table in the content databases.

1. On the computer running the instance of SQL Server, open SQL Server Management Studio.
2. Click New Query.
3. Choose one of the content databases from the Available Databases drop-down list.
4. Type select * from versions in the query window and then click Execute.
5. The most recent version number in the Version results should correspond to the cumulative update file. It should be 14.x.x.x (change this value based on the update you are testing/installing) for the SharePoint Config database . The TimeStamp value should correspond to when the update was applied.
6. Repeat the query for all four Project Server databases, the SharePoint_Config database, and the WSS_Content DBs.

Run another SQL backup of the updated databases.

5. Testing Project Server 2010

Perform initial testing using the “Initial use setup”. Consider using an automated testing tool if human resources are hard to come by to reduce the validation testing window. After you complete the above checks, proceed to the following series of tests. Document the results.

Full Validation Testing Links