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
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.
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.
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.
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
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.
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.
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.
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.
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
Update Center for Office Servers, Office Products
Updates for SharePoint Server 2010
Updates for Project Server 2010
Project Server blogs:
Project Admin Blog
Brian Smith’s Blog
SharePoint Updates:
Todd Carters SharePoint Site : Includes Release, Version, KB Article Number and a download link.
Very good content, congratulations.