Showing results for 
Search instead for 
Did you mean: 

Configuring Your First WSUS Client

Level 17

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

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.

Level 7

Mr Garvin...I enjoyed your article. I set up my systems as you suggest but I'm still not getting the registration of either the WSUS server or one workstation in the WSUS application. There is connectivity between the two devices. I can ping by both IP address as well as computer name, so I believe DNS is not an issue. Can you offer some suggestions as to where I should look next?

Level 17

I'm assuming, having read the article, that you've also performed the three activities related to "Confirm the Policy Was Applied":

1. Inspect the registry.

2. Review the WindowsUpdate.log

3. Run the Diagnostic Tool.

What were the results of those activities?

Level 7

Good point. I didn’t. My apologies. I’ll get those steps done right away!



Level 7


All my setting are as the same as in your article except I have a question about the NoAutoUpdate option.

In your article, under: 1. Inspect the Registry, it says,

“NoAutoUpdate – should be ‘1’”

According to technet, the NoAutoUpdate registry keys refers to the following setting in gpedit:


Stores configuration data for the policy setting Configure Automatic Updates.


The values of NoAutoUpdate are:

Range = 0|1

0 = Enable Automatic Updates.

1 = Disable Automatic Updates.

If I set the value of NoAutoUpdate to "1" in my registry then that make the Configure Automatic Updates option in gpedit "Disable Automatic Updates," and that makes it impossible to set the value of AUOptions to anything. I'm still a novice, so it is entirely possible that I have misinterpreted something here. Please advise. I'd love to get this system working.

Thanks for your help,


Level 17

In your article, under: 1. Inspect the Registry, it says,

                     “NoAutoUpdate – should be ‘1’”

That is a typographical error in the article, and it's now been fixed.

NoAutoUpdate should always be '0'.

It would be set to '1' if the policy Configure Automatic Updates were DISABLED.

Level 7

Thanks. I also looked up a specific error in my windows log file and applied a KB patch.

The error was: FATAL: Ident cab verification failed with error 0X800B0001

I googled it found references to the following:

Update for Windows Server Update Services 3.0 SP2 for x64-based Systems (KB2720211)

I applied the patch, reforced the gpupdate and ran windows update successfully. Actually, it’s running on all servers and workstations properly, except now only my Windows 7 workstations are reporting in. The servers are showing up in the WSUS manager but with a yellow exclamation point and 0% plus “not yet reported.”

Level 17
The servers are showing up in the WSUS manager but with a yellow exclamation point and 0% plus “not yet reported.”

What Windows version are your servers running?

Review the WindowsUpdate.log for the error.

Level 7

Thanks for the great and very help in getting this. my firsts WSUS instalaltion on the road ...... but (of course there is a but) I still appear to have one problem that I can't figure out.  I'm pretty new to 2012R2 and completely new to WSUS.

I followed these steps and have validate the registry settings, and ran the WSUS Diagnostic to check that I had done everything correctly on the server, which is 2012 Essentials R2  Confirmed with IIS mgr that WSUS is on port 8530.for HTTP and 8531 for HTTPS.  All are green but 2:

WSUS Server Connectivity

     content     Error:Forbidden     Incorrect proxy client configuration - use settings tab ......     Error: NotFound     Omitting required port suffix .....

So i have tried and searched everything that I can find.  There is not proxy server on this network, just a simply small network with a D-Link router in the hangar with 12 PC's, all hard wired.  I'm following your instructions and working ONLY on the server at this point; have not touched any clients at all.  Policies are good, gpupdate runs no errors, registry keys are all correct from the article.








Any help would be tremendously appreciated.


Level 17

WSUS Server Connectivity

     content     Error:Forbidden     Incorrect proxy client configuration - use settings tab ......     Error: NotFound     Omitting required port suffix .....


As it happens, these are actually expected responses when the DiagTool is targeted to a WSUS v6 server. The tool was originally developed/tested prior to the release of Windows Server 2012 and WSUS v6, and two significant changes happened with the release of WSUS v6.

  • The default installation is now to the alternate v-root ("WSUS Administration"), and the use of selfupdate resources in the Default Web Site was deprecated, since that capability is no longer required. As such, the DiagTool does a check for the IUIDENT.CAB file in the Default Web Site, and that test will fail on a WSUS v6 server installed in the default configuration.
  • The WSUS Role unnecessarily installs (but does not enable) the Directory Browsing module in IIS7. As a result, IIS then returns an HTTP 403.14 (Directory listing denied) when the DiagTool attempts to browse the /Content v-dir, and subsequently misinterprets that as a proxy error, rather than the directory browsing error that it actually is. If the role service is not installed, then IIS simply returns an HTTP 200 and ignores the request as it's not valid.

You can safely ignore both of those messages; however, you may wish to consider removing the "Directory Browsing" role if it's not actually needed.

Level 7

Thanks for the quick reply.  I though they were OK from reading the whitepaper you had available for downloading, but it showed a command window version of the tool, so I thought I'd check.

So the other question I have is simple I think.  None of the computers using this server are members of this or any other domain.  I believe that I can manually (via registry) configure the pilots windows 7 machines to use this server for updates instead of hammering the internet connection each time they are here.  Is that correct?

Thanks again!


Level 17

You can configure them using the registry; however, I would recommend configuring the first using Local Policy, and then use REG EXPORT and REG IMPORT to clone the configuration to the remaining systems.

Details on configuring the client with policy can be found in Configuring the Windows Update Agent - Overview and the four subsequent articles.

Level 7

That was exactly what I did.  Now another question, hope that's ok as I don't want to wear out my welcome ....... : )

Is there a way on the server that I can see what updates have downloaded to the server?  I'm looking in WSUS Console and the Updates pane shows, for example, that there are 8627 "All updates" updates with no status, and 44 "updates needed by computers" of which I presume the actual server is one of, but I can't actually see any updates anywhere.  It started sync about 9 hours ago, and I did "apply" the Approve all updates" rule.  What I'm after is simple I think.  I'd like it to DL all of the updates for the products I've selected, and them automatically approve them so that they are available to the computers that connect with no intervention by anyone.


Level 17

Yes. In the All Updates view, right click on the datagrid title bar and enable the "File Status" column. The "File Status" column presents an icon with three different values, which you can view by hovering over the icon. The values are "Files not downloaded", "Ready for installation", and (I believe) "Pending download" (or the equivalent). If you sort on this field, you can see all of the updates that have successfully downloaded to the WSUS Server.

As for automatic approvals, you'll need to create and enable an Automatic Approval for the categories/classifications of updates that you wish to automatically approve. But I would strongly caution you against doing so. The whole purpose of having a WSUS Server is to allow you to manage which updates get deployed, to where, and when. If you're going to automatically approve all updates, you might as well just continue to use Automatic Updates and leave the WSUS server out of the equation entirely. In addition, quality of updates is a notable concern, and if you've paid any attention at all to the patch management community in the past six months, I can tell you that Microsoft has had at least one major update issue every month. Automatically deploying broken updates can be a much bigger headache to clean up, than the risk of not deploying them for a few days after release.

Level 7

Added the column, now 48 (of 9537) updates are showing have the gray icon that reads (Ready for Installation (files not downloaded) so I'm not sure where to go from here.  I believe they will actually download once I approve each of them if I'm reading correctly.    In the view I have selected Approval: Any except declined  and Status:Needed and hit refresh.  The remainder of the files are not in the list.  Just an FYI that I do have and have been trying to use the Microsft provided documentation but it's impossible to find anything if you do not know exactly what it is called.  So iam (probably incorrectly) guessing that WSUS has determined that I have 48 needed updates and the balance of the 9537 are not needed.  And I have no idea how to tell it that they are, unless they do that by have that type of client connect to them?

Advice well prescribed on the approval.  So here is my dilemma.  I have a VERY remote location with a relatively low bandwidth connection located air a VERy remote airfield.  This group that travels through there (about 30 pilots) have an hour or two typically between flights where, among other things, I need them to update their machines.  When I have 2 or more doing it at once, the internet connection gets saturated VERY quickly, usually 1-3 minutes, from Windows update.  This not only impacts them, but the other users, including the 2 full time staffers in the building, which is an enormous problem.  They only get this internet access once and maybe twice a month, and they never get caught up, and also have little or no bandwidth left to other equally critical tasks.  So my solution was to build them a WSUS server to feel them the updates LOCALLY, thus not touching the internet connection at all.  Upgrading the connection is not an option in this area; it is as fast as we can get.  So I was going to have the WSUS server install ONLY the criticals.  I am painfully aware of the issues that several of these updates have left behind, but it very much pales in comparison to the current problem.

Level 17

The scenario you describe with the pilots and short time frames and saturated WAN links is an excellent opportunity to install an AUTONOMOUS Downstream Server configured with an Automatic Approval rule for Security and Critical Updates (the Default Rule will meet this need). The only addition you'll want to implement is to put a DEADLINE on that Automatic Approval rule so that the updates have an immediate deadline. This will actually FORCE the updates to be installed onto those systems when they connect to the network.

I would not impose that configuration on the rest of your not-constrained organization, though.

As for the documentation .. you're correct that it's hard to find things if you don't know what you're looking for. My advice, as loathe as it may sound, would be to simply read the Operations Guide, in order, cover to cover. It'll probably take a couple of hours, but that will be a couple hours well invested, and the console will make significantly better sense once you have. (Note: The link goes to the WSUS v3 OpsGuide. There is no OpsGuide for WSUS v6 ... yet. But the functionality of WSUS v3 and WSUS v6 is identical.)

Level 7

Thank you very much for the link; I've already started to read it.  Would never have found it otherwise!!!!  I did implement deadlines already, though a little differently. I think I'm going to use RDP yo get into the server to approve them.  My idea was to build the server here, get the bulk of the updates already downloaded, ship it to the, and have it auto update itself in the 9 non-user hours each day.

Now im getting an error on the console that it cannoy connect to the wsus server and prompting me to reset the wsus connection, which i am trying.

The only problem with your solution would be that there are no connections with any other servers.  We don't use servers anywhere anymore except in really remote locales such as this, and they are all highly bandwidth constrained.  The bulk of data is stored and shared via Google Drive and the system has worked exceptionally well!!!!!!  The users love it and so do we, and it has had the added benefit of enormous cost savings over MS or even linux servers everywhere.  Our support calls have plummeted, much less maintenance, and most importantly, very satisfied users since we did this withfar fewer issue.  We've switched from a big number of small server to only now 4, and they are are located in very remote locations where bandwidth is at a premium.  But the Win update problems have continued to plague us.  A large part  of the machines are user-owned, and we do enjoy great users that are very conscious of maintaining and keeping current with both hardware and software.

So what happened to wsus 4 and 5?    LOL  .......

Thanks again!!

Level 11

Good nice to see this remembering those days...

Level 7

OK, so I've now been through the ops giude and it was somewhat useful, though I learned far more from your responses than I would have ever gotten from IT .....

Anyway, 23 hours and no sleep later I now have a working WSUS server, or so it would appear.  MUCH quicker than from MS Update!

Based on many of the things that you said in earlier posts, I decided to add another server here in the lab to do the same here, and maybe try the upstream approval process in the longer time.  Grabbed an old box and a fresh copy of 2012R2 to add a fifth server that I'll use primarily for WSUS, but I'm sure I'll find other things to learn on it.  I've followed the MSDN article to "backup" the WSUS stores to restore to that machine once it's done so that at least that wait will go away ..... LOL.

I just wanted to say Thank You again for all of your help in resolving my issue and pointing me in the direction to get it up and running!  Now I'm just not sure why everyone doesn't use WSUS, other than the lack of adequate documentation.  It will now be a part on my standard install.

Thanks and best wishes!


About the Author
I'm a Head Geek and technical product marketing manager at SolarWinds. I wrote my first computer program in RPG-II in 1974 to calculate quadratic equations and tested it on some spare weekend cycles on an IBM System/3 that I ‘borrowed’ from my father’s employer. After that I dabbled, studied, and actually programmed in just about every language known for the past 40 years; worked on a half-dozen different variants of Unix on 3B2s, RS6000s, HP9000s, Sparc workstations, and Intel systems; connected to CompuServe on a 300 baud modem; ran a FidoNet BBS on OS/2 on a 9600 bps modem; and started working with Windows when Windows NT4 was still the latest operating system. Along the way, I did a few years in database programming and database administration. I installed some of the first ADSL and SDSL Internet circuits in Texas, and then migrated into full-time Windows systems management, which had a lot to do with my interest in SUS and WSUS 10 years ago. This ultimately led me to EminentWare in 2009, and SolarWinds three years later.