1 2 3 4 5 Previous Next

PatchZone

95 posts

About 3 months ago we took an in-depth look at the state of Java with respect to the number of reported/fixed vulnerabilities, and how that impacted earlier versions of Java. Since that time, three additional Java security updates have been released, plus some very interesting research has been published on what versions of Java are still in use. We're going to cover both of those in this update.

 

Recap

Let's start by adding the vulnerability counts for the three most recent updates. To recap, after the release of JRE7u13, which was almost entirely a patch for historical vulnerabilities (only 6 of the 39 fixes applied to JRE7-only vulnerabilities), research showed that over 80% of the reported/fixed vulnerabilities in JRE7 previously existed in JRE6, and almost half of them existed in JRE5:

JRE7u13 vulnerability counts.png

 

JRE7u21

Since that time, another 49 vulnerabilities have been patched -- 42 of them in JRE7u21, which was released just last week. Of those 49, 29 of them also existed in JRE6 (59.2%), and 21 of them existed in JRE5 (42.8%).

 

This brings the total counts for all of the security vulnerabilities identifed in JRE7 up to 172, with 128 (74.4%) present in JRE6, and 82 (47.7%) present in JRE5.

JRE7 total vulnerabilities (thru JRE7u21).png

So, let me say this as loudly and clearly as I can.... it is **NOT** safer to keep running Java 6 or Java 5. If you need to have the Java Runtime Environment installed, then you **NEED** to upgrade to JRE7 immediately, and uninstall any earlier versions of the Java Runtime Environment.

 

Sadly, as recently published research shows, it seems that very few are actually getting that message.

 

Who's not running JRE7?

Recently, Websense added Java version detection capabilities to their Advanced Classification Engine (ACE™) and pushed it through the Websense ThreatSeeker® Network to get real-time information about what versions of Java were in use. A month ago they published their findings. This analysis includes data from TENS of MILLIONS of users, so don't consider this a "representative sample"... this is the Real World folks, and you're quite likely part of it.

 

You can view the multi-colored rainbow-moired pie-chart -or- read the entire article but let me share some of the scariest numbers with you:

  • 8.7% of those tens of millions (that's almost a million browsers), still have versions prior to JRE5 installed. (More on this below!)
  • 2.5% are still using JRE5 (about a quarter million)
  • 3.7% are still using JRE6u7 -- the last version released that was not automatically uninstalled with a patch upgrade
  • 66.4% of browsers are running some variant of JRE6
  • 22.4% have upgraded to JRE7, but only 5.2% were using the current patch level of JRE7 (7u17 at the time of the study)

 

That's over ten million (at least!) systems running an instance of the JRE with known vulnerabilities that are being actively exploited. Websense also notes that "the largest single exploited vulnerability is the most recent one" -- one of the two fixed in JRE7u17! (and also present in JRE6u41 and earlier).

 

JRE5???

What about these million systems actively using a version of JRE prior to 5? Where did they come from? To first grasp this we need to call attention to the fact that JRE5 was originally released in September, 2004. So, by definition, this group includes a lot of Windows XP machines, and even scarier, probably some machines older than Windows XP. It's remotely possible that some of these systems are Windows 2000 or Win9x systems running the Microsoft Java Virtual Machine (JVM) which was based on Java v1.1. One thing I can tell you for certain -- they're probably infested, and most likely are part of a botnet. But consider this ... the data came through Websense, which means the machines are sitting behind a Websense appliance! These are not home systems (well, unless their ISP is running Websense appliances on the front-end) ... these are corporate, governmental, and organizational systems!

 

You need a JRE patching strategy!

Here are some questions to consider in your JRE patching strategy:

  • Have you validated the need to have the JRE installed, and uninstalled it from machines where it is not needed?
  • On the systems where it is needed, have you upgraded to JRE7?
  • On your JRE7 systems, do you have a patch management strategy in place to ensure the latest version of JRE7 is installed?

 

Software Vendors and JRE "compatiblity"

Finally, something I hear a lot -- "My vendor says their software won't work with newer versions of JRE."

 

For those systems where another software vendor claims compatibility issues with newer versions of the JRE:

  • Have you verified that the vendor is not just blowing smoke up your nose because they haven't tested their software against the newest versions of JRE and certified compatibility?
  • What value is "support" from a vendor that can't even keep up with the latest security guidance?
  • Is your network's security and your organization's ability to continue to operate, more important than following the guidance of a software vendor that can't be bothered?

 

Do your own testing!! If it works, then upgrade the JRE, be secure, and then go hold that vendor's feet to the fire for doing the same. Do not let your organization be held hostage to critical security risks by a non-responsive software vendor!

 

There are ten million PLUS systems on the Internet *today* running a version of Java that is known to have active exploits. Do not be part of the problem ... be part of the SOLUTION!

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.

For years patch management for Windows desktops has been a relatively straightforward process. In corporate environments either a WSUS server or a third party patch management solution downloads patches from Microsoft as the patches become available and then deploys the patches to designated Windows computers. However, this tried and true practice might be changing.

 

With its latest operating system releases, Microsoft seems to have thrown a monkey wrench into the patch management process. My purpose in writing this blog post is not to bash Microsoft, but rather to explain what you can realistically expect with regard to patch management should you choose to deploy Windows 8.

 

Some things stay the same

As you have probably heard, Windows 7 and Windows 8 have a lot in common. In fact, some have even gone so far as to say that when Microsoft created Windows 8 they more or less just bolted the Metro interface on top of Windows 7. In reality, there is more to Windows 8 than just a new GUI. Even so, the similarities between Windows 7 and Windows 8 are undeniable.

 

Given how similar the two operating systems are to one another, it should be no surprise that patch management works more or less the same way in Windows 8 as it did in Windows 7. Windows 8 is able to download operating system patches from a WSUS server or from a third party patch management system. That’s the good news.

 

But Metro complicates it

The bad news is that Metro complicates things. Even though WSUS can be used to patch the core operating system, it is not currently being used to patch Metro apps (which Microsoft says we now have to refer to as Windows Store apps).

 

At first this might not be seem like such a big deal. After all, the Windows Store is used primarily for downloading third-party apps. WSUS has never been used for patching third-party apps. The problem is that from the perspective of patch management, Windows 8 does not really differentiate between third-party Windows Store apps and native applets that are designed to run through the Metro interface.

 

To show you why this is a problem, consider a situation that happened recently. The Windows Store tile indicated that updates were available. When I selected the tile, I expected the updates to be for third-party apps. However, the updates were actually for operating system components (People, Calendar, etc.). In other words, Windows 8 seems to have developed a split brain syndrome when it comes to patch management. The operating system kernel and desktop items seem to still be patched through WSUS, but anything Metro related is being patched (at least for right now) through the Windows Store. This is bound to result in some frustration for Windows administrators.

 

Documentation is also an issue

Another issue is the way that the previously mentioned update was rolled out. Normally, when Microsoft provides an operating system update, there is a corresponding KB article that details what the update does and which files are affected. To the best of my knowledge, no such KB article exists for the December update which updated the Mail, Calendar, People, and messaging apps. Personally, I find the idea of undocumented updates to be a bit unnerving.

 

WSUS does not do Windows RT

Another issue that you need to be aware of with regard to patch management is that currently WSUS is not able to update devices running Windows RT. That isn’t to say that Windows RT devices can’t be updated, it’s just that WSUS is incapable of providing updates to these devices. Rumor has it that WSUS will eventually be retrofitted to support Windows RT, but in the meantime Windows RT updates must come directly from Microsoft Update and from the Windows Store.

    

Conclusion

The fact that Microsoft uses a different update method for Windows Store apps is likely going to prove to be frustrating for network administrators. Hopefully Microsoft will eventually release a new version of WSUS that is capable of providing updates to Windows Store apps and to Windows RT devices.

A disruptive day at the office could start when someone says: “Hey, I’m having problems with my OS; the last thing I saw is that there were a bunch of updates being installed”, and if we are not lucky and it is in fact an update that is generating the problem, we will need to get our hands dirty.

 

Getting in the situation when we know we need to rollback an update it is definitely not an easy situation. Maybe if we need to do it in our home computer it would not represent a big problem, but if we are facing a situation where we just approved the update for our entire organization, then things could get really messy.

 

In reviewing some of what we previously discussed in Patching Best Practices we will see that is almost a must to test our updates before deploying; but at this point, whether we tested or not, it does not matter, we need to solve this problem. However, you will see also that it is highly recommended to have ready a baseline image of our company user's system (maybe a virtual machine), this way we can rapidly start working with this image in order to solve the problem.

 

And of course, if we don’t have the baseline image, we can start working with the machine that appeared with the problem.

 

Start Working on the Problem

Having said the necessary about best practices, let’s start working on the problem. Here’s general guidance about what we need to do:

 

  1. If you are using WSUS, mark the recent approved updates as “Not Approved”. This will not remove the updates from computers where the update is already installed, but it will prevent them from being installed on any other systems.
  2. Use the baseline image to review the behavior when we have the updates approved.
  3. Perform some quick troubleshooting (Event Viewer, application logs) to understand a little bit more about the problem.
  4. Remove the updates installed in baseline image. We can use “Control Panel”; or “Windows Update” (in “Read More” section about “Installed Updates” sometimes the uninstall instructions appear).
  5. Verify that the problem is solved. 
  6. To extend this automatically for all users we can use WSUS or scripting:
    • For WSUS, configure the updates as “Approve for Removal” -- this will automate the process of uninstalling.
      • Even more, we set a “Deadline” to remove the update.
      • If we want to remove it as soon as possible, select a date in the past.
      • Important disclaimer: The “Approve for Removal” option is not available for several updates, so we might want to use the “scripting” option.
    • Scripting the update:
      • For Windows XP we can find the folder (hidden) for the update C:\Windows\$NtUninstallKB<number> and generate a script for uninstalling.
      • For Windows 7 we can use a script with “wusa /uninstall /kb:<number>

 

Handling Restore Points

“System Restore Points” are also a valid way to solve a faulty update deployment for Windows OS. A System Restore point is basically an operating system snapshot that is created whenever you make a significant change to your PC. One of the processes that can create restore points automatically is in fact Windows Update.

 

So, whenever we have a problem with a recent change, we can use a Restore Point to recover the exact state we have previous to our change.

 

Using System Restore Points

Using Restore Points does not have any big complication, just following a wizard; but the only trick is that we have to do it manually on every computer:

 

  1. Access “Computer” > “Properties”.
  2. Select “System Protection” and click on “System Restore”.
  3. This will open up a wizard, click “Next” in the first step.
  4. We will have the option for selecting the “Restore Point” to apply to our system, carefully select the proper one.
  5. Reboot the computer.

 

With that we’ll complete the necessary steps to solve our problem. But if we are going to depend on restore points, we must make sure we have the necessary configuration among all of our computers.

 

Creating Restore Points

To create restore points in our computers we can do it of course manually or by an automated process.

 

Unfortunately, the automated process is not all that simple. We will use Group Policy to distribute this configuration among our organization, but we will need a few command lines to accomplish this.

 

  • Creating Restore Points manually
    • Access “Computer” > “Properties”
    • In the left pane, click “System Protection”.  
    • Click the System Protection tab, and then click Create.
    • In the System Protection dialog box, type a description, and then click Create.
  • Creating Restore Points using Group Policy
    • Create a new Group Policy Object and link it to the Active Directory Container of your choice.
    • Create a new Task under [Computer Configuration\Preferences\Control Panel Settings\Scheduled Tasks]
    • Type a name and choose SYSTEM account to run this task.
    • In “Triggers” tab, click “New” and choose the period of time you would like to create a restore point.
    • In “Action” type “%windir%\system32\rundll32.exe" and in “Program/Script”: “/d srrstr.dll,ExecuteScheduledSPPCreation”
    • Click OK and complete the GPO creation.

 

For more information about “Restore Points” review the following link: “System Restore: frequently asked questions”.

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.

Windows clusters have always presented a special problem for those tasked with patch management. On one hand, clustering is very necessary. Clustering provides fault tolerance and is often the only way to protect a mission critical server or service. On the other hand, failover clustering compounds the difficulty of patch management.

 

Cluster Patching – The Old Way

Prior to the release of Windows Server 2012, if you wanted to patch a cluster (using only native tools) you had to move the clustered resources off of a cluster node, patch and reboot the cluster node, and then repeat the process for the other nodes in the cluster. The technique worked, but it required manual intervention and was tedious and time consuming. The manual nature of the process could be forgiven if patching was a one time process, but as any good admin knows, patching is an ongoing process.

 

Cluster Patching – The New Way

Those cluster administrators who dread Patch Tuesday will be happy to know that you don’t have to use a manual process to patch a Windows Server 2012 cluster. In fact, Microsoft has introduced a new feature called Cluster Aware Updating.

 

The tricky part of patching a Windows Server 2012 cluster is that cluster aware updating is not used by default. You have to enable cluster aware updating. Otherwise, the cluster will have to be patched using the same manual technique required by clusters running earlier versions of Windows Server.

 

How Does Cluster Aware Patching Work?

Before I explain how to enable cluster aware updating, you might be curious as to how the patching process works in a Windows Server 2012 cluster.  Cluster aware updating works similarly to the method used to manually patch a failover cluster, except that the process is automated.

 

Windows Server 2012 uses a round robin approach to updating cluster nodes. The process begins by identifying the cluster node that has the most free memory available. The clustered resources are moved from a random cluster node to the node that has the most free memory. After the clustered resources have been moved off of the cluster node, the node is placed into maintenance mode. At this point, the cluster node is patched, rebooted, and then taken out of maintenance mode. The process is then repeated for every remaining node in the cluster.

 

How Is Cluster Aware Patching Implemented

Cluster aware updating is based on the use of a new utility called the Cluster Aware Update Tool. The Cluster Aware Update Tool is automatically installed on all of the nodes in the cluster, but it is not active.

 

If you want to use the Cluster Aware Update Tool from outside of the cluster then you can install the tool by installing the Failover Clustering feature on any machine that is running Windows Server 2012 (you don’t actually have to create or join a cluster).

 

In order to perform cluster aware updating, the Cluster Aware Updating tool must run as a clustered server role. That way the update code can move from cluster node to cluster node as the updating process progresses.

 

How To Configure Cluster Aware Patching

To set up cluster aware updating, open the Server Manager and then choose the Cluster Aware Updating option from the Tools menu. When the Cluster Aware Updating tool opens, select your failover cluster from the Connect to a Failover Cluster drop down box, and then click Connect.

 

Once the connection to the cluster has been established, click on Configure Cluster Self Updating Options. This will cause Windows to launch the Configure Self Updating Options Wizard. Click Next to bypass the wizard’s Welcome screen and you should see a message telling you that the cluster isn’t configured with the Cluster Aware Updating cluster role.

 

You must now select the Add the CAU Clustered Role with Self Updating Mode Enabled to this Cluster check box. Click Next and you will be asked to set a self updating schedule. Microsoft recommends scheduling updates to occur at a time when there is the least possible demand on the
cluster nodes.

 

Click Next a couple more times and you will see a screen asking you if you wish to receive recommended updates the same way that you receive important updates. After making your decision, click Next and verify that the information displayed on the summary screen is correct. You can
complete the process by clicking Apply, followed by Close.

 

As you can see, it is relatively easy to implement cluster aware updating. After doing so, the process of keeping the cluster nodes up to date will be completely automated.

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:;

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.