1 2 3 4 5 Previous Next

PatchZone

61 Posts authored by: Lawrence Garvin

On Thursday (Apr 4) Microsoft announced the forthcoming content for Patch Tuesday – Apr 9, 2013.


You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.


Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on April 10, 2013, at 11:00 AM Pacific Time (US & Canada).

Register now for the April Security Bulletin Webcast. After this date, this webcast is available on-demand.


You can also follow the MSRC team at @MSFTSecResponse.

 

Number of Releases: 9

Critical Security Updates: 2 addressing vulnerabilities in Windows and Internet Explorer.

Important Security Updates: 7 addressing vulnerabilities in Windows, InfoPath 2010, Sharepoint Server 2010/2013, Sharepoint Foundation 2010, Groove Server 2010, Office Web Apps 2010, and Windows Defender for Win8/WinRT.


Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.

Configuring the Windows Update Agent - Overview

Configuring the Windows Update Agent - General Settings Part 1

Configuring the Windows Update Agent - General Settings Part 2

Configuring the Windows Update Agent - WSUS Settings

 

7. WUA Policies related to scheduled installations only

A number of settings are related explicitly, and exclusively, to scheduled installations. For these settings, a scheduled installation is an installation initiated by the WUAgent when AUOption=’4’ at the ScheduledInstallationDay and ScheduledInstallationTime specified in the settings. Any other installation is considered an unscheduled installation and these settings are not relevant.

 

Delay Restart for Scheduled Installations

This setting allows the configuration of how long the WUAgent waits after the completion of the installation event before launching the restart sequence. Generally this option would only have significance when installations are scheduled to occur during the workday and the user may be impacted. The default value is 5 minutes. It can be set from 1 to 30 minutes.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RebootWarningTimeoutEnabled

0-1

0x0–0x1

If enabled, uses the delay specified in the RebootWarningTimeout value

RebootWarningTimeout

1-30

0x1–0x1e

 

Delay Restart for Scheduled Installations - Registry.pngDelay Restart for Scheduled Installations - Policy.png

 

No Auto-Restart with Logged On Users for Scheduled Automatic Updates Installations

When a scheduled installation occurs with a logged on non-administrative user on Windows XP (or Windows Server 2003), that user will be forced to restart the system. This setting allows the non-administrative user to interactively launch the installation, rather than it occurring automatically. It does not grant the non-administrative user the ability to defer or cancel the restart. Admin users always have the option to initiate or defer the restart. Generally this option would only be used for scheduled installation events that occur during the workday. Enabling this option with overnight scheduled installations can interfere with the expected system restart if a user failed to log off of the system at the end of the workday. All users on Vista and newer systems are prompted with a dialog to control when the restart occurs, unless the setting to block this functionality has been enabled. On Vista and newer systems, the user is given three choices when deferring the restart: 10 minutes, 1 hour, or 4 hours. This setting has no functional significance on Vista and newer systems.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

NoAutoRebootWithLoggedOnUsers

0-1

0x0–0x1

If enabled, allows a non-admin user to initiate the restart, rather than having it forced by the WUAgent

No Auto-Restart with Logged On User - Registry.pngNo Auto-Restart with Logged On User - Policy.png

Re-prompt for Restart with Scheduled Installations

When a user on Windows XP/2003 is presented the option to “Reboot Later,” the duration of the delay before the user is prompted again is determined by this setting. The default delay is 10 minutes. The delay can be configured from 1 to 1440 minutes (24 hours). On Vista and newer systems, the delay is selected by the user from one of three choices: 10 minutes, 1 hour, or 4 hours.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RebootRelaunchTimeoutEnabled

0-1

0x0 – 0x1

If enabled, allows the configuration of the time delay before the restart dialog is presented to the user

RebootRelaunchTimeout

1-1440

0x1 – 0x5a0

 

Re-prompt for Restart With Scheduled Installation - Registry.pngRe-prompt for Restart With Scheduled Installation - Policy.png

 

Reschedule Automatic Updates scheduled installations

This setting determines whether updates are installed at system startup when the scheduled installation event is missed and how long the delay after startup is before installation begins. The default behavior is to install updates 1 minute after startup (as a matter of practicality, this is 1 minute after the Windows Updates service startup). The installation at startup can be disabled, or it can be configured to occur from 1 to 60 minutes after startup.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RescheduleWaitTimeEnabled

0-1

0x0 – 0x1

If enabled, allows the configuration of the time delay after restart; If disabled, installation at startup will not occur

RescheduleWaitTime

1-60

0x1 – 0x3c

 

Reschedule Automatic Updates Scheduled Installations - Registry.pngReschedule Automatic Updates Scheduled Installations - Policy.png

 

Enable Windows Update Power Management to automatically wake up the system to install scheduled updates

For systems that are in sleep or hibernation mode, this setting allows the system to wake up at the scheduled installation event to install updates. If deadlines are configured, and expire, the system will wake up when the deadline expires. If the system is running on battery power, it will be returned to hibernation.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

AUPowerManagement

0-1

0x0 – 0x1

If enabled, allows the system to wake up to install updates.

Enable Windows Update Power Management - Registry.pngEnable Windows Update Power Management - Policy.png

Configuring the Windows Update Agent - Overview

Configuring the Windows Update Agent - General Settings Part 1

Configuring the Windows Update Agent - General Settings Part 2

 

6. Policies exclusive to WSUS environments

In this section, we’ll look at the three configuration settings that are exclusive to the WSUS environment.

 

Specify Intranet Microsoft update service location

This setting defines a client as a WSUS client. If this option is Disabled or has never been configured, the client system will use AU/WU/MU for detection. When this option is Enabled, the URL specifies the WSUS server to be used. Only the WUServer value needs to be specified in the setting; the v7.x Windows Update Agents ignore the WUStatusServer value. The WUServer value must be a URL of the form http://nameOfWSUSServer.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

UseWUServer

0-1

0x0 – 0x1

If enabled, defines the system as a WSUS client and uses the WUServer value as the assigned WSUS server

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Registry Value

Valid String Value

Notes

WUServer

http://nameofWSUSServer

Identifies the URL of the assigned WSUS server. Must be defined as an http:// or https:// URL

Specify Intranet Microsoft Update Service Location - Policy.pngSpecify Intranet Microsoft Update Service Location - Registry.png

 

Enable client-side targeting

WSUS uses groups to provide approvals to client systems for the installation of updates. Groups must be created in the WSUS console, but membership in those groups can be assigned from the console or by using policy settings. In addition to this policy setting, the Options|Computers dialog in the WSUS console must be set to the correct value. The default configuration is “server-side targeting” and group memberships are managed from the WSUS console. When using server-side targeting, this policy setting should be set to Disabled to ensure clients do not attempt to exert authority over their group memberships. If this policy setting is Enabled, the group(s) that a client is assigned to are defined in the policy setting using a semi-colon delimited list. The client becomes authoritative for these group memberships as configured in the policy setting. Do not specify “All Computers” or “Unassigned Computers” in this setting. The Options|Computers setting must also be set to “Use Group Policy…” so that the WSUS server knows the client is authoritative. This setting also disables the ability to change group memberships from the console.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

TargetGroupEnabled

0-1

0x0 – 0x1

If enabled, identifies the assigned WSUS group(s) that the client belongs to. If disabled, the WSUS console is used to assign group memberships

TargetGroup

Semicolon delimited string

 

Enable Client-Side Targeting - Policy.pngEnable Client-Side Targeting - Registry.png

 

Allow signed updates from an intranet Microsoft update service location

When a WSUS server is used to distribute locally published updates to client systems, this setting must be Enabled to permit the WUAgent to validate the packages using an alternate code-signing certificate (one not issued by the Microsoft WU infrastructure).

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

AcceptTrustedPublisherCerts

0-1

0x0 – 0x1

If enabled, allows the WUAgent to install locally published updates validated by an alternate code-signing certificate

Allow Signed Updates - Policy.pngAllow Signed Updates - Registry.png

 

Configuring the Windows Update Agent - Scheduled Installations

Configuring the Windows Update Agent - Overview

Configuring the Windows Update Agent - General Settings Part 1

 

In this third part of our five-part series, we're continuing our look at the general settings of the Windows Update Agent.

 

Allow Automatic Updates & immediate installation

An option that is quite often overlooked, but probably not really relevant until the introduction of Windows Defender in 2006, is the ability to allow immediate installation of updates that cannot trigger system or service restarts. Unfortunately, there’s no way to visually identify one of these updates in the WSUS console. Generally speaking, this group includes Definition Updates. An update listed with a Reboot Behavior of “Never restarts” may install with this option, but even updates that should have that option set typically do not. What’s important to note is that the Windows Update Agent knows how to identify these updates, and they will be handled automatically if you allow that.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

AutoInstallMinorUpdates

0-1

0x0 – 0x1

If enabled, allows the WUAgent to immediately install any update with the Impact attribute set to “Minor”

Allow Automatic Updates Immediate Installation - Registry.pngAllow Automatic Updates Immediate Installation - Policy.png

Allow non-administrators to receive update notifications

This is mostly a legacy option, beneficial primarily to non-administrative users on Windows XP systems, where interacting with the Windows Update Agent UI requires administrative permissions. This option restricts that requirement and allows the WUA to present the UI to a non-administrative user.

 

Here are a couple of additional pedantic notes:

  • It also applies to Windows Server 2003 systems, but inasmuch as the only non-admin users on a Windows Server 2003 system would be Terminal Services clients, it has no practical application.
  • Windows Vista and newer systems grant full access for the Control Panel WUApp to all users. This option has no practical application on Vista or newer systems.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

ElevateNonAdmins

0-1

0x0 – 0x1

If enabled, allows the WUAgent to interact with non-administrative users on a Windows XP system

Allow Non-Administrators to Receive Update Notifications - Policy.pngAllow Non-Administrators to Receive Update Notifications - Registry.png

Remove links & access to Windows Update

In Windows XP/2003 and earlier systems, there was a Start Menu option, a Taskbar icon, and on Internet Explorer 6 and earlier versions, a menu option to launch Windows Update. This setting removes those menu options (although it did not preclude a creative user from typing the URL into the browser address bar). They have no relevance on Vista or newer systems. This option is a user option, not a computer option, and will be found in the UserTemplates\Start Menu and Taskbar node of the policy editor.

 

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

NoWindowsUpdate

0-1

0x0 – 0x1

If enabled, blocks access to the Start Menu and Internet Explorer menu options, and the Taskbar icon

 

Remove access to use all Windows Update features

This setting is generally applicable to pre-Vista systems to block access to the Windows Update Agent functionality, including the notification boxes and the ability to install updates interactively. There is also an option to configure the type of notifications that are suppressed. The user can have all notifications blocked, or be provided with restart-required notifications. This update is a user setting, and care should be taken when configuring it so as to not block access to all users. Typically a separate GPO filtering out Domain Admins is recommended for using this setting. The setting is found in the UserTemplates\Windows Components\Windows Update node of the policy editor.

 

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

DisableWindowsUpdateAccess

0-1

0x0 – 0x1

If enabled, blocks access to all Windows Update Agent UI functionality

DisableWindowsUpdateAccessMode

0-1

0x0 – 0x1

If enabled, allows the display of restart required notifications

Remove Access to Use All Windows Update Features - Policy.pngRemove Access to Use All Windows Update Features - Registry.png

 

Turn off access to all Windows Update features

This is the current incarnation of the option to block access to client-side update management functionality. The setting configures WSUS as the only update source and fully blocks access to AU, WU, and MU. It is a computer setting, and will override any user-based settings (e.g. if you enabled restart required notifications in the previous user setting, this one will shut them off). This setting is found in the ComputerTemplates\System\Internet Communication Management\Internet Communication Settings node of the policy editor.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

DisableWindowsUpdateAccess

0-1

0x0 – 0x1

If enabled, blocks access to all Windows Update Agent UI functionality

Turn Off Access to All Windows Update Features - Policy.pngTurn Off Access to All Windows Update Features - Registry.png

 

Configuring the Windows Update Agent - WSUS Settings

Configuring the Windows Update Agent - Overview

5. WUA General Settings

The first group of settings to be familiar with are the general settings. These settings apply to all systems regardless of how they obtain updates. While generally not used for non-WSUS clients, it’s important to know that Automatic Updates (AU) clients can be configured, and these settings actually predate the creation of SUS/WSUS.

 

Configure Automatic Updates

On non-WSUS systems, this value is typically configured at installation, or by a user via the Control Panel. The setting provides five valid options which determine how updates are downloaded and installed. The options are:

  • Option 1: Not used
  • Option 2: Notify before download / Notify before installation
  • Option 3: Download automatically / Notify before installation
  • Option 4: Download automatically / Schedule installation
  • Option 5: Allow local administrator to choose the configuration

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

AUOptions

2-5

0x2 – 0x5

Set according to the option configured

ScheduledInstallDay

0-7

0x0 – 0x7

Ignored if AUOption!=’4’; defines the day(s) in which updates can be installed

ScheduledInstallTime

0-23

0x0 – 0x17

Ignored if AUOption!=’4’; defines the hour of the day in which updates will be installed

NoAutoUpdate

0-1

0x0 – 0x1

If the policy is Disabled, this value is False, and the system will not perform any automatic updates functions

Configure Automatic Updates - Registry.pngConfigure Automatic Updates - Policy.png

Automatic Updates Detection Frequency

This value specifies how often the system checks for updates. The default value is 22 hours, but this value includes a random negative offset of 0-20%. So in actuality, the system checks every 17.6-22 hours, and the interval varies with each detection event. The most significant factor in setting this value is to make it consistent with your WSUS server synchronization schedule. If your WSUS server only synchronizes once per day, there’s minimal value in changing this value from the default; however, if your WSUS server is synchronizing multiple times per day, having the client check in more often can be quite useful. Do not set this value to 1 hour. While it is a valid value that may be useful for limited diagnostic purposes, a regular 1-hour detection interval will interfere with the expiration of the targeting cookie (which has a 60-minute time-to-live).

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

DetectionFrequency Enabled

0-1

0x0 – 0x1

If enabled, allows the customization of the detection frequency

DetectionFrequency

1-22

0x1 – 0x16

Ignored if DetectionFrequencyEnabled!=’1’

Automatic Updates Detection Frequency - Registry.pngAutomatic Updates Detection Frequency - Policy.png

Do Not Display “Install Updates and Shutdown” Option

The default behavior is to always present this feature when applicable. The setting allows the option to be removed from the shutdown menu. On Windows 7 and Windows Server 2008 R2 systems with Service Pack 1, the user no longer has a menu choice – installation of updates is forced upon the user when executing a shutdown from the Start Menu. (The installation can be bypassed by launching a shutdown from the command line using shutdown /s /t 0.) The setting can be configured either as a computer option (affecting all users) or a user option (only affecting domain users). Implementing it as a user option can be effectively used to override the behavior for regular domain users, but still allow launching of the capability via a local account.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

HKCU\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

NoAUShutdownOption

0-1

0x0 – 0x1

If enabled, blocks access to select the “Install Updates and Shutdown” option from the Start Menu.

Do Not Display Install Updates and Shutdown Option - Registry.pngDo Not Display Install Updates and Shutdown Option - Policy.png

Do Not Adjust Default Option to “Install Updates and Shutdown”

This setting preserves the existence of the option to install updates at shutdown but does not display it as the default option. The setting is really only relevant on Windows XP/2003 systems where the dialog box presents a dropdown menu of choices. As noted previously for Windows 7/2008R2 SP1 systems, this is the only option presented via the Start Menu. On Vista/2008 SP2 systems, the options are presented as a fly-out menu. Like the setting to suppress the option, this setting can be configured either as a computer option or a user option.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

HKCU\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

NoAUAsDefaultShutdownOption

0-1

0x0 – 0x1

If enabled, does not force the display of the option as the default in the Windows XP/2003 shutdown dialog.

Do Not Adjust Install Updates and Shutdown Option - Registry.pngDo Not Adjust Install Updates and Shutdown Option - Policy.png

 

Configuring the Windows Update Agent - General Settings Part 2

Configuring the Windows Update Agent - WSUS Settings

On Thursday (Mar 7) Microsoft announced the forthcoming content for Patch Tuesday – Mar 12, 2013.


You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.


Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on March 13, 2013, at 11:00 AM Pacific Time (US & Canada). Register now for the March Security Bulletin Webcast. After this date, this webcast is available on-demand.


You can also follow the MSRC team at @MSFTSecResponse.

 

Number of Releases: 7

Critical Security Updates: 4 addressing vulnerabilities in Windows, Internet Explorer, Silverlight v5, Office 2010, Visio 2010, and Sharepoint Server 2010.

Important Security Updates: 3 addressing vulnerabilities in Windows, OneNote 2010, and Office for Mac (2008 and 2011).


Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.

Over the next few five weeks (I'm still sorting out exactly how many posts this will actually take), I'm going to take us on a tour of the configuration options for the Windows Update Agent. Some of these capabilities are documented in the WSUS Deployment Guide (with some errata that complicates it a bit), but some are not discussed at all. In addition, there are certain considerations that you just don't get from the cut-and-dried technical specifications found in that document. This content was originally presented as a webcast in the Summer, 2010, and has been derived from that original outline. The sections are numbered in this series of posts as they're also being aggregated for publication as a comprehensive white paper.


1. What is the Windows Update Agent (WUA)

The Windows Update Agent is the native software in a Windows operating system that communicates with Automatic Updates, Windows Update, Microsoft Update, or a WSUS server to determine what updates are available for installation, initiates the download of those updates, initiates the installation of those updates, and, in the case of WSUS, reports the status of those events back to the WSUS server.

The WUA has functionally existed since Windows 98, although prior to the introduction of WSUS in 2005, it was actually known as the “Automatic Updates Client”. Regardless of its name, the behavior of the WUA has always been configurable via the registry, and starting with the introduction of Active Directory and Group Policy in Windows 2000, via Group Policy or Local Policy.

It wasn’t really until the introduction of WSUS, however, that configuring the WUA really became of interest; otherwise, clients of Automatic Updates just did their thing at 3am on the day (or two) after patches were released by Microsoft, or whenever a logged-in user browsed to Windows Update via Internet Explorer.


2. Methodologies: Policy vs. Registry

As noted, originally the AU Client could only be configured via registry settings, but since they didn’t actually exist in the registry unless manually created, and nobody had documented them, nobody actually knew they existed. Our first real awareness of the ability to configure the AU Client came with the release of WSUS in 2005, and the availability of a Group Policy template that contained those settings.

Today you can configure the WUA using either Group Policy, Local Policy, or directly editing the registry. In an Active Directory environment, Group Policy is the best choice; but for non-Active Directory environments it’s a bit more complicated. The preferred methodology is to use Local Policy to configure a reference machine, and then export the WUA registry key to be imported into other systems.

You can also obtain pre-made registry files online, or build your own, but the biggest risk with importing directly to the registry, or editing the registry directly, is the risk of making errors in the process. If the registry values are incorrectly named, the wrong data type, or have invalid values, the WUA will ignore the registry value and revert to its built-in default settings.

One of the most common errors resulting in invalid registry values is entering decimal values instead of hexadecimal values. In the registry charts in the coming posts I will highlight the cells where common mistakes are made, typically from confusing decimal and hex values when entering them into the registry.


3. General Considerations

There are three general points I’d like to call attention to before we look at individual settings in the coming posts:
  • The Policy settings and registry values that we will discuss in this article are documented in the WSUS Deployment Guide. Except where expressly noted, all policy settings are found in the Computer Configuration\Administrative Templates\Windows Components\Windows Update node of the policy editor. In the interests of brevity, all future policy setting references will be identified as one of the following:
    • ComputerTemplates- \Computer Configuration\Administrative Templates
    • UserTemplates- \User Configuration\Administrative Templates
  • All WUA computer policy settings are manifested in one of these two registry keys:
    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
  • All WUA user policy settings are manifested in one of these two registry keys:
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate


4. WUA default behavior

  • Checks for updates from Automatic Updates every 17.6-22.0 hours.
  • Downloads updates automatically upon detection of availability and schedules the installation to occur at 3am the next day.
  • Restarts the system five minutes after the completion of the installation.
  • If the system is powered off at 3am, the downloaded updates are automatically installed the next time the system is powered on.
  • On Windows XP and Windows Server 2003 systems, if the logged-on user has administrative privileges, that user can
    • Select which updates to install.
    • Initiate the installation of updates before the scheduled installation time.
    • Choose whether to reboot the system after the installation is completed, or reboot the system later. If later is chosen, the user is re-prompted every 10 minutes until the user chooses to reboot the system, or the user logs off. If the user logs off, the reboot occurs within 10 minutes.
  • On Windows Vista and all newer systems, all users have privileges to select which updates to install, when they are installed, and whether the system is restarted after installation.
Starting next week... we'll look at how to change the behaviors of the Windows Update Agent.

WSUS Timeout Errors - When? and Why? - Eliminating and avoiding

 

This is the 5th and final part of this series on handling WSUS timeout issues, and now that we’ve removed unnecessary update approvals, addressed the issue of too many synchronized updates, and defragmented the filesystem hosting the WSUS database, we’re now ready to perform WSUS database maintenance.

 

In this article we’re going to talk about what the database maintenance activity does, how to get the database maintenance script, and how to successfully execute the script.

 

What Does WSUS Database Maintenance do?

The reference for the WSUS Database Maintenance activity is in the WSUS Operations Guide in the section titled Reindex the WSUS Database, and at its core, this is what the database maintenance script does. You could, of course, simply launch SQL Server Management Studio and reindex everything – but that would keep the database (and WSUS server) offline for a lot longer than is really necessary, potentially rebuilding indexes that don’t need to be rebuilt. The script evaluates the level of fragmentation and reindexes only those objects where the page density is low or the external fragmentation is high in relation to the index size. Specifically, the criteria are:

  • Page Count > 50 and Average Fragmentation > 15%, or
  • Page Count > 10 and Average Fragmentation > 80%, or
  • Average Page Space Used < 85% and the Average Page Space Used is low enough that pages can be freed up by rebuilding the index

 

How to Get the WSUS Database Maintenance script

The script can be obtained from the Microsoft Technet Script Center. The script is not an actual downloadable object, so you will need to copy and paste the script from the webpage into your local system.

 

CAUTION: There is a compatibility issue between the “Copy Code” link in the script center, and certain versions of something that results in upper-bit characters being inserted into the text stream rather than the simple spaces that are actually defined. The manifestation of this issue is discussed in this thread in the TechNet WSUS forum, and I was able to reproduce it today, using the “Copy Code” link with IE9 on Win7x64 and pasting into either Notepad or SQL Server Management Studio directly. When I copied the text directly from the display on the page, I did not encounter the syntax errors. I suggest you copy the text directly, rather than use the “Copy Code” link.

 

How to Use the WSUS Database Maintenance script

There are two ways you can invoke this script:

Either way, since you’ll need to download and install something if you’re using the WID, I suggest you go all the way and install the SQL Server Management Studio Express Edition. (You may find additional uses for this tool at another time.)

 

If you choose to use SQLCMD.EXE, and assuming you’ve saved the script as WSUSDBMaintenance.sql, the command to run the script from the command line is:

sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query –I -i <scriptLocation>\WsusDBMaintenance.sql

 

If you’re running this on Windows Server 2012 use:

sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query –I -i <scriptLocation>\WsusDBMaintenance.sql

 

To run the command from SQL Server Management Studio, open the WSUSDBMaintenance.sql file, or paste the code directly into a New Query window connected to the SUSDB and click on “Execute” or press <F5>.

 

Be prepared! This script will take some time to execute. On my WSUS server (P4 2.8GHz hyperthreaded, 1.5GB RAM with separate spindles for OS and WSUS), the script took almost 8 minutes to scan the WID and identify 77 indexes that qualified for maintenance. To run the entire script took almost 19 minutes.

Today (Feb 7) Microsoft announced the forthcoming content for Patch Tuesday – Feb 11, 2013.

 

You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.

 

Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on February 13, 2013, at 11:00 AM Pacific Time (US & Canada). Register now for the February Security Bulletin Webcast. After this date, this webcast is available on-demand.

 

You can also follow the MSRC team at @MSFTSecResponse.

Number of Releases: 12

Number of CVEs addressed: 57

 

Critical Security Updates: 6 addressing vulnerabilities in Windows, Internet Explorer, and Exchange Server 2007 and 2010

Important Security Updates: 7 addressing vulnerabilities in Windows, .Office, Search Server 2010 for Sharepoint, and the .NET Framework

 

Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.

At first glance, one might look at the first ten Java 7 updates in eighteen months (through JRE7u11, u8 was not released) and feel like the sky is falling. But, let’s split those apart into functionality updates (planned) and security updates (unplanned), and maybe it's not quite as intense.

Functionality updates

First, the functionality updates, and what we see here are evenly spaced feature enhancements. These are the even numbered releases which signify a planned release.

Java 7 Functionality Updates.png

Security updates

Then the odd-numbered (and unplanned) security updates. Wow! Don’t those look just as regular as the feature releases!

Java 7 Security Updates.png

Let’s take a look at these six security update packages in a bit more detail.

 

The first shocker is that right out of the gate, in the first three months of existence, twenty security vulnerabilities were identified. What you might not know is that nineteen of those vulnerabilities also existed in Java 6, and had existed in Java 6 for the previous five years. Only one of these was unique to Java 7. Maybe even scarier: Nine of them still exist in Java 5! In fact, this is pretty much the story for almost all of these Java 7 vulnerabilities.


Here’s a chart showing the number of Java 7 vulnerabilities reported/fixed up to JRE7u11 that also existed in Java 6 and Java 5.

Java 7 vulnerabilities in older Java versions.png
Last Friday, Oracle released another security update for Java, (JRE7u13 and JRE6u39), and we can presume that JRE6u39 will be the last update for Java 6. If the above numbers shocked you, this security update might add a bit more of a shock. The update itself repaired 50 vulnerabilities, but eleven of them were only in the JavaFX module. The other 39 were in the Java Runtime Environment -- Yep! They fixed 39 more vulnerabilities! But only six of those vulnerabilities were exclusive to Java 7! Of the 39, 12 of them only existed in Java 6, and 21 of them existed in Java 6 and still exist in Java 5. One of the vulnerabilities didn't exist in Java 7, but only in Java 6 and earlier, so only 38 of them existed in Java 7.


So, if update the above table and add one more row and recalculate the totals, here's what we have today:

Java 7 u13 vulnerabilities in Java 6.png

Let’s put this in a very simple perspective:  over 80% of the reported/fixed vulnerabilities in Java 7 also existed in Java 6 (and have for the past six years) and almost half (49.6% to be exact) still exist in Java 5!

 

Which Java to keep?

What that means for patch administrators is that there’s no significant advantage to deferring the deployment of Java 7 and retaining Java 6, except in a case where an application has a known and verified dependency on Java 6. If that situation applies to you, be aware that after February, 2013, Oracle will not be publishing any additional security updates for Java 6, and you might want to have a heart-to-heart with that software vendor who still has Java 6 dependencies.

 

For some additional guidance on managing Java installations, see my Patchzone article.


Who’s responsible?

Excluding the 61 vulnerabilities that exist in Java 5, which Oracle definitely inherited from Sun, we might wonder about the other 38 vulnerabilities in Java 6. In fact, we can infer their “state of inheritance” by the version of Java 6 in which they were fixed: Every one of those Java 6 vulnerabilities existed in JRE6u26 and earlier. That is to say, all 80% of the Java 7 vulnerabilities that also existed in Java 6 were inherited from Sun!

 

Which, I guess, leaves us with this reality: Oracle inherited a problem in Java code security from Sun in 2009, and over the past eighteen months we’ve learned that a lot of them were not discovered, much less fixed, in Java 7. So we can’t really blame Oracle for creating them -- well a third of them are unique to Java 7 -- but there’s no doubt that Oracle is complicit in their perpetuation of a lot of bad code written in Java 6 and earlier.(Some of these vulnerabilities actually date back to Java 1.4 and earlier!)

So, I think I’ll temper my anger towards Oracle, at least as to their perceived ineptness in creating new code; however, as for the rest, I guess it really depends on where you are on the spectrum with regard to accountability for inherited conditions. Up until recently, I think, the prevailing wisdom in American popular thought regarding “inherited problems” would have placed all of this in the lap of Sun Microsystems.

On the other hand, regardless of where you point the finger, it’s definitely Oracle’s problem now.

WSUS Timeout Errors - When? and Why? - Eliminating and avoidingjavascript:;

 

We’re up to Part 4 now, and we’re going to look at defragmenting the database for WSUS. To recap in Part 2 we talked about removing unnecessary update approvals, and in Part 3 we talked about having too many synchronized updates in general. Update management is a necessary part of this process before optimizing the filesystem or database. In most of the situations I’ve seen and discussed with other WSUS administrators, it was the volume of data that was the primary culprit–-not the inefficiencies in the organization of that data within the database.

 

Defragmenting a disk drive can have a significant impact on disk performance; defragmenting a database file can have similar impacts on database performance. In the early days of Windows, defragmentation was something almost every Windows user, and certainly every system administrator, came to know and hate. The need hasn’t gone away, but Microsoft’s built-in defragmentation software did get better (actually, they licensed the software from one of those remaining vendors). Starting with Windows Vista, the defrag task is automatically created in the Task Scheduler to run at 1:00 a.m. every Wednesday morning. However, this task is disabled by default in Windows Server.  This is no great loss, though; a scheduled defrag task is totally useless for a database-based application anyway, because the database engine has a permanent file lock on the database files.

 

For a WSUS server using the Windows Internal Database, we need to take a slightly more direct approach. After completing all of the requisite update maintenance previously described in Parts 2 and 3 of this series:

  1. Stop the WSUS service. This is the “Update Services” service if you’re using the services MMC., or you can stop it from the command line using net stop wuauserv.
  2. Stop the database service.  Since we’re assuming a local database, that would be the Windows Internal Database service if you’re using the console, or net stop MSSQL$MICROSOFT##SSEE. (Note: If you’re using WSUS v6 on Windows Server 2012, the name of the WID service has changed to MSSQL$MICROSOFT##WID.)
  3. Defragment the drive containing the WSUS database. Navigate to Start -> All Programs -> Accessories -> System Tools and launch Disk Defragmenter. You can also launch from the command line using DEFRAG.EXE.
  4. Restart the database service.
  5. Restart the WSUS service.

 

It’s also worthy of note that the pretty graphical feedback that exists in Windows Server 2003, does not exist in Windows Server 2008 or Windows Server 2008 R2. In Windows Server 2008 R2, there is a progress indicator, but in Windows Server 2008 there is no active feedback at all. Of course, if you have an alternate disk defragmentation utility to use, that will work as well.

 

You can also script and schedule this task to run automated and unattended, and defragmenting a hundred gigabyte disk drive may take a long time–-even longer if it’s never been done. (This is another good reason to script and schedule it, so you’re disinclined to watch the progress state and get bored-–or depressed.)

 

By the way, if the database and content store are on different drives, it’s also worthwhile to defragment the volume with the content store too.

 

WSUS Timeout Errors - WSUS Database Maintenancejavascript:;

WSUS Timeout Errors - When? and Why? - Eliminating and avoiding

WSUS Timeout Errors - Removing unneeded update approvals


In Part 3 of this series, we’re going to discuss the complications of having too many updates in your WSUS environment, and their contribution to causing timeout issues.


There are two situations in which we can find ourselves with too many updates. The first is a planning complication; the second a maintenance complication.


Planning Decisions

When a WSUS server is in the planning stages, one of the determinations that must be made is proper identification of the Product Categories and the Update Classifications that need to be selected for synchronization. Generally speaking, there are two rules you should follow when making these selections:

 

Select all Update Classifications except "Drivers"

Do NOT select the "Drivers" classification! (Yes, I repeated myself; it’s that important!) The “Drivers” classification contains over 30,000 device driver update packages, and for most organizations, none of those packages will apply to any installed hardware. If you have a server with the “Drivers” classification selected, you might consider rebuilding that server without it.

 

Select only the Product Categories for products that you actually have installed and need to deploy updates for

Do not select Product Categories you might have someday; do not select Product Categories that can no longer be patched. To determine if a product can no longer be patched, go to the Microsoft Support Lifecycle page, and look up a product. If the Extended Support date has passed, then there are no new updates for that product. Point the product to Microsoft Update, make sure all of the available patches are installed, and leave the Product Category unselected. You’re done patching that product … forever.


Maintenance Activities


Unselect the Product Categories for products that no longer exist in your organization, or have reached the end of the Extended Support period

Presumably, based on the guidance in the previous article, these updates have already been declined. The second part of that step is to update the synchronization rules. This won’t physically remove the updates from the database, but the change will hide them from the console and, more importantly, from many of the queries that look at all updates, including the declined updates. This will reduce the number of updates that need to be processed by client detections, downstream server synchronizations, and the Server Cleanup Wizard.


Regularly run the Server Cleanup Wizard

The Server Cleanup Wizard provides a number of services that can help reduce the total number of updates in the WSUS collection:

    • It deletes old revisions of updates.
    • It declines superseded updates that do not have active approvals.


Better Performance

The two most significant factors in the content of the WSUS database that affect performance are the total number of synchronized updates and the number of those updates that have approvals.


How many updates should you have?

It’s difficult to put a finite quantity on this value, because it does depend on the required selections for Product Category, Update Classification, and Update Languages. However, as a comparison point, on my English-only WSUS servers, synchronizing all Windows operating systems, most of the “BackOffice” server applications, two versions of Office, and Definition Updates for Defender and MSE, I have fewer than 6,000 updates on my server today.


How many approved updates should you have?

On any given day over the past several years, I have rarely seen the number of approved updates on any one of my WSUS servers exceed 10% of the total number of updates synchronized. Your mileage may vary, but if its more than 15%, you probably want to go back and look at

Part 2 again.

 

Deleting Updates

Just to entice you, you can physically delete other updates from the WSUS database. It can be done via API calls with code you write, or by native features of SolarWInds Patch Manager.

 

WSUS Timeout Errors - Defragment the filesystem

WSUS Timeout Errors - WSUS Database Maintenance

In Part 1, I introduced the three manifestations of timeout errors in a WSUS environment, and identified the four practices that will help eliminate them. In this article we’re going to talk specifically about the practice of removing unnecessary update approvals. This is a practice that all WSUS administrators should adopt, whether timeout errors are an issue, or not -- it’s just good practice.

 

Why do approvals matter?

Update approvals collect up over time, to the point where eventually they achieve critical mass and start interfering with efficient database operations within the WSUS database. WSUS was never intended to be a run-it-and-forget-it type of application, and it does require regular administration and maintenance.

 

How do approvals impact performance?

In WSUS, there are four entities of interest that are impacted by approvals: Updates, Groups, Computers, and Approvals. As the counts of each of those entities increase, the combinations increase exponentially. This causes longer processing times within the database when returning queries to the console or providing synchronization event data to a downstream server. Eventually the result doesn’t come back fast enough, and the console or downstream server gets tired of waiting.

 

One of the ways we can control this performance behavior  – and in an amazingly significant manner – is by managing the number of approvals that exist on the WSUS server. Generally speaking, a well-maintained WSUS server will rarely have more than a few hundred approved updates. So, as a starting point, if a WSUS server has more than 500 approved updates, it’s a candidate for a review of the approvals.

 

Updates that should have approvals removed

There are three classes of updates that we can target for update approval removals:

  • Products that no longer exist in the environment. If you’ve upgraded all of your Windows XP systems to Internet Explorer 8, and retired all of your Windows 2000 systems, then you really have no use for any updates for IE5, IE6, or IE7, or for Windows 2000. Decline them.
  • Any update that has been superseded by a Service Pack that has been fully deployed to your organization.  Updates superseded by a service pack that is installed everywhere have no useful value. Decline them.
  • Any other superseded update that is reported as 100% Installed/Not Applicable on the WSUS console. If superseded updates are 100% Installed/NA, then they will never be used (read: deployed) to any system ever again. Decline them.

 

This third group is usually the most difficult to identify. One way to do this is to:

  1. Filter the All Updates view with Approval=”Approved” and Status=”Installed/NotApplicable”.
  2. Enable the Supersedence column display
  3. Sort by the “Installed/Not Applicable Percentage” column. Alternatively, you can also sort by the Supersedence column. You may prefer one method over the other, and either will serve the purpose.
  4. Select the updates reported as 100% Installed/NotApplicable that are identified as superseded.

 

PatchZone - SupersededNAUpdates.png

Note: If you are using SolarWinds Patch Manager, you can build a permanent update view with these settings, and then do a Select All on the list of updates. I describe how to do this in a Geekspeak Blog Post.

 

Having identified the updates to be declined:

  • If you do not have downstream replica servers, you can Decline these updates directly.
  • If you have one or more downstream replica servers, do NOT perform a mass decline of hundreds of updates on your upstream server. This is also a known cause of downstream replica server synchronization timeout errors. Rather, in this case, you’ll need to spread this activity out over several sessions so as to not overload the number of approval events that need to be synchronized to the replica servers.

 

This procedure should then be performed on a regular basis. Monthly would be optimal, but you may find that removing approvals on a quarterly basis is sufficient to maintain performance of your WSUS server.

 

WSUS Timeout Errors - Too many updates

WSUS Timeout Errors - Defragment the filesystem

WSUS Timeout Errors - WSUS Database Maintenance

UPDATE: 3/1/2013

The fun never ends. Yet another zero-day vulnerability in the current patch-revisions of the Java Runtime Environment. Security research firm Fireeye reports that there are active exploits in the wild against both JRE7u15 and JRE6u41. The most significant point of this is that JRE6u41 isn't likely going to get fixed, as JRE6 expired support yesterday. Presumably JRE7u17 will be available shortly, but at a minimum you need to disable Java in IE or use a browser that prompts before launching a Java applet in the browser.

 

Note also, since the release of JRE7u10, you can now disable Java in Internet Explorer using the Java Control Panel for JRE7, but the UI is a bit flaky. You'll need to select the "Microsoft Internet Explorer" option, and then press spacebar to disable the functionality. And even then, this may not be enough, there is some discussion and controversy around whether this actually works or not. Seriously, if you're not actively using a Java-based application on your computer right now - today! - I would suggest removing Java completely. I have!

 

Disable plugin for JRE7 in IE.png

 

UPDATE: 1/31/2013

Previously I wrote in this article, incorrectly, that the vulnerability fixed in JRE7u11 was also present in JRE6. This is not correct. However, subsequent research has also uncovered the fact that 78% of the Java 7 security vulnerabilities that have been fixed since its release in July, 2011, are also present in Java 6. As such, for those that might have been inclined to stick with Java 6 to avoid the security issues with Java 7, that's not going to be of any real help. Also, security updates for Java 6 will no longer be published after February, 2013, so if you need Java, migrating to the latest release of Java 7 and removing Java 6 is definitely the best approach.



It’s been yet another busy 72 hours in the land of Java, although, by now, a lot of people have become quite accustomed to this rat race. The latest issue was reported Friday, by a number of sources, that an active exploit of an issue in the Java Runtime Environment (JRE) v7 update 10 was identified. Unlike past times, though, Oracle responded quite rapidly, and on Sunday released an update: JRE7v11 – which, unfortunately, doesn’t fix all of the identified vulnerabilities, but does fix the one being exploited. That update was published to the SolarWinds Patch Manager catalog yesterday.

 

However, be aware that the same vulnerability also exists in the Java Runtime Environment v6, and Oracle has not released a patch for that vulnerability, so don’t be surprised if an active exploit for JRE6 shows up in the next day or so.

 

In the meantime though, here’s an Action Plan for dealing with Java.

 

Best Solution: Uninstall Java

If you have machines that do not need the Java Runtime Environment, then uninstall it. Completely! If you have Java 7 and Java 6 installed (or any other older versions of Java) uninstall the older versions! Consider it one of those applications that only “special people” get to install. SolarWinds Patch Manager has tools that can you leverage to do mass uninstallations of Java across your entire organization.

 

Good Solution: Disable Java

Java is a pretty popular development environment and has been around a very long time. As a result, the reality is that almost every organization has at least one business critical application that requires the Java Runtime. Consider, though, disabling the Java Runtime on those systems that need it, and only explicitly enabling it when the application(s) that require it need to be used. This can be done through the Java Control Panel.

 

Minimum Solution: Disable Java Plugins in the Browsers

Sometimes, though, it’s just not practical to disable Java. Some business applications are used on a daily basis, or the process of enabling and disabling Java don’t work well for some users. At a minimum, though, you should disable Java in web browsers. This is fairly easy to do in almost every environment. Here are links for disabling Java in each of the major browsers:

 

Required Solution: Patch Java!

If you don’t uninstall Java, and regardless of whether you disable it completely, partially, or not at all, absolutely you need to keep it patched with the most current updates. Failing to apply this JRE7u11 patch can result in the installation of malicious software on PCs in order to steal identities or make infected computers part of a network used to attack websites.

 

To help all IT Pros with this challenge, today SolarWinds has updated the Patch Manager evaluation edition to include this latest JRE7 update. Previously only an older version of JRE6 was available for evaluations. We also know that the vulnerability exists in JRE6, and hopefully there is an update for JRE6 coming soon from Oracle, so when that update becomes available, we will also make it available to all evaluation users. Effective today, you can fully patch every JRE7 system in your network using a 30-day free trial of SolarWinds Patch Manager.

 

Oh, and, it takes a lot less time using Patch Manager! You can be done in as little as a few hours, typically overnight for most organizations – as opposed to days if you’re using scripts or doing it manually. Check out this video for a quick look at how Patch Manager makes patching Java so much easier.

 

If you need assistance, the Customer Portal is available for customers and evaluators can email direct to itmanagement@solarwinds.com. In addition, you can post to the Thwack Patch Manager forum, which I continuously monitor. Whether it’s completely uninstalling Java, or patching the installations you keep, Patch Manager has the ability to help you do both.

 

One last note, this new JRE7u11 update also has new protection mechanisms for dealing with unsigned Java applications, and will notify the user if one is encountered. This is a function of elevating the default security level from “Medium” to “High”, and is discussed further in the JRE7u11 Release Notes.

In several conversations during the past year I’ve observed an increasing number of occurrences of “Timeout Errors” with regard to Microsoft WSUS installations which seems to add complexity to WSUS patching.

 

When? and Why? Timeout Errors Occur

So typically in microsoft WSUS patch management, these timeout errors manifest in one of three ways:

 

Using the console to retrieve data for display

If a large number of updates is required to satisfy the query, or the complexities of the relationships between updates, approvals, target groups, and computer update status result in extra execution time, the console gets tired of waiting on the database.

 

Using the Server Cleanup Wizard

This issue manifests as a result of the “Delete Unneeded Updates” task, and typically is seen on servers that have been operational for a long period of time where the Server Cleanup Wizard has never been used.  It can also manifest on WSUS servers that just have too much data. Deleting data from a table in SQL Server is a fairly ‘expensive’ operation all to itself, and because there are constraints on whether updates can be deleted by this task, those constraints must be validated for each update identified as a candidate for deletion. The amount of execution effort required to validate these constraints can also be time consuming. Fundamentally this is a result of ‘too much work to do’.

 

Synchronizing from a replica server

Synchronizing updates from one WSUS server to another is a fairly simple process, but in the case of the replica server, it’s also necessary to synchronize approvals and declines. However, the WSUS server does not synchronize state data, but rather synchronizes events. Synchronizing an approval is a per-group event (number of updates approved x number of groups affected). Declining an update is the inverse of the approval (number of update approvals removed x number of groups affected PLUS the actual decline event). There are two very specific scenarios in which replica timeouts are being observed.

  • The first is caused because the upstream server simply has too many updates approved. Typically this scenario manifests when the replica server is first installed, as a result of the initial synchronization.
  • The second is caused because the upstream server has too many approval events to synchronize. Typically this scenario manifests when a large number of updates have been mass declined on the upstream server.

 

Eliminating and Avoiding Timeout Errors

As seen, the specific internal behaviors of the WSUS database that contribute to these scenarios are somewhat different in each case; but in every case, preventing these timeout errors can almost always be achieved by engaging in four maintenance “best practices” on your WSUS server.

  • Removing unnecessary approvals
  • Removing excessive updates
  • Defragmenting the filesystem hosting the WSUS database
  • Using the WSUS DB Maintenance script

 

Over the course of the next four weeks we’re going to dive into greater detail on patch management on each of these four highly recommended maintenance practices, and talk specifically about WSUS patch management and what each practice provides to the WSUS environment to avoid timeout errors, and how to ensure these tasks are performed correctly.

 

WSUS Timeout Errors - Removing unneeded update approvals

WSUS Timeout Errors - Too many updates

WSUS Timeout Errors - Defragment the filesystem

WSUS Timeout Errors - WSUS Database Maintenance

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.