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

Specify Intranet Microsoft Update Service Location

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.

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

Configure Automatic Updates

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.