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

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.

kevinhsieh

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.

ASKER

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.

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.

...also, you might run network packet sniffer.

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?

ASKER

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.

Group policy overrides the local one.

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

ASKER

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.

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...

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.

ASKER

The "Get-WindowsUpdateLog" cmdlet does not appear to exist in my server 2012 server-core install.

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.

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial