1 2 3 4 Previous Next

PatchZone

95 posts

One of the lesser known (or understood) features of WSUS is the ability to assign a computer to more than one Target Group. Multiple Target Groups can be useful for managing special-case approval needs for a specific update, as when a small subset of computers should not receive a particular update. They can also be useful for creating custom reporting groups, when used in conjunction with the WSUS Reporting capability for filtering by Target Group.

 

When using multiple Target Groups to manage approvals, there’s often a question of the effective approval for an update.

 

  • If you have two peer groups and Update ‘A’ is Approved for Group ‘A’ and Update ‘A’ is Not Approved for Group ‘B’, then Group ‘A’ gets the update and Group ‘B’ does not. If a computer belongs to both groups, then the computer gets the update, because, unlike AD or NTFS ACLs, there is no “Deny” operation on a per-group basis. All it takes is one approval from one group where a computer has membership.
  • If you have a parent-child group, and Update ‘A’ is Approved for the Parent Group, by default the Child Group will inherit that approval unless explicitly marked as Not Approved for the child group.

 

In the case where a handful of systems need to NOT get an update, the only practical way to implement the solution is with a Parent->Child group, where the Child Group is the group of exclusions. The advantage to this is that the six systems will inherit all of the existing approvals from the Parent Group, but the specific update of interest can be set to Not Approved for the child group.

 

If you create peer groups, then you must remove the six machines from the original group or they’ll still have an approval for the unwanted update. Also, you’ll have to replicate all of the existing approvals from the existing group to the new group. Finally, removing a  computer from an existing (normal) group can be undesirable for many reasons, the most notable being reporting. For organizations that report by target group, removing systems from a regularly-assigned target group will negatively impact reporting. In the end, just way too much work to achieve the objective desired.

 

When the issue affecting the special-handling update goes away (i.e. the update is fixed, superseded, or expired), the only ‘undo’ that is required is to remove the systems from the child group and delete the group.

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

 

Number of Releases: 8

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

Important Security Updates: 5 addressing vulnerabilities in Windows and Office 2003/2007/2010/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 Nov 13, 2013, at 11:00 AM Pacific Time (US & Canada).

Register now for the November Security Bulletin Webcast.

You can also follow the MSRC team at @MSFTSecResponse.

 

Updates are typically released by Microsoft at 10am PDT (5pm UTC).

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

This is not really a new issue... but I suspect it's unknown to many. I just encountered it today.

 

In January, 2013, MS13-002 was released to all channels to fix two privately reported remote code execution vulnerabilities in MSXML v4 Service Pack 3.

MS13-002 superseded MS12-043, released to all channels in June, 2012, that fixed a publicly reported remote code execution vulnerability.

These vulnerabilities are exploitable through specially crafted HTML email messages or web pages.

 

HOWEVER…. Service Pack 3 for MSXML v4 was never released to automated channels. Even today, it is only available as a download from the MDC.

 

MSXML v4 SP2 expired support in April, 2010, so the above security fixes for MSXML v4 SP3 were not released as updates for MSXML v4 SP2.

MSXML v4 was an upgrade to MSXML v3 (which ships on all WinXP and newer systems) and targeted to ISVs for use in applications, so presumably it only gets installed if an application utilizing MSXML v4 has installed it.

 

Anybody care to guess the probabilities that the remote code execution vulnerabilities that exist in MSXML v4 SP3 also exist in previous versions?

 

Now.. here’s the really bad news….

  • How many of your systems have MSXML v4 installed? You might not even know which ones!
  • Have you upgraded your MSXML v4 to Service Pack 3 on those systems. (I haven’t. Yikes! Heck, I didn’t even know I needed to!)
  • Have you installed MS13-002 to those systems? I’ll bet, except for systems that did get manually updated to MSXML4SP3 (or responsible applications that are using the current version), that MS13-002 (or MS12-043) shows as “Not Applicable” to most of your enterprise. Oooops! Some of those systems may not have MSXML v4 installed. Some of them likely have MSXML v4 SP2, or even earlier, installed. If installed, it should be listed in Programs & Features, and you’ll have the expected msxml4.dll and msxml4r.dll in the System32 or SysWow64 folders. Note that MSXML 4.0 is a 32-bit only package.

 

Investigating my system…. (sigh)…. It looks like LastPass installed MSXML4SP2 – which means, B&G, LastPass is shipping with an insecure version of MSXML4.

UPDATE/CORRECTION: After conversation with LastPass, I have learned that LastPass did NOT install MSXML4 (in any variety or version). Not sure what DID install MSXML4SP2 to my system, but I'm uninstalling it immediately!

It’s a matter of curiosity how many other products may be shipping with this vulnerable (and unsupported) instance of MSXML v4 SP2.

 

Check your systems. Uninstall MSXML 4 if it's not needed, or upgrade it to SP3, and then install MS13-002.

On Thursday (Oct 3) Microsoft announced the forthcoming content for Patch Tuesday – Oct 8, 2013.

 

Number of Releases: 8

Critical Security Updates: 4 addressing vulnerabilities in Windows XP, Internet Explorer (v6, 7, 8), Outlook 2007/2010, Windows Sharepoint Services v2/v3, Sharepoint Server 2007/2010/2013, and Office Web Apps 2010.

Important Security Updates: 4 addressing vulnerabilities in Office 2003/2007/2010/2013, Sharepoint, and Silverlight v5.

 

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 October 9, 2013, at 11:00 AM Pacific Time (US & Canada).

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

 

You can also follow the MSRC team at @MSFTSecResponse.

 

Updates are typically released by Microsoft at 10am PDT (5pm UTC).

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

Insightful thoughts and probing questions from Tom Hollingsworth in the Systems & App forum.

http://thwack.solarwinds.com/message/211929#211929

 

Check it out. Join the discussion!

On Thursday (Sep 5) Microsoft announced the forthcoming content for Patch Tuesday – Sep 10, 2013.

 

Number of Releases: 14

Critical Security Updates: 4 addressing vulnerabilities in Windows, Internet Explorer, Outlook 2007/2010, Windows Sharepoint Services v2/v3, Sharepoint Server 2007/2010/2013, and Office Web Apps 2010.

Important Security Updates: 10 addressing vulnerabilities in Windows, Office 2003/2007/2010/2013, and FrontPage 2003.

 

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 Sep 11, 2013, at 11:00 AM Pacific Time (US & Canada).

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

 

You can also follow the MSRC team at @MSFTSecResponse.

 

Updates are typically released by Microsoft at 10am PDT (5pm UTC).

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

On Thursday (Aug 8) Microsoft announced the forthcoming content for Patch Tuesday – Aug 13, 2013.

 

Number of Releases: 8

Critical Security Updates: 3 addressing vulnerabilities in Windows, Internet Explorer, and Exchange Server 2007/2010/2013.

Important Security Updates: 5 addressing vulnerabilities in Windows.

 

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 Aug 14, 2013, at 11:00 AM Pacific Time (US & Canada).

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

 

You can also follow the MSRC team at @MSFTSecResponse.

 

Updates are typically released by Microsoft at 10am PDT (5pm UTC).

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

One of the questions that I continue to encounter from new WSUS Administrators relates to taking approvals for updates deployed to a testing group, and easily duplicating those approvals onto one or more production groups. In this article we’re going to look at how to do that using the WSUS native console.

 

It’s actually a very simple process, but we’re going to do a step-by-step in the article. The process goes like this:

 

  1. Create a Custom Update View to show the updates approved for the test group.
  2. Select the newly created view and customize the view.
  3. Select the updates to be approved for the production group and approve.

 

Step 1: Create a Custom Update View to show the updates approved for the test group.

 

In the WSUS console, select the Updates node in the console.

New Update View 1.png

Right click and select New Update View…

New Update View 2.png

In the section Step 1: Select properties” check the third option in the list “Updates are approved for a specific group”.

 

Add Update View Step 1.png

In the section Step 2: Edit the properties click on the hyperlink for “a specific group” and select your test group from the list of groups. In this example we've selected "Test Computers".(If you have multiple different test groups, you’ll need to create a custom update view for each test group.)

Add Update View Step 2.png

In the section Step 3: Specify a name enter a view name appropriate to the defined content. Here we've named the view "Test Group Approvals".

 

Add Update View Step 3.png

Step 2: Select the newly created view and customize the view.

 

After selecting the view, you’ll likely want to modify the view a bit to make it more efficient for this use.

  1. On the filters, set Approval=”Approved” and Status=”Any”.
  2. Right click on the column header and add the Release Date and Arrival Date columns in the view.
  3. Click on the Release Date column header to sort the view with newest release date on top.

 

Test Group Approvals View.png

The Approval column can provide a key indicator as to the updates you’re interested in selecting. Aside from focusing on the updates with a release date consistent with your patch collection, the Approval column can be used to provide hints to the updates approved only for the test group. In the Approval column it’s likely the case that the entry looks like “Install (1/#)” where the value ‘1’ represents the test group as the only current approval target, and the value ‘#’ represents the total number of target groups configured on your WSUS server. We can see that this server has ten target groups defined (including "All Computers" and "Unassigned Computers").

 

Step 3: Select updates to be approved for the production group and approve.

 

Using the Release Date column and/or the Approval column, identify the updates to be approved for the production group(s). Select the updates using Shift-Click or Ctrl-Click. Right click and select "Approve" from the context menu.

 

Here I’ve selected three updates approved for the Test Group and will approve them for the Win2008R2 group.

Add Approvals.png

 

Update Views are Per-User

 

Make special note that these custom update views in the WSUS Admin Console are created on a per-user basis, so if multiple administrators need this view, it will need to be created on each console.

 

SolarWinds Patch Manager

 

You can also create this update view in SolarWinds Patch Manager, but Patch Manager provides an even better (and easier) way to do this, and I talk about that in this Geek Speak article.

 

Part 1: Package Creation Fundamentals, August 7, 2013, 11am CT

Lawrence Garvin, SolarWinds Head Geek and WSUS MVP, will provide an overview of the detection logic used by the Windows Update Agent and how that determines the update states reported to WSUS (Installed, Not Installed, Not Applicable), the three rule sets (Prerequisite, Applicability, and Installed) thate comprise the detection logic and how they are used in the detection process, focusing on the six detection logic rules that are used in 99% of package creation activities. 

 


Part 2: Creating Packages with Patch Manager, September 4, 2013, 11am CT

Lawrence Garvin, SolarWinds Head Geek and WSUS MVP, will discuss how to create basic and advanced packages with the Package Wizard feature of Patch Manager.  He will also discuss how to use the PackagBoot™ function to create complex before and after deployment scenarios.  Bring your questions and we’ll answer them!

 

 

Register here. Can't make it? Register anyway and we'll send you a link to the recorded webcast.

With all of the activity over the past year as a result of the Flame malware fiasco, it seems a great time to take a step back and review the issues, considerations, and responses appropriate to the Windows Server Update Services (WSUS) environment as a result of these certificate-related changes.

 

During the 2nd and 3rd quarters of 2012, a number of changes were made in the certificate infrastructure of Windows Update, which also impacted the operation of WSUS environments. All of these changes culminated in the release of KB2661254 which has as its sole purpose to quarantine (read: disable) any certificates present on a system that were built with key-lengths less than 1024-bits.

 

For WSUS Administrators, there are three possible ways in which this may have an impact.

 

WSUS SSL Certificates

For WSUS Administrators who have implemented Secure Sockets Layer (SSL) connections for their WSUS servers, the age and provenance of the SSL certificates in use may be a concern. Be sure that your SSL certificates have at least 1024-bit keys.

 

On Windows Server 2008 and newer (IIS7), to check your SSL certificate, navigate to the IIS console in Server Manager, select the root node of the IIS console, and double-click the “Server Certificates” icon. Double-click on the certificate to open the Certificate dialog.

WSUS SSL Cert on IIS7.png

On Windows Server 2003 (IIS6), open the IIS Admin Console, select the WSUS website, open the Properties dialog, select the “Directory Security” tab, and click on the “View Certificate…” button to open the Certificate dialog.

WSUS SSL Cert on IIS6.png

Once the Certificate dialog is open, select the Details tab, and view the value in the “Public key” field to identify the key-length.

Certificate Key Length verification.png

Local Publishing Certificates

More commonly (than SSL, believe it or not), many WSUS Administrators may have local publishing certificates in use. All local publishing certificates created prior to April, 2012, will have been created with 512-bit keys. Additionally, any certificates created after April, 2012, but prior to the installation of KB2720211 (April 2012) or KB2734608 (August 2012) to the WSUS server, will also be 512-bits. Certificates created after the installation of one of those updates will be 2048-bit certificates.

 

To check your Local Publishing Certificate, on the WSUS server launch the Certificate Management console with CertMgr.msc. Navigate to the “Trusted Publishers” certificate store, and double-click on the WSUS Publishers Self-signed certificate. As with the SSL certificate above, on the Details tab, scroll down the attribute list and find the “Public key” attribute. It should show “RSA (2048 Bits)”.

Other Certificate-based Applications

In addition to the two instances directly affecting WSUS, there may also be other applications that are dependent upon certificates for their operation. SolarWinds Patch Manager is one such application. It uses certificates to authenticate and encrypt console-to-server and inter-role communications. It was updated in July, 2012, with the release of v1.73. However, there may be other applications in the environment that have not been updated. It’s important to know which applications you have that are certificate-based and what type of certificates are in use.

 

Beware KB2661254

KB2661254, if installed, will BREAK all three of the above scenarios by quarantining the certificates.

 

If the SSL certificate is less than 1024 bits, the Windows Update Agent will record HTTP 403 errors, most likely an HTTP 403.4 (SSL required). In the WindowsUpdate.log these will appear as error codes 0x80190193 or
0x80244018.

 

If the Publishing certificate is less than 1024 bits, the publishing software will encounter errors publishing new packages, and the Windows Update Agent will record an 0x800B0109 error.

 

Other applications affected may behave in various different ways, for example in the case of SolarWinds Patch Manager, the consoles will be unable to connect to the application servers, and if you have more than one Patch Manager server deployed in a distributed infrastructure, the servers will be unable to communicate with one another. Any attempt to register a new server will also fail.

 

Be sure to patch the WSUS server, update the SSL or Publishing certificates, redistribute the certificates, and re-publish any locally-published updates prior to installing KB2661254. For more information, please read the complete Microsoft KB2661254 article, which also includes guidance on how to override the impact of this update if you have already installed it and cannot resolve key-length issues with existing certificates.

 

Why Is This Still an Issue?

Inasmuch as the update has been available for nine months, you might think this is merely historical pedanticism at this point.

 

Sadly, though, every day I encounter environments that have not patched the WSUS server (KB2720211) nor deployed KB2661254. This article is for those who have not yet done so, in the hopes that they will be able to
avoid the trials and tribulations experienced by those who inspired this article to be written.

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

 

Number of Releases: 7

Critical Security Updates: 6 addressing vulnerabilities in Windows, Internet Explorer, Silverlight v5, Office 2003/2007/2010, Lync 2010/2013, and Visual Studio 2003

Important Security Updates: 1 addressing vulnerabilities in Windows Defender on Windows 7 and WS2008R2.

 

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 Jul 10, 2013, at 11:00 AM Pacific Time (US & Canada).

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

 

You can also follow the MSRC team at @MSFTSecResponse.

 

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.

One of the great features built into Microsoft’s Windows Server Update Services (WSUS) is the ability to address the needs of networks that are not connected to the Internet. The WSUS Deployment Guide describes the basic requirements and procedures for implementing this capability in the article Configure a Disconnected Network to Receive Updates.

 

Over the years, though, this procedure has routinely coughed up a few ugly “gotchas” that have made life a bit annoying for some WSUS administrators. In this article I’m going to talk about the most commonly seen “gotchas”, why they exist, how to remediate them, and how to avoid them.

 

The procedure works in this order:

  1. Copy files from connected server to portable storage
  2. Export updates from connected server
  3. Copy files from portable storage to disconnected server
  4. Import updates to disconnected server

so that’s the order in which I’m going to cover the “gotchas”.

 

But before starting the procedure, make sure that the relevant settings are identical on both servers. This includes all settings on the Update Files and Languages dialog, as well as the selections on the Products and Classifications dialog.

Copy Files from Connected Server

In order to successfully copy all of the needed files from a connected server, they must first be present on the connected server. Updates that may be needed in the disconnected server must be Approved for Install on the connected server so that the files are downloaded. Also, before executing the copy of files to the portable storage, double-check the console of the connected server and verify that all update download are actually completed.

The other notable “gotcha” is how the copy is performed. You should copy the Subfolders of the WSUSContent folder, not the WSUSContent folder itself. The subfolders and files inherit ACLs from the WSUSContent folder, but the critical ACL item is the Full Control permission granted to the LOCAL Group “WSUS Administrators”. If you copy the WSUSContent folder itself, you’ll overwrite the ACLs on the disconnected server and WSUS won’t be able to find the content.

Export Updates from Connected Server

The only “gotcha” in this step recently started occurring with greater frequency. The native export format for the update metadata is the CAB file format. CAB files, though, have a maximum size of 2 Gigabytes. On servers with the “Drivers” and/or “Definition Updates” classification selected, the large number of updates in those two categories may create more export content than can fit into a 2GB CAB file.

There are two things to do to avoid this situation. Properly maintain approvals on the connected server and use the Server Cleanup Wizard. On a connected server the only reason to approve updates is to get files downloaded. Once the files are downloaded, they will not be deleted unless the updates are declined; also, files will not be deleted from the disconnected server unless they are declined there and the Server Cleanup Wizard is used, so truly the only files we actually need on the connected server are the files for new updates. I recommend as part of your regular export/copy procedures that you also decline all expired and superseded updates and run the Server Cleanup Wizard prior to beginning the export/copy. Also, having a smaller set of files to copy from the connected server to the disconnected server can make that process much faster.

Copy Files from Portable Storage to Disconnected Server

If you copied the Subfolders of WSUSContent, then this step is pretty straightforward, but make sure the disconnected server’s WSUSContent folder is actually where it thinks it should be. I’ve seen an occasional case where the WSUSContent folder was copied somewhere else and it couldn’t be found.

Also, with respect to the ACL issue mentioned in the earlier section, if you do happen to copy the WSUSContent folder and overwrite the ACL, it can be easily remediated. As noted, the key is the WSUS Administrators local group. If this has happened, you’ll see an unresolvable SecurityID in the Permissions dialog for the WSUSContent folder. Remove that ACL, add back the real “WSUS Administrators” local group, grant it Full Control applied to folder, subfolders and files, and select the “Replace all child object permissions” so the ACLs get applied to the entire folder tree.WSUSAdminACLforWSUSContentFolder.png

Import Update to Disconnected Server

The most notable “gotcha” with this final step is impatience. The WSUS Operations Guide notes that the WSUS server make take “3-4 hours” after the wsusutil import task completes before it fully reconciles all of the update approvals with the files in the content store. That “3-4 hours” estimate dates back to the original release of WSUS v2 in 2005 when there were only a few thousand updates in the entire WSUS catalog. Today a server can easily have ten times as many updates to export/import. Consider the possibility that this task may take several hours, particularly so if being imported to a less-than-well-maintained server or you’re running a server with tens of thousands of updates.

The last “gotcha” is maintenance. Be sure to remove approvals, run the Server Cleanup Wizard, defragment the filesystems, and use the WSUS DB Maintenance script on your disconnected server on a regular basis as well.

On Thursday (Jun 6) Microsoft announced the forthcoming content for Patch Tuesday – Jun 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 Jun 12, 2013, at 11:00 AM Pacific Time (US & Canada).

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


You can also follow the MSRC team at @MSFTSecResponse.

 

Number of Releases: 5

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

Important Security Updates: 4 addressing vulnerabilities in Windows, Office 2003, and Office for Mac 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.

On Thursday (May 9) Microsoft announced the forthcoming content for Patch Tuesday – May 14, 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 May 15, 2013, at 11:00 AM Pacific Time (US & Canada).

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


You can also follow the MSRC team at @MSFTSecResponse.

 

Number of Releases: 10

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

Important Security Updates: 8 addressing vulnerabilities in Windows, Windows RT, Lync Server 2013, Lync 2010, Communicator 2007 R2,  Word 2003, Publisher 2003/2007/2010, Visio 2003/2007/2010, Windows Essentials 2011/2012


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 previous weeks,  I‘ve posted a series of articles about the configuration options available for the Windows Update Agent, but knowing what those options are is only half the battle. One of the most significant challenges new WSUS Administrators face while implementing WSUS is getting the clients configured to communicate with the WSUS server. In this article, we’re going to walk through the steps necessary to make this happen.

Configure the WSUS Server as a Client

Before you dive down into Active Directory, OrgUnits, and Group Policy, always start with the simplest option – configuring the WSUS Server itself as a client. This provides two notable opportunities:

  • Since we’re going to use Local Policy, it eliminates all of the complications that are created by Active Directory and Group Policy.
  • Because the WSUS Server is the client, it also eliminates network communications as a complication.

 

In all of the configuration settings described in previous posts, only one of them is required to configure a system as a client of a WSUS server.

 

Log onto the WSUS Server as the local administrator and run GPEDIT.MSC.

Navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update

WSUSPolicySettings-LocalPolicyEditor.png

 

Specify Intranet Microsoft Update Service Location

Specify Intranet Microsoft Update Service Location - Policy.png

Enable this policy and provide the URL of your WSUS server in both fields of the dialog. The URL should be in the form http://servername. You also need to know whether WSUS was installed to port 80 or port 8530. If it was installed to port 8530, there is a virtual directory named “WSUS Administration” in IIS. In this case, the URL should be http://servername:8530. This information is also presented during WSUS installation on a dialog.

WSUS URL in Installer.png

Since we’re configuring a server, there is a second setting for which we should specify a non-default setting.

Configure Automatic Updates

Configure Automatic Updates - Policy.png

Enable this policy and set the dropdown to Option #3 – Auto download and notify for install. This will allow the WSUS server to transfer the installation files for approved updates from the “server” to the “client”, so they’re ready for installation when you choose to actually update the server.

 

Close the policy editor.

Apply the Policy to the System

Open a Command Prompt and run the command gpupdate /force /target:computer

 

This will apply the two settings you just configured to the system. Also, because the Windows Update Agent is aware of policy change events, this will automatically trigger an immediate detection event with the WSUS server configured in the URL.

Confirm the Policy Was Applied

One of the most common errors I see in configuring a client is assuming that the policy was applied. There are three ways you can verify policy settings have been applied.

1. Inspect the Registry

Open the Registry Editor, and navigate to HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

If the policy applied correctly, these five registry values will be present. (There may be others, but they don’t matter at this point.)

  • AUOptions – should be ‘3’
  • NoAutoUpdate – should be ‘0’
  • UseWUServer – should be ‘1’
  • WUServer – should be the value you entered in the policy settings dialog (e.g. http://servername or http://servername:8530)
  • WUStatusServer – should be identical to WUServer

2. Review the WindowsUpdate.log

At the time you ran the GPUPDATE command earlier, or anytime the Windows Update service is started, these entries of immediate interest will be made to the WindowsUpdate.log:

  • The current client version (if a successful connection was made to the WSUS server after applying the policy, the minimum WUAgent version should be v7.6. On Win8/Win2012 systems this will be v7.8.)
  • The URL of the WSUS server
  • The option chosen in Configure Automatic Updates (Option #3 = “Pre-install notify”)

 

3. Use the Free SolarWinds Diagnostic Tool for the WSUS Agent

This tool will inspect your registry, display all of the significant values found, and identify if any are inconsistent.

Confirm the WSUS Server Appears in the WSUS Console

Finally, after confirming the system has been properly configured, you should review the WSUS console to verify that the WSUS server is listed in the All Computers group.

Add Other Clients

Okay, so we’re done with the hard part. The easy part is just reproducing the above using Group Policy. The first step in using Group Policy is to understand your Active Directory Organizational Unit structure. The second step is to create a Group Policy Object (GPO). While the WSUS GPO can be linked at the domain level, it’s much more realistic that you will have more than one GPO (desktops, servers) and they will be linked by Organizational Unit. Survey your OrgUnits so that you know where the various  machine types are contained. Also consider additional behavioral configurations of the Windows Update Agent that may drive your need for additional GPOs.

Configure a Group Policy Object

Configuring a GPO is identical to the process you used for configuring the WSUS server via Local Policy, except now instead of using the local policy editor you’ll use the Group Policy Management Console (GPMC) with a domain administrator account. The GPO is hosted on the domain controllers and acquired by a client system when the machine logs onto the domain.

 

After configuring the GPO you’ll need to link it to one or more Organizational Units, where those OrgUnits hold the machines that are appropriate for the settings in the GPO.

 

And, like you did for the local policy on the WSUS server, you’ll also need to confirm that the policy is successfully applied by inspecting the registry and/or the WindowsUpdate.log.

Troubleshooting Group Policy

A full discussion on troubleshooting Group Policy issues is beyond the scope of this article, so if you’ve not explored this concept, I would encourage you to do so. If your GPO does not get applied to a client system, this typically happens for one of the following reasons:

  • The client system is not joined to the domain.
  • The client system is not assigned to the correct Organizational Unit.
  • The Group Policy is not linked to the correct Organizational Unit(s).
  • A conflicting policy is overriding the settings in your GPO.
  • Some other (typically more severe) data communication issue is at work. In these scenarios the client is likely not getting any group policy settings, rather than just not getting the WSUS settings.

Use Policy Management & Monitoring tools

You can also use GPResult or RSOP (Resultant Set of Policy) to verify the policy has been applied. RSOP is useful when you need to troubleshoot why a policy is not being applied, or when conflicting policy settings are being applied. For simply confirming that the right settings have been applied, however, reading the registry or the WindowsUpdate.log is much simpler and faster.

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.