We help IT Professionals succeed at work.

Configure GPO so server-core will download updates from internal WSUS

RhoSysAdmin
RhoSysAdmin asked
on
I have several server core installs that are not contacting our WSUS server despite manually adding these WSUS registry keys :

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"ElevateNonAdmins"=dword:00000000
"TargetGroup"="Servers"
"TargetGroupEnabled"=dword:00000001
"WUServer"="<mywsus server>"
"WUStatusServer"="<mywsus server>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AUOptions"=dword:00000005
"AutoInstallMinorUpdates"=dword:00000000
"DetectionFrequency"=dword:0000000c
"DetectionFrequencyEnabled"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"NoAutoUpdate"=dword:00000000
"RebootRelaunchTimeout"=dword:0000000f
"RebootRelaunchTimeoutEnabled"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"UseWUServer"=dword:00000001


We see the following error in the Event log on the server-core when trying "wuauclt /detectnow"

Fault bucket , type 0
Event Name: WindowsUpdateFailure2
Response: Not available
Cab Id: 0

Is this is firewall issue?  We have full OS installs in the same subnet that ARE communicating with the WSUS server.

Can someone point me to documentation that will tell me how to configure the GPO's for our server-core servers so they at least check-in with our WSUS server so we can manually install the updates during planned maintenance windows?
Comment
Watch Question

Sean BravenerSenior Information Technology Consultant
CERTIFIED EXPERT
Awarded 2019
Distinguished Expert 2019

Commented:
here is an article that goes over the core GPO's to set up .
https://www.itprotoday.com/windows-78/group-policy-settings-wsus
CERTIFIED EXPERT

Commented:
You can start with configuring the actual group policy and getting it applied to your servers, rather than doing it in the registry. And running resulting set of policies and verifying that it's actually applied.
kevinhsiehNetwork Engineer
CERTIFIED EXPERT

Commented:
Yeah, I have no idea why you would configure WSUS on the client side and not with GPO. I manage all settings via GPO. No need to do anything to a domain member other than join it to domain and pmace in correct OU.

WSUS client settings work the same for core and full desktop experience.

Author

Commented:
Using the registry edits was not my first choice. I thought it was my only choice given these server-core servers are in a perimeter network.  However, I have two full-OS servers in the same network that are talking to my WSUS server.  

I've asked our network engineer to check the firewall rules to make sure there's not some sneaky little rule in there preventing communication b/t the WSUS server and the server-core servers.
CERTIFIED EXPERT

Commented:
Maybe you could turn off the firewall for a minute, just to try. I saw cases when the firewall was blocking things it said it did not block.
CERTIFIED EXPERT

Commented:
...also, you might run network packet sniffer.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Look at MMC, local policy the location for updates is the same and controls the registry entries.

Are these core members of the domain?
Do they a path to the wsus servers?

Author

Commented:
I can run secpol.msc on my server core installs.  "Class not registered" error.  

The only tips I'm seeing on the net show how to create a security template on a reference server and import it to the server-core server.  I can't find anything that shows how to view the local security policy on a server-core install.
CERTIFIED EXPERT

Commented:
Group policy overrides the local one.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Try running, mmc. Add/remove Snapins....
Group policy.....
See if that is an option.

Author

Commented:
We do have a "WSUS" GPO applied to the OU where these server-core servers are located.  I ran the GPMC Group Policy Results Wiz and confirmed the appropriate GPO settings are getting applied.  So forget what I said about importing registry settings.

I've deleted and confirmed the auto-recreation of SusClientId from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate.  

I've tried to kick off several "wuauclt /detectnow" commands, but the WSUS server has no status reports for either server core server (yet).

I'm left to hope for something magical to happen overnight at this point.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Double check hostname/port and whether the core servers have a path to it.
run get-windowsupdatelog
and look in the log file to see what is actually going on. whether the GPO is kicking in, URL, client target..
are other systems in this OU reporting?
look in the any catergory on the wsus in the event the GPO does not apply the client target or the one you think applies is superseded by another that sets a different clienttarget...
CERTIFIED EXPERT

Commented:
Given that the original error was "fault bucket", it almost certainly looks like a bug in the program, likely C++ runtime fault, rather than any misconfiguration. I.e. it's not that the code can't do what it wants because of some external reason - settings, policies, network traffic blocked, etc. which probably would be identified and logged in the event log, but crash of the program itself - division by zero, trying to use an uninitialized object, etc. Accordingly, you may want to look at any updates of the system or C++ runtime libraries.
Alternatively, maybe you can think about changing the circumstances and conditions encountered by the windows update code, whatever they may be, so the code goes on the different branch and does not hit the place with the crash. Since the code is a black box for you, it's pure experimentation of this and that, based mostly on your sixth sense. Things like assigning affinity of the process to just one processor, for example.

Author

Commented:
The "Get-WindowsUpdateLog" cmdlet does not appear to exist in my server 2012 server-core install.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
see if the log is readable
stop windows update service/BITS
rename c:\windwos\windowsupdate.log c:\windows\windowsupdate.log.bak
start the windows update services again
wuauclt /detectnow
then look through the most recent entries the .bak file will have too much old data to sift through.
more c:\wiondows\windowsupdate.log

something seems off either the ip is unreachable, the port has issues, client target will merely mean that these servers will be only seen under the all category for certain, and possibly in the unassigned grouping.
but if the IP is accessible and the port is correct they should checkin and report in.

If you have replicas in the environment, make sure the replica's are configured to roll up reports to the master/primary.
Much to my relief, it appears there was a specific firewall rule missing on our router that's now been added.  

Vadim's tip to run the resulting set of policies wizard in the GPMC to confirm the GPO side was working correctly helped me isolate the issue and ask our Network Engineer the right question.
CERTIFIED EXPERT

Commented:
It's nice to know that the issue is resolved (I assume). Still, I'd like to note that even if there was missing rule, and WSUS couldn't reach something it needed, the error in the event log should have adequately told "I can't reach XXX", rather than "fault bucket". "Fault" is basically an internal program error, when the program has encountered a situation the programmer did not think about.

Also, I'm wondering, if my tip to run RSoP helped to find the problem, why the comment with that tip is not at least part of the accepted solution?

Explore More ContentExplore courses, solutions, and other research materials related to this topic.