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.

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.