Testing Updates
After applying an update or group of updates to your test computers, test all applications and functionality. The amount of time and expense that you dedicate to testing the update should be determined by the potential damage that can be caused by a problematic update deployment. There are two primary ways you can test an update: in a test environment and in a pilot deployment. A test environment consists of a test lab or labs and includes test plans, which detail what you will test, and test cases, which describe how you will test each feature. Organizations that have the resources to test updates in a test environment should always do so because it will reduce the number of problems caused by update incompatibility with applications. Even if your organization does not have the resources to test critical updates and security updates, always test service packs before deploying them to production computers.
The test lab can be made up of a single lab or of several labs, each of which supports testing without presenting risk to your production environment. In the test lab, members of the testing team can verify their deployment design assumptions, discover deployment problems, and improve their understanding of the changes implemented by specific updates. Such activities reduce the risk of errors occurring during deployment and allow the members of the test team to rapidly resolve problems that might occur while deploying an update or after applying an update.
Many organizations divide their testing teams into two subteams: the design team and the deployment team. The design team collects information that is vital to the deployment process, identifies immediate and long-term testing needs, and proposes a test lab design (or recommends improvements to the existing test lab). The deployment team completes the process by implementing the design team's decisions and then testing new updates on an ongoing basis.
During the beginning of the lifetime of the update test environment, the deployment team will test the update deployment process to validate that the design is functional. Later, after your organization identifies an update to be deployed, the deployment will test the individual updates to ensure that all of the updates are compatible with the applications used in your environment.
An update test environment should have computers that represent each of the major computer roles in your organization, including desktop computers, mobile computers, and servers. If computers within each role have different operating systems, have each operating system available on either dedicated computers, a single computer with a multiboot configuration, or in a virtual desktop environment.
After you have a set of computers that represent each of the various types of computers in your organization, connect them to a private network. You will also need to connect test versions of your update infrastructure computers. For example, if you plan to deploy updates by using WSUS, connect a WSUS server to the lab network.
Load every application that users will use onto the lab computers and develop a procedure to test the functionality of each application. For example, to test the functionality of Internet Explorer, you can visit both the Microsoft Web site and an intranet Web site. Later, when testing updates, you will repeat this test. If one of the applications fails the test, the update you are currently testing might have caused a problem.
Note If you will be testing a large number of applications, identify ways to automate the testing of updates by using scripting.
In addition to testing your implementation of an update, conducting a pilot deployment provides an opportunity to test your deployment plan and the deployment processes. It helps you to determine how much time is required to install the update as well as the personnel and tools needed to do so. It also provides an opportunity to train support staff and to gauge user reaction to the update process. For example, if a particular update takes an hour for a dial-up user to download, you might have to identify an alternative method for delivering the update to the user.
Note The more significant the update, the more important it is to use a pilot program. Service packs, in particular, require extensive testing both in and out of the lab.
Besides testing the update yourself, subscribe to mailing lists and visit newsgroups frequented by your peers. People tend to report problems with updates to these forums before an official announcement is made by Microsoft. If you do discover a problem, report it to Microsoft. Historically, Microsoft has fixed and re-released security updates that have caused serious problems. On the other hand, Microsoft support might be able to suggest an alternative method for reducing or eliminating the vulnerability.
In this tutorial:
- Managing Software Updates
- Methods for Deploying Updates
- Windows Update Client
- Windows Server Update Services
- System Center Configuration Manager 2007 R2
- Manually Installing, Scripting, and Removing Updates
- Overview of Windows 7 Update Files
- How to Script Update Installations
- How to Remove Updates
- Deploying Updates to New Computers
- Other Reasons to Use a Private Network for New Computers
- Managing BITS
- BITS Behavior
- BITS Group Policy Settings
- Configuring the Maximum Bandwidth Served For Peer Client Requests Policy
- Managing BITS with Windows PowerShell
- Windows Update Group Policy Settings
- Configuring Windows Update to Use a Proxy Server
- Tools for Auditing Software Updates
- The MBSA Console
- MBSACLI
- Scheduling MBSA
- Troubleshooting the Windows Update Client
- The Process of Updating Network Software
- Assembling the Update Team
- Inventorying Software
- Creating an Update Process
- Discovering Updates
- Evaluating Updates
- Speeding the Update Process
- Retrieving Updates
- Testing Updates
- Installing Updates
- Removing Updates
- Auditing Updates
- How Microsoft Distributes Updates
- Security Updates
- Update Rollups
- Service Packs
- Microsoft Product Life Cycles