How To Perform Patch Management Using SUS

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : February 6, 2004

On This Page

Objectives
Applies To
How To Use This Module
Summary
Before You Begin
What You Must Know
Assess Phase - Scanning for Updates
Assess Phase - Baselining Your Environment
Assess Phase - Designing the SUS Infrastructure
Identify Phase - Obtaining Notifications
Identify Phase - Processing Notifications
Identify Phase - Ensuring That Security Updates Are Safe
Evaluate and Plan Phase - Scheduling Updates
Evaluate and Plan Phase - Deploying Emergency Change Requests
Evaluate and Plan Phase - Building the Release
Deploy Phase - Communicating the Rollout Schedule
Deploy Phase - Staging Updates on SUS Servers
Deploy Phase - Advertising Software Updates to Client Computers
Deploy Phase - Monitoring and Reporting on Deployment Progress
Deploy Phase - Handling Failed Deployments

Objectives

Use this module to:

• Implement all four phases of the patch management process using SUS and MBSA.

Applies To

This module applies to the following products and technologies:

• Microsoft Software Update Services (SUS) 1.0 with Service Pack 1

• Microsoft Baseline Security Analyzer (MBSA) version 1.1.1

How To Use This Module

This module provides details on how to use SUS and MBSA to implement the four-phase patch management process.

To gain the most from this module, you should:

• Read the module, "The Patch Management Process." This will give you an overview of each of the four phases in the patch management process, and provide an introduction to the tools available to support patch management in Microsoft Windows operating system environments.

• Read the following four modules, which describe the four-phase patch management process in detail:

  • Read the module, "Patch Management Phase 1 - Assess."

  • Read the module, "Patch Management Phase 2 - Identify."

  • Read the module, "Patch Management Phase 3 - Evaluate and Plan."

  • Read the module, "Patch Management Phase 4 - Deploy."

• Read the "Software Update Services Deployment White Paper," which can be downloaded from the SUS site at https://www.microsoft.com/windowsserversystem/sus/default.mspx.

• Read the "Microsoft Baseline Security Analyzer" introduction, located at https://www.microsoft.com/mbsa.

Summary

This module covers the use of SUS and MBSA to deliver enterprise patch management. The guidance and information provided in this module will show you how to implement the four-phase patch management process that is recommended by Microsoft.

Before You Begin

Before you begin to use this module, you need to perform the following preparatory steps:

• Download MBSA

  Download MBSA from the MBSA Home Page, located at https://www.microsoft.com/technet/security/tools/mbsahome.mspx.

• Download the latest MBSA XML file

  If the machine you use has Internet access, the latest security XML file will be downloaded automatically, if needed. If your computer does not have Internet access, however, you need to download the latest XML file using the signed .cab file at the following location: https://www.microsoft.com/downloads/details.aspx.

  The .cab file is signed to ensure it has not been modified. You must uncompress it and store it in the same folder where MBSA is stored.

  Note To view the latest XML file without downloading it, use the following location: https://www.microsoft.com/technet/security/search/mssecure.xml

• Install MBSA

  You can install MBSA using Mbsasetup.msi. The default installation directory is: \Program Files\Microsoft Baseline Security Analyzer\.

  Note You need to run commands from this directory. MBSA does not create an environment variable for you.

• Download SUS 1.0 with SP1

  You can download SUS 1.0 with SP1 from https://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-AE66A4E4BF6C&displaylang=en

• Install SUS 1.0 with Service Pack 1

  Install using SUS10SP1.exe.

What You Must Know

Before using this module, you should be aware of the following:

• You can operate MBSA either by using the GUI (Mbsa.exe) or from the command line (Mbsacli.exe).

• MBSA uses ports 138 and 139 to perform its scans.

• MBSA requires administrator privileges on the computer that you scan. The options /u (username) and /p (password) can be used to specify the user name to run the scan. Do not store user names and passwords in text files, such as command files or scripts.

• MBSA requires the following software:

  • Microsoft Windows XP, Microsoft Windows 2000, or Microsoft Windows NT 4.0 SP4 and later operating system (local scans only on Windows XP computers that use simple file sharing)

  • Internet Information Services (IIS) 4.0, 5.0 (required for IIS vulnerability checks)

  • Microsoft SQL Server™ 7.0, 2000 (required for SQL vulnerability checks)

  • Microsoft Office 2000, XP (required for Office vulnerability checks)

• For MBSA, the following services must be installed/enabled:

  • Server service

  • Remote Registry service

  • File and Print Sharing

• SUS only works over port 80; the Automatic Updates component on a client is only capable of communicating with the SUS server on that port.

• SUS 1.0 SP1 runs on Windows 2000 Server with Service Pack 2 or later. IIS must be enabled on the server.

Assess Phase - Scanning for Updates

An audit must be carried out before you can begin to use SUS to deploy software updates into your production environment. For background information, see the section "Inventory/Discover Existing Computing Assets" in the module, "Patch Management Phase 1 - Assess."

If you use SUS for patch management you must use MBSA for auditing and scanning. MBSA reports on missing security updates and service packs, as well as identifying vulnerabilities, for the following operating systems:

• Microsoft Windows Server™ 2003

• Windows XP

• Windows 2000

• Windows NT 4.0

MBSA will also report on whether the computer configuration adheres to common security best practices (such as strong passwords).

Furthermore, MBSA reports on missing security updates for the following applications:

• Microsoft Internet Information Server 4.0

• Microsoft Internet Information Services 5.0 and 6.0

• Microsoft SQL Server 7.0 and SQL Server 2000, including Microsoft SQL Server Desktop Engine (MSDE) 1.0 and MSDE 2000

• Microsoft Exchange Server 5.5 and Exchange Server 2000 (including Exchange administration tools)

• Microsoft Internet Explorer 5.01 and later

• Microsoft Windows Media Player 6.4 and later

MBSA will also identify misconfigured settings for the following applications:

• Internet Information Server 4.0

• Internet Information Services 5.0 and 6.0

• Internet Explorer 5.01 and later

• SQL Server 7.0 and SQL Server 2000 (including MSDE 1.0 and MSDE 2000)

• Office 2000 and Office XP

To scan for updates using MBSA

1. On a workstation that has MBSA installed, log on as the domain administrator and run the MBSA GUI.

2. Click Pick multiple computers to scan and enter the domain name or Internet Protocol (IP) address range to scan. If you are scanning the entire domain, the name you enter must be the NetBIOS name of the domain, not the Fully Qualified Domain Name (FQDN) used within DNS.  

3. Select Use SUS Server and enter **https://**server where server is the required SUS server name, as shown in Figure 1.

   

   Figure 1. Scanning computers in a domain or range of IP addresses

4. Click Start scan and wait for results.

5. Click Pick a security report to view and click a computer to view its report.

6. Click Results details to view further details.

   Note: MBSA only detects the presence or absence of software updates for operating systems and software applications that are listed in Microsoft Knowledge Base article 306460, "Hfnetchk Returns Note Messages for Installed Patches," at https://support.microsoft.com/default.aspx?scid=kb;en-us;306460.

The output of MBSA will identify those software applications for which it has been programmed to scan are physically installed in your IT infrastructure, as well as the security updates that need to be applied to make those applications secure.

Figure 2 shows an example in which IIS 5.0 has been installed on a Windows 2000 member server.

Figure 2. Output from MBSA scan

The GUI version of MBSA scans for file version and registry key information. A more comprehensive scan of the production environment can be performed using the command-line version of MBSA (Mbsacli.exe), which verifies file checksum versions, file version, and registry key information for each scanned security update.

There are two options for using the MBSA command-line version:

• With the /hf switch to perform a security update scan only

• Without /hf to perform a full computer scan

Using Mbsacli.exe with the /hf switch creates scan results that can be viewed at the command line or sent to an output file, whereas using Mbsacli.exe without the /hf switch will produce an XML scan report that can later be viewed in the MBSA GUI. The output from Mbsacli.exe /hf can be imported into Microsoft Excel or a text file for further analysis.

Assess Phase - Baselining Your Environment

You can use the output from the MBSA command-line utility (Mbsacli.exe /hf) together with the PivotTable and PivotChart Report function within Microsoft Excel to identify what has been deployed in the production environment and to set an appropriate baseline. For background information, see the section "Inventory/Discover Existing Computing Assets" in the module, "Patch Management Phase 1 - Assess."

Note: SUS clients automatically apply updates made available to them (and that have been approved) on the SUS server. These updates, therefore, might not need to be included in the build images, but can be applied when a new computer joins the domain. In practice, however, many of the updates made available through SUS are either critical to the successful operation of the computer or reduce exposure to security vulnerabilities. This means that administrators should add new security updates to the base build, so new computers are protected from the moment they are deployed into production.

Assess Phase - Designing the SUS Infrastructure

Assessing the software distribution infrastructure is another key part of an effective patch management process. For background information, see the section "Assess the Existing Software Distribution Infrastructure" in the module, "Patch Management Phase 1 - Assess".

Only one SUS parent server should be configured to automatically download software updates from the Microsoft public Windows Update servers, as shown in Figure 3. Note that only updates that have gone through testing and have been approved for deployment should be approved on the parent server.

Figure 3. Recommended SUS topology

Using a preconfigured synchronization schedule, the SUS parent server downloads critical updates and security updates on a daily basis from the public Microsoft Windows Update servers. It requires that the outbound TCP port 80 be open through the firewall.

The SUS test server is configured to download the updates from the SUS parent server. This also occurs on a scheduled daily basis, with the synchronization time set to one hour after the SUS parent server synchronizes with the public Microsoft Windows Update servers. (One hour is the closest possible time to the SUS parent server synchronization schedule.) This is to ensure that the packages are present on the SUS test server as soon as possible and are ready for approval and testing.

The SUS test team should approve the new updates on the SUS test server. After they have been approved, the updates become immediately available to all SUS test clients. To avoid having all SUS test clients poll the SUS test server at the same time, they will poll the server every 22 hours, with up to a 20 percent reduction for randomization. After testing is deemed successful for a specific update, the SUS administrator should approve that update on the SUS parent server.

Once the update is approved on the SUS parent server, then the SUS clients reporting in to that server will begin downloading from it within 22 hours by default. Installation starts according to the specified schedule, or when it is performed by the local administrator. Client computers reporting in to SUS child servers will start downloading the update, within 22 hours from the point at which the approval reaches the child server.

The SUS child servers are configured to automatically synchronize with the parent server on a daily basis. Child servers synchronize and download all contents, as well as the approved items from the SUS parent server. After synchronization occurs, all approved updates on the SUS parent server are mirrored on the SUS child servers, and are immediately available to the production SUS clients that are configured to poll critical and security updates from such SUS child servers.

In the topology design shown in Figure 3, administrators need only approve an update on the SUS parent server for it to be made available to all production SUS clients. It is always possible to initiate a manual synchronization on all SUS servers.

Microsoft occasionally updates the detection criteria (metadata) for a software update, which will cause a software update to appear with an "updated" status. There might also be occasions when a software update has been re-issued and this will also cause an "updated" status to appear in the interface. There are few occurrences of software updates being re-released, however, and when one is, information about that appears in the software update bulletin. If the original version of the update has already been approved in the SUS GUI, the SUS administrator can configure the SUS server either for auto-approval or for manual approval of the re-released version of the update.

To ensure that revised updates are not automatically released into production without testing, the administrator should select the option Do not automatically approve new versions of approved updates. I will manually approve these updates later on the SUS server.

Synchronization Intervals

The parent server should be configured to pull updates from the public Microsoft Windows Update server on a daily synchronization schedule, although administrators can request updates more frequently by manually selecting the Synchronize now option in the SUS Server Administration Page.

The download should be configured so that it occurs at network quiet times. Normally, once a day should be sufficient, as shown in Figure 4.

Figure 4. Configuring SUS to download updates

Note that child servers should be configured to automatically pull new updates from the parent server at scheduled intervals. This interval should occur at least one hour after the parent server pulls the updates from the public Microsoft Windows Update servers.

If administrators are made aware of updates that occur before the next scheduled download, they can use the Synchronize now option.

Identify Phase - Obtaining Notifications

Once you have assessed your environment, the next phase involves problem identification, and getting information on available updates. For background information, see the section "Discover a New Software Update" in the module, "Patch Management Phase 2 - Identify."

Microsoft Security Notification Service

Notification by e-mail is the most common form of software update notification. One option for e-mail notification is to subscribe to the Microsoft Security Notification Service at https://www.microsoft.com/technet/security/bulletin/notify.mspx.

SUS Patch Alert Service

If you have signed up for the SUS patch-alert service, you will normally be informed of new updates that can be deployed using SUS through an e-mail message, similar to the one shown in Figure 5. The e-mail indicates that new updates are available for download on the public Windows Update servers, but does not indicate what those updates are.

Figure 5. Example e-mail message notifying administrators of new software updates available through Microsoft Software Update Services

Identify Phase - Processing Notifications

Once you have received a notification, you need to identify which software updates have been made available. For background information, see the section "Discover a New Software Update" in the module, "Patch Management Phase 2 - Identify."

In SUS, you should force synchronization to occur between the SUS server and the public Windows Update server whenever you receive a new e-mail update notification. This can be achieved by using the Synchronize Now option in the SUS Server Administration Page, as shown in Figure 6.

Figure 6. Forcing an SUS server to synchronize content with the Microsoft Windows Update servers

Note: Only those updates that appear in the SUS Server Administration Page can be deployed via SUS.

To determine the relevance of an individual software update to computers within the production environment, you should read the associated security bulletin or Knowledge Base article. This documentation can be accessed from within the SUS Server Administration Page by following the procedure described below.

To Find the Details of a Software Update

1. Click the approval log hyperlink.

2. Find the particular update to be examined.

3. Click Details... for that particular update (as shown in Figure 7).

   

   Figure 7. SUS approval log

4. In the Update Details dialog box, click the Info icon (as shown in Figure 8).

   

   Figure 8. Accessing supporting information for an update

   Note: When administrators select a specific update for approval through the SUS Server Administration Page, the update automatically notifies them of dependencies on other updates. Approving the specific update automatically approves all of the updates that the specific update depends on. The Automatic Updates client will ensure that these updates are installed in the correct order.

Identify Phase - Ensuring That Security Updates Are Safe

As mentioned earlier, all security updates that are made available by Microsoft from the public Windows Update servers are digitally signed. The signature for each new update automatically checks when the SUS server downloads the security update. For background information, see the section "Determine Whether Software Updates Are Relevant" in the module, "Patch Management Phase 2 - Identify."

The SUS parent server downloads new updates and stores them with temporary file extensions (.tmp). Only after the digital signature has successfully been checked will the files be renamed with their original file extension (for example, .exe) and placed in the \Content\Cabs folder as shown in Figure 9.

Figure 9. Location of digitally signed updates on the SUS server

If an update does pass digital signature checking, an error is written to the event log on the SUS download sever, and the synchronization log indicates a failure to download the update due to signature check failure, as shown in Figure 10.

Figure 10. Failure in digital signature validation

The SUS administrators must check the synchronization log for download failures on a daily basis. The SUS clients perform the same process, whether they download updates from the public Windows Update servers or from an SUS server.

Because the SUS parent server is the source of updates for clients and SUS servers within the organization, SUS administrators should ensure that a virus scanner is installed as a service on this computer and that it is configured to scan all incoming and outgoing files.

Verifying the Software Update Install Procedures

It is important to test that the uninstall works. After uninstalling, you should check that the server continues to run as expected and continue to watch the Event Log and System Monitor counters.

Software updates cannot be automatically uninstalled by SUS, so you must remove them manually using Add or Remove Programs in the Control Panel. If a large number of computers are affected, it may be better to develop a script that performs this task.

Evaluate and Plan Phase - Scheduling Updates

If you have business-critical computers, which have specific times at which changes and computer restarts are permitted (outage windows), the deployment of a software update - and any system restarts that are required as a result - will need to be scheduled within these outage windows. For background information, see the section "Plan the Release" in the module, "Patch Management Phase 3 - Evaluate and Plan".

To Schedule Updates in an SUS Environment

1. Configure policy settings in Group Policy objects (GPOs) to download but not installthe required updates, using the Automatic download and notify for installation setting.

2. Monitor the event logs on these servers to confirm that the required updates have been downloaded and are awaiting installation.

3. Log on to the server and start the installation - and authorize restart of the computer if required - at the date and time agreed to with the change manager.

If you schedule the installation of new updates (and possible computer restarts) on workstations outside normal working hours, it is essential that you use the Reschedule Automatic Updates scheduled installations GPO setting to enable computers that have missed a scheduled installation to reschedule the installation to occur when the Automatic Updates service starts.

Note: If this GPO setting is not used, then, when a scheduled installation is missed (because the client computer was turned off), the installation will not occur after this point, even when the computer is restarted. Instead, the SUS client software will wait until the next scheduled start time to try the installation again. This poses a potential issue: unless the computer is online at the scheduled install time, updates will never be applied.

By default, upon the installation of an update requiring a restart, users without local administrator rights will have only five minutes to save or secure their work before the computer performs a forced restart.

To Prevent Forced Restarts

1. Control restart behavior using the No auto-restart for scheduled Automatic Updates installations GPO setting. When enabled, this GPO setting prevents Automatic Updates from automatically restarting a computer while users are still logged on.

2. For this setting to be effective, the end users must have restart privileges on their computers.

Note: If the product to be patched was deployed using Windows Installer, the Installer may require access to original installation files. If you are performing an unattended installation of the software update, these files need to be in the same location as they were when the product was originally installed. If the product was installed from physical media, such as a CD drive, for example, Windows Installer will try to find the original files on the currently inserted CD.

Evaluate and Plan Phase - Deploying Emergency Change Requests

Emergency change requests require specific procedures and considerations. For background information, see the section "Plan the Release" in the module, "Patch Management Phase 3 - Evaluate and Plan."

If the change request indicates that the software update is regarded as business critical, then you must:

• Use Group Policy to force clients to install the software update before their regularly scheduled maintenance window.

• Override the normal synchronization schedule, whereby child SUS servers synchronize updates at network quiet times, by forcing replication between the SUS server that downloaded the updates and any child servers by using the Synchronize now option in the SUS Server Administration page.

Evaluate and Plan Phase - Building the Release

Before updates can be deployed, you may need to prepare the update executables and distributions. For background information, see the section "Building the Release" in the module, "Patch Management Phase 3 - Evaluate and Plan."

The updates deployed by SUS are downloaded directly from the public Windows Update servers and are already packaged in the .exe file format, so no additional work is needed in order to repackage them for deployment.

Performing a Pilot Rollout Using SUS

For background information, see the section "Acceptance Testing" in the module, "Patch Management Phase 3 - Evaluate and Plan."

To Perform a Pilot Rollout

1. Approve the update on the SUS pilot server only. Do not approve it on any other SUS server.

2. Create a new site level GPO (referred to as SUS pilot GPO) and configure the policy settings so that computers that apply this GPO refer to the SUS pilot server for updates.

3. Apply security filtering so that only the SUS pilot clients have "read and apply policy settings" rights to this GPO.

4. Ensure the SUS pilot GPO has priority by placing it at the top of the list of GPOs assigned to the site. Verify that the Enforce (Windows 2003) or No Override (Windows 2000) option is enabled to ensure that the policy is applied.

5. Once the update has been successfully deployed into production, administrators should delete the SUS pilot GPO. Clients involved in the pilot should revert back to the production SUS server for new updates, once they refresh Group Policy.

If the pilot proved unsuccessful, then it will be necessary to "unapprove" it on the pilot SUS server and uninstall it from clients that have already installed it. Administrators will need to do this manually, using Add or Remove Programs in the Control Panel wherever possible. For updates that cannot be uninstalled manually, use the System Restore utility for Windows XP, the backup-and-restore tools for Windows Server 2003 and Windows 2000 (or other recovery technologies in use) to revert the client back to the last known good state prior to update installation.

Deploy Phase - Communicating the Rollout Schedule

Before updates can be safely and successfully deployed, your users need to be informed, as there may be specific actions they need to carry out to aid the update installation process. For background information, see the section "Deployment Preparation" in the module, "Patch Management Phase 4 - Deploy."

To Clearly Communicate the Rollout Schedule

1. Send a clear and easily identifiable e-mail message to users and administrators warning them of the update and providing information about how to install it. If the update is aimed for desktops outside of core business hours, then the e-mail message should tell end users to leave their computers on overnight on a specified date.

2. This mail should be flagged for follow-up, in order to remind users and administrators of the actions they need to take to install the software update. These actions will depend on the download and installation policy settings that are in force for a particular SUS client:

   • Notify for download and notify for installation

     A user logged on with local administrator rights will be notified about newly approved updates that apply to the client computer and 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, users will need to select the option to install the software update when the New update available for installation notification appears once the download is complete.

     The Automatic Updates client will not contact the SUS server for any further updates, as long as currently detected updates have not been installed.

   • Automatically download and notify for installation

     Newly approved updates that apply to the client computer are automatically downloaded by the Automatic Updates client. In order to install the software update, a logged-on user with local administrator rights will need to select the option to install when the New software update available for installation notification appears.

     The Automatic Updates client will not contact the SUS server for any further updates, as long as currently detected updates have not been installed.

   • Automatically download and schedule the install

     If this option is selected, users logged on with local administrator rights will be notified that a new update is available and be provided with the option to install an update prior to the scheduled install time or to delay the restart after installation completes (should this be required).

     Users without local administrator rights will not have this option and the update will install - in the background - at the scheduled time. These users have the option to delay a computer restart, only if the No auto-restart for scheduled Automatic Updates installations policy setting has been enabled. If this is setting is not enabled, the Automatic Updates client will inform the user that the system will be shut down within five minutes and it will automatically restart the system after this period expires.

     Note: It is also essential that the Reschedule Automatic Updates scheduled installations GPO setting be used to enable computers that have missed a scheduled installation to reschedule the installation to occur when the Automatic Updates service starts.

Deploy Phase - Staging Updates on SUS Servers

For clients to install a new update, it must be present on their local SUS server. For background information, see the section "Deployment Preparation" in the module, "Patch Management Phase 4 - Deploy." To avoid affecting normal business operations, you should schedule SUS child sites to synchronize updates (and the list of approved updates) at network quiet times. You will need to check the synchronization log on each child server to check whether the particular update is available on that server. Figure 11 illustrates this process.

Figure 11. Checking that updates are available on child servers

If the update is not yet present on an SUS child server, then you should run a manual synchronization to download the update and then check the synchronization log to confirm that the update has been received.

Note: If there are SUS servers located in perimeter networks, the SUS-related contents from the SUS download server must be copied to offline media, transported to the perimeter network, and then copied over to a server from which the local SUS servers are configured to obtain source files.

To Release an Update Through a Phased Rollout

1. Disable synchronization of the update "approvals" list from the SUS parent server. Although the child server will have a copy of the files within the update, it will not be deployed to clients, because the approvals list has not been synchronized.

2. You should then enable synchronization of the approvals list to commence rollout into a different site.

Deploy Phase - Advertising Software Updates to Client Computers

The first step required to deploy a software update into production is to advertise the software update to client computers. Rollouts can either be phased, or all clients can receive the update within the same deployment period. For background information, see the section "Deployment of the Software Update to Targeted Computers" in the module, "Patch Management Phase 4 - Deploy."

Open Rollout

If a phased rollout is not required, you should carry out the following process.

To Implement an Open Rollout

1. Approve the update on the SUS parent server. This will make the update available to clients that use the SUS parent server to obtain updates, as shown in Figure 12.

   

   Figure 12. Approving updates on the SUS parent server

2. SUS clients will begin to download the newly approved update at the next detection cycle, or when prompted by the local administrator, if the Automatic Updates client was configured to notify the local administrator when new updates are available.

SUS clients poll the SUS server every 17 to 22 hours looking for new updates. Assuming a new update has been approved and is available on the local SUS server, it is automatically downloaded and a notification is issued to the logged-on user (if that user has local administrator rights) that a new update is available. When download is complete, installation will occur according to the installation options selected for the Automatic Updates client.

Note: If the option to notify for download and notify for installation has been selected, the update will not be downloaded automatically. A logged-on local administrator must request download for this to occur.

The Automatic Updates installation options include:

• Scheduled installation:

  The update will be installed at the scheduled installation time, unless the local administrator installs it earlier. The computer must be online at the scheduled time in order for installation to occur. The Reschedule Automatic Updates scheduled installations GPO setting, however, allows computers that missed their scheduled install time to perform the installation upon Automatic Updates service restart.

• Notify for installation:

  The local administrator (when logged on) will be notified that an update is ready to be installed. The administrator can install the update immediately or defer installation to a more appropriate time. Users without local administrator rights are not made aware of pending updates.

If the update to be installed requires a restart, local administrators have the option of delaying the restart until a more appropriate time. They should be made aware that no further updates will be downloaded or installed until this restart has occurred.

With the scheduled installation option and the No auto-restart for scheduled Automatic Updates installations GPO setting enabled, users with computer restart privileges, as well as users with local administrator rights, will be prompted to perform a post-install restart. The restart can take place only as long as no other users are interactively logged on to the computer using remote desktop tools, for example, through Terminal Services.

SUS child servers will synchronize approval of the update at the next synchronization interval and will make the update available to their clients in the manner previously described.

Users with local administrator rights are notified of any updates that are awaiting scheduled install time through the taskbar icon shown in Figure 13. They then have the ability to force installation to occur immediately (while logged on) or to wait for the automatic installation to occur at scheduled install time.

Figure 13. Notifying the logged-on user of new updates

For users without these rights, the only notification message will be one that indicates that the update has been installed, and that they need to restart their computers, as shown in Figure 14, assuming that No auto-restart for scheduled Automatic Updates installations policy setting has been enabled.

Figure 14. No auto-restart SUS client

If this is not the case, the Automatic Updates client will inform the user that the system will be shut down within five minutes, and it will automatically restart the system after this period expires.

Phased Rollout

If you want to release the update through a phased rollout, then you should carry out the following process.

To Implement a Phased Rollout

1. Approve the update on the parent SUS server.

2. After the update has been successfully deployed to clients supported by that server, you should enable synchronization of the approvals list on the SUS child server that supports clients in the next phase of the rollout.

For example, if an update that affects all Windows XP clients is to be released to Seattle clients first and, after this deployment is complete, to clients in Cambridge, the SUS administrator will approve an update on the Seattle SUS server first and clients will begin to download and install it. When the deployment in Seattle is complete, then the SUS administrator will enable synchronization of the approvals list on the Cambridge SUS server, which was disabled during the rollout preparation phase. After the approvals list has been successfully synchronized, updates approved on the Seattle server will be made available to clients supported by the Cambridge server.

Emergency Change Request

In some cases, you might need to avoid the time delay between gaining approval of an update in the SUS Server Administration Page and deploying the update on a target server. An update designed to prevent an imminent security breach on a business-critical server will need to be deployed as soon as possible, rather than waiting for the next scheduled installation time.

The following process shows the steps that need to be taken to distribute the software update and force business-critical servers to install it. A similar process could also be followed for the software updates that apply to workstations.

Note: This process can only be successful in business locations where there is sufficient available network bandwidth to allow the software update files and the updated approvals list to be made available to SUS servers.

To rapidly deploy an update using SUS and Group Policy

1. Assign a temporary Group Policy object (GPO) to the appropriate part of the Organizational Unit (OU) structure and use security filtering to ensure that it applies to the appropriate computers. Note that this temporary SUS GPO should be of a higher priority than the SUS GPO that is normally in use. The policy settings within this GPO should be configured to disable the Automatic Updates client and change the default Group Policy refresh interval for computers to five minutes.

2. Force domain controller replication to occur, so that all domain controllers have a copy of the new Group Policy object.

3. Wait up to 120 minutes for all clients within the OU to refresh the Group Policy.

4. Amend the policy settings within the new GPO policy, so that the Automatic Updates client is enabled, and also set to automatic download and automatic installation. Set automatic installation to occur one hour from the current time.

5. Force domain controller replication to occur so that all domain controllers have a copy of the changed Group Policy object.

6. Wait about five minutes for all the SUS clients to refresh the updated SUS GPO settings. After the GPO has taken effect, the Automatic Update clients should begin to download the new update from the SUS server. Installation will begin when the specified time is reached.

7. After the update has been successfully installed on all target computers, delete the temporary GPO used to make all these changes. Servers will fall back to the existing Automatic Updates download and installation options after they refresh their Group Policy settings.

   Note: This procedure should be considered only when an update is regarded as criticalto the operation of the business. In normal circumstances, administrators should wait for the standard SUS installation schedule.

Deploy Phase - Monitoring and Reporting on Deployment Progress

Because computers can fail to install an update for a range of reasons, it is important be able to monitor the progress of the deployment. For background information, see the section "Deployment of the Software Update to Targeted Computers" in the module, "Patch Management Phase 4 - Deploy."

To monitor successful release of the deployed update in an SUS environment, you should run the MBSA tool and monitor whether the particular software update is no longer displayed as missing in the report produced by MBSA output list.

MBSA can also identify installed updates, as well as updates that have been approved on the SUS server but have yet to be installed.

To Scan Multiple Computers

1. On a workstation that has MBSA installed, log on as the domain administrator and run the MBSA GUI.

2. Click Pick multiple computers to scan and enter the domain name or the IP address range to scan. If you are scanning the entire domain, the name you enter must be the NetBIOS name of the domain, not the Fully Qualified Domain Name (FQDN) used within DNS.  

3. Select Use SUS Server and enter **https://**server where server is the required SUS server name, as shown in Figure 15.

   

   Figure 15. Scanning computers in a domain or range of IP addresses

4. Click Start scan and wait for the results.

5. Click Pick a security report to view and then select a computer to view its report.

6. Click Results details to view further details.

As deployment progresses, there may be a number of reasons why certain computers fail to install a software update, including the following:

• Computers are offline for various reasons - for example, users are not at work, users have to dial up, users are mobile, or computers are undergoing maintenance.

• Computers are being rebuilt or re-imaged.

• Computers with the Automatic Updates client are not communicating with the SUS server.

• The Automatic Updates client service has been stopped, either by the user or as part of maintenance.

• Computers have low disk space.

If one of those reasons results in some of your client computers not being patched within the given SLAs, you will need to determine what mitigating steps you should take to bring them into compliance. Although you might not be able to patch all of your computers, you should make sure that you fully understand the reasons why those computers cannot or should not be patched.

The following guidelines should assist you in addressing the failure of the software update to install and help you to bring more of your computers in compliance:

• Always rescan your environment after the first phase of deployment to identify the computers that were missed during the first phase.

• Constantly monitor and report on deployment progress. The rescanning and monitoring will result in subsequent redeployment phases to target computers that reported as exceptions.

• Always triage to find the root cause of failed deployments.

• For computers that are offline or are being rebuilt, the software update will be downloaded and installed when the computers next come online, as long as the Automatic Updates client service is in a healthy state.

• Refer to the guidelines throughout this section in order to increase the success rate of deployment.

To deal with unsuccessful deployment

1. Examine the event log for any SUS-related errors on the Automatic Updates clients. The complete list of possible events for the Automatic Updates client can be found in Appendix B, "Software Updates Services Event Log Messages" of the Software Update Services Deployment white paper, which can be downloaded from https://www.microsoft.com/windowsserversystem/sus.

2. Examine the IIS logs on the SUS server to find failed Automatic Updates clients. Examine the clients' IP address entries and the log entries. Verify the HTTP return codes (such as 404) for each entry to establish if the issue was caused by a download failure.

3. Examine the Windows Update log file. This file logs all activities performed by the Automatic Updates client and is located in the root of the system folder on each client computer. It should be scanned for detailed information of past activities and error messages.

4. Examine the Iuhist.xml file, which logs the entire history of installed updates and where they were downloaded from. The file can be found in Program Files\WindowsUpdate\V4.

If the Automatic Updates client is not downloading the updates, then you need to verify the status of the Automatic Updates client in the registry.

To verify the status of the Automatic Updates client

1. In the Registry, go to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update.

2. Look for the AUState value of the Automatic Updates client. The value for AUState must be set to 2 in order for the client to look for newly approved updates. If AUState is set to 5, the client is pending installation of downloaded updates and will not run a new detection until these updates have been installed. The client will reset itself to AUState 2 after installation has been completed. If AUState is set to 7, the client is disabled. If AUState is set to 8, an install occurred but the computer has not restarted.

Deploy Phase - Handling Failed Deployments

If you decide that a deployment has been unsuccessful and needs to be stopped and rolled back, you need to stop the rollout, uninstall failed updates, and then redeploy them. For background information, see the section "Deployment of the Software Update to Targeted Computers" in the module, "Patch Management Phase 4 - Deploy."

Stopping the Deployment of an Approved Update

If a deployment has failed and you need to prevent further installations, then you must cancel approval of the update on the SUS server. 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.

In Figure 16, the administrator has chosen not to install the Q318138 update.

Figure 16. Choosing not to install an update

Note: If the local administrator chooses not to install a particular update as shown in Figure 16, it will not be installed even if the SUS administrator re-approves that update in the SUS Server Administration Page. In this case, the local administrator of the computer can install it only by using the Declined Updates button within Automatic Updates in Control Panel on that client.

If a computer has installed an approved update, the update can be removed only by using Add or Remove Programs in the Control Panel. Not all updates can be removed, and in such cases, Windows XP computers can roll back using the System Restore utility. The Windows 2000 and Windows Server 2003 systems will have to rely on their backup-recovery technology to revert the computer back to the last known good state. This information should have been researched and established when you were screening and testing a particular update, however, and you should always make a backup before you deploy an update that cannot be uninstalled.

Download the Complete Solution

Patch Management with SUS 1.0 SP1