Export (0) Print
Expand All

Update Management Process

Updated : June 1, 2007

On This Page

In This Module
Objectives
Applies To
How To Use This Module
Overview
Deployment Preparation
Deployment of the Software Update to Targeted Computers
Post-Implementation Review
Summary
Next Steps

In This Module

This module describes the fourth phase—Deploy—of the four-phase update management process. The Deploy phase is concerned with the successful rollout of approved software updates into your production environment, so that you meet all of the requirements of any deployment service level agreements (SLAs) that you have in place.

The purpose of this module is to describe the principles of the Deploy phase of the update management process, and to introduce the types of tasks that enable deployment to be carried out using Microsoft Windows Server Update Service (WSUS) and Microsoft Systems Management Server (SMS).

Note: Beta 2 of the next release of SMS, entitled System Center Configuration Manager 2007, is now available for download at http://www.microsoft.com/technet/sms/2007/evaluate/download.mspx. With major investments in simplicity, configuration, deployment and security, Configuration Manager 2007 dramatically simplifies system deployment, task automation, compliance management, and policy based security management allowing for increased business agility.

After reading this module you will be able to plan the tasks needed to successfully:

  • Roll out the approved software update.

  • Deploy any necessary countermeasures.

Without a deployment process, you will not have the tried and tested set of tasks and activities required to deploy a software update into your production environment, or to deploy any necessary countermeasures or mitigation steps.

Objectives

Use this module to:

  • Prepare for deployment.

  • Deploy a software update to targeted computers.

  • Review the deployment, post-implementation.

Applies To

This module applies to all Microsoft products and technologies.

How To Use This Module

While the basic tasks needed to carry out assessment using WSUS and SMS are described in this module, you can find more detailed instructions in the Technical Libraries listed below.

To gain the most from this module, you should:

Overview

The Deploy phase is the fourth phase in the update management process, as shown in Figure 1.

Figure 1. The update management process

Figure 1. The update management process

The Deploy phase focuses on the tasks and activities required to deploy a software update into the production environment. Additional tasks may be required to deploy any countermeasures or mitigation steps.

The entry point for this phase is a determination that the software update is ready for deployment into production and that approval has been obtained to deploy the software update.

The goal for the Deploy phase is to successfully roll out the approved software update and/or any countermeasures into your production environment.

The deployment of a software update consists of the following activities:

  • Deployment preparation.

  • Deployment of the software update to targeted computers.

  • Post-implementation review.

Deployment Preparation

The production environment needs to be prepared for each new release. The steps required for preparing the software update for deployment include the following:

  • Communicating rollout schedule to the organization.

  • If WSUS is deployed:

    • Staging the updates on WSUS servers.

  • If SMS is deployed:

    • Importing programs and advertisements from the test environment.

    • Assigning distribution points.

    • Staging the updates on the distribution points.

    • Selecting deployment groups.

For more information about deployment preparation in WSUS or SMS environments, see Windows Server Update Services (WSUS) Technical Library or Technical Library for Systems Management Server 2003.

Communicating Rollout Schedule to the Organization

It is important to tell end users and administrators about the impending release of an update. You should send a clear and easily identifiable e-mail message to users and administrators, which both notifies them of the update and provides information about how to install it. You should flag the mail for follow-up to remind users and administrators of the actions they need to take.

In the situation when you are deploying an update to desktops outside of core business hours, the e-mail message should tell users to leave their computers on overnight on a specified date. If this message is flagged for follow-up as shown in Figure 2, then the users will receive a reminder at 4:30 P.M. on May 30, 2003, to leave their computers on for the night.

Cc700833.gr36(en-us,TechNet.10).gif

Figure 2. This screen shot illustrates how an e-mail flagged for follow-up can be used as a reminder

If you use WSUS, the communications process includes additional considerations, which depend on the download and installation policy settings for the WSUS client:

  • Notify for download and notify for installation. A user who logged on with local administrator rights will need to select the option to download the update whenever the New update available for download notification appears in the task bar. In order to complete the installation, they will then need to install the software update when the New update available for installation notification appears.

  • Automatically download and notify for installation. Newly approved updates that apply to the client computer are automatically downloaded by the Automatic Updates client. To install the updates, a user who logged on with local administrator rights will need to select the option to install the software update when the New software update available for installation notification appears.

  • Automatically download and schedule the install. A user who logged on with local administrator rights can install an update prior to the scheduled install time, or delay the restart (should this be required) after installation completes. For users without local administrator rights, the update will install in the background at the scheduled time. These users can only delay a computer restart, if the No auto-restart for scheduled Automatic Updates installations policy setting has been enabled.

To find more detailed information on using WSUS in the Deploy phase, see Windows Server Update Services (WSUS) Technical Library.

Deployment Preparation using SMS

If you use SMS 2003, there are several additional steps to consider to prepare for deployment:

  • Importing programs and advertisements from your test environment. First, packages built and tested in the test environment must be imported into the production SMS 2003 environment.

  • Assigning distribution points. You then need to assign distribution points; software update binaries should be placed on distribution points at all the sites where target clients are located. If the Distribute Software Updates Wizard can be used, distribution points can be assigned using the wizard (and amended manually once the package has been created).

  • Staging updates on distribution points. The next step is to ensure that copies of all files are placed on the distribution point servers. The process of sending software update binaries to distribution points involves sending the files between SMS sites, and from SMS sites to local distribution points.

  • Selecting deployment groups. If you use the Distribute Software Updates Wizard to distribute a new software update, you do not have to target computers precisely. This is because the wizard deploys a smart agent, which is invoked when a new update needs to be installed. The agent automatically determines whether an update is applicable to that computer (and whether it has already been installed). If updates are being distributed through a custom package and collection, then you may need to create one or more SMS queries, in order to deploy the update to the appropriate computers.

For more detailed information on using SMS in the Deploy phase, see Technical Library for Systems Management Server 2003.

Deployment of the Software Update to Targeted Computers

The process you use to deploy the software update into the production environment will depend on the type and nature of the release, as well as the release mechanism you select.

It will also depend significantly on whether the software update is an emergency. Because of the urgency associated with emergency changes, there will be some differences in how you deploy them. Those differences will be highlighted throughout this section.

Ideally, you should release software updates through a phased deployment, which minimizes the impact of any failures or adverse effects that might be introduced by the initial distribution of a software update.

The steps required to deploy a software update in production include:

  • Advertising the software update to client computers.

  • Monitoring and reporting on the progress of deployment.

  • Handling failed deployments.

Advertising the Software Update to Client Computers

If you use WSUS, and a phased rollout is not required, you only need to approve the update on the WSUS parent server for it to be made available to clients. WSUS clients will then begin to download the newly approved update, either at the next detection cycle or when prompted by the local administrator (if the Automatic Updates client is configured to notify the local administrator when new updates are available).

However, if there is to be a phased rollout, you should first approve the update on the parent WSUS server only. Then, after the update has been successfully deployed to clients supported by that server, you should enable synchronization of the approvals list on the WSUS child server that supports clients in the next phase of the rollout.

To find more detailed information on using WSUS in the Deploy phase, see Windows Server Update Services (WSUS) Technical Library.

If you use SMS, and you use the Distribute Software Updates Wizard, a repeating advertisement is automatically created, which runs the software update installation agent on computers in the target collection. If necessary, you can alter the repeat interval from the default value of seven days. For example, a collection including servers may run the agent once per day. Using the same package and program, you can create advertisements for multiple collections, if you need to create different schedules for different types of computers. If the rollout is being staggered, you would modify the query after each phase, so that clients in the next phase are included.

If you are not using the Distribute Software Updates Wizard, when an advertisement is set up to install an update, its schedule should be configured to repeat at intervals. This is so that a failed installation is automatically retried. The advertisement repeat interval needs to be carefully chosen, because clients that have already successfully installed the update will remain in the target collection until a new inventory has been collected—which may be triggered by the installation program itself—or until the inventory has been updated in the SMS database and the collection is re-evaluated. Therefore, the program could be rerun on a client that has already successfully run it once. For this reason, it is essential that the program run checks first to see whether the software updates are installed, and that it exits without delay if they are.

To find more detailed information on using SMS in the Deploy phase, see Technical Library for Systems Management Server 2003.

Emergency Change Request

For information on how to manage emergency change requests using WSUS, see Windows Server Update Services (WSUS) Technical Library and to see how to manage emergency change requests using SMS, see Technical Library for Systems Management Server 2003.

Monitoring and Reporting on Deployment Progress

Computers can fail to install an update for several reasons, such as:

  • The computer is offline.

  • The computer is being rebuilt or re-imaged.

  • The computer has insufficient disk space.

  • In WSUS environments:

    • The computer is not communicating with the WSUS server (for computers with the Automatic Updates client).

    • The Automatic Updates client service has been stopped.

  • In SMS environments:

    • The computer's SMS clients are not communicating with the SMS site servers.

    • The computer has had its agent service stopped, either by a user or as part of maintenance.

  • In SMS 2003 environments:

    • The computer has MSXML 3 up to SP1 (SMS 2003 requires MSXML 3.0 SP4).

For more detailed information on using WSUS in the Deploy phase, see Windows Server Update Services (WSUS) Technical Library.

To monitor for successful update release in SMS, you can use the Advertisement Status Viewer to show the deployment status of advertisements, based on their status messages. Status messages report only whether the repeating advertisement was run, not whether the update was installed. To get this information you need to analyze the status messages to determine when the Patch Install program was last successfully run on each client; if the time since it was run is longer than the repeat period for any clients, you should investigate.

For software updates identified through the Security Updates Inventory Tool, the Inventory Tool for Microsoft Updates, or the Microsoft Office Inventory Tool for Updates, you can use the built-in reports to check for successful deployment. The Compliance by Software ID report can be used to provide a summary of the total number of systems on which the update is installed or missing, as well as the status relating to the distribution of the software update.

For more information about using SMS in the Deploy phase, see Technical Library for Systems Management Server 2003.

Handling Failed Deployments

If you face exceptions during a normal deployment, you should have sufficient time to stop, determine the root cause, and re-deploy. However, during an emergency deployment, the time available for triage and root cause assessment will be much shorter.

Your organization may also decide that a deployment is unsuccessful and needs to be stopped and rolled back. You must have a plan in place to stop the rollout, uninstall failed updates, and then redeploy them.

In WSUS Environments

For failed deployments in a WSUS environment, you must cancel approval of the update on the WSUS server, in order to prevent further installations. On clients that have already downloaded the update, but have not yet installed it, local administrators can manually remove it from the list of updates to be installed. If a computer has installed an approved update, the update can only be removed by using the Add or Remove Programs facility in Control Panel (assuming that the update can be uninstalled). For more detailed information on using WSUS in the Deploy phase, see Windows Server Update Services (WSUS) Technical Library.

In SMS Environments

If you use SMS, handling failed deployments involves four main tasks:

  • Stopping the deployment of the active package, until the problem has been resolved.

  • Identifying and resolving the problem - that is, working out why the deployment failed.

  • Re-advertising the package.

  • Uninstalling the software update, by creating an Uninstall package (if the update can be uninstalled).

For more information about using SMS in the Deploy phase, see Technical Library for Systems Management Server 2003.

Post-Implementation Review

The post-implementation review should typically be conducted within one to four weeks of a release deployment to identify improvements that should be made to the update management process.

A typical agenda for a review includes:

  • Ensure that the vulnerabilities are added to your vulnerability scanning reports and security policy standards, so the attack does not have an opportunity to recur.

  • Ensure that your build images have been updated to include the latest software updates following the deployment.

  • Discuss planned versus actual results.

  • Discuss the risks associated with the release.

  • Review your organization's performance throughout the incident. Take this opportunity to improve your response plan to include any lessons learned.

  • Discuss changes to your service windows.

  • Assess the total incident damage and costs, including both downtime and recovery costs.

  • Create another baseline or update the existing baseline for your environment.

Summary

During the Deploy phase, you should have accomplished the following key activities:

  • Established the order in which the software updates will be rolled out into production.

  • Surveyed your production environment to ensure it would be able to handle the software update.

  • Placed the software update files on WSUS servers and SMS distribution points.

  • Deployed the software update into production.

  • Rescanned your environment to assess success, and updated any computers that failed to install the software update.

  • Performed a review of the update management process once the deployment is complete.

Next Steps

Once you have deployed the software update, you should return to the Assess phase, where you can continue to:

  • Inventory/discover existing computing assets.

  • Assess security threats and vulnerabilities.

  • Determine the best source for information about software updates.

  • Assess the existing software distribution infrastructure.

  • Assess operational effectiveness.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft