none
Group Policy Not Applying w/ WSUS Policy

    Question

  • Hello,

    I'm trying to find the root cause of a group policy issue I've been having for a while.

    I just started building a new WSUS environment from scratch - there were two other WSUS servers still running, both applied via either SCCM SUP or GPO, that hadn't been managed in several years.  I set up a new WSUS server, configured it, and started to use it...  We're not rolling out the updates to everyone yet (still in the testing phase), but we want all client computers in the domain to report to the new server.

    I created a group policy that points computers to my new WSUS server, and applied it to the root of my domain.  About 3300 computers are now reporting to the new WSUS server, and are unassigned.  This is exactly what I'm looking for.  No servers are pointing to my WSUS instance, because they're in a blocked inheritance OU, as I intended (we'll update them from another server at a later time).

    My issue is that there are about 100 computers that are still actively pointing to either of the old servers.  I deleted all computers from one of the WSUS servers, and moments later a new PC checked in.  I looked at where that PC was in AD, and confirmed that most of the other PCs in the OU are pointing to the new WSUS server.  It's not in any security group for security filtering.  I've confirmed that there are no other WSUS policies whatsoever in the domain.

    As I mentioned earlier, one of the WSUS servers is an SCCM 2007 SUP.  I've done, as far as I can tell, all the configuration possible to disable WSUS on that server.  In the Software Updates Client Agent Properties, I've unchecked "Enable software updates on clients."  In the Software Update Point Client Installation Properties, I've unchecked "Enable Software Update Point Client Installation."  In Software Update Point Component Properties, I've set it to "None."  I've cleared out all the computers from WSUS on BOTH of the old servers - the one with the SCCM SUP and the one that is a vanilla WSUS server.  The original GP that pointed computers to the second WSUS server (the vanilla one) has been deleted.

    Summary: All GPO's and SCCM settings have been removed/disabled, and it's been several months now, yet computers still point to the old WSUS server.  I've confirmed a dozen times over that the computers are in OU's that inherit the correct new GPO.  Any pointers?

    Wednesday, September 14, 2016 7:36 PM

Answers

  • For the ConfigMgr/SUP scenario, the settings within the client WUAgent are controlled by ConfigMgr client settings, and essentially the ConfigMgr client agent uses LocalGP/registry to poke the settings into play.
    When you disable the SU client settings in ConfigMgr, this will typically abandon the settings at the client, not remove them nor reset them, so you're left with those client machines configured to use the WSUS/SUP.
    It's not particularly graceful. This is the most likely cause of those clients continuing to contact the WSUS/SUP.
    If those ConfigMgr clients are no longer contacting ConfigMgr, they won't get the revised Client Settings, so they'll just keep using cached Client Settings.

    Check what's happening on one of those clients by looking into the windowsupdate.log, and check the WU registry keys.
    Check the ConfigMgr client agent logs on the client machine, those logs relating to WUAhandler is a good place to start:
    https://technet.microsoft.com/en-au/library/bb735866.aspx

    As dubsdj suggests, the regkeys to look into, on the client machine, are:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
    "WUServer"="http://mywsusServer:8530"
    "WUStatusServer"="http://mywsusServer:8530"


    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]

    The regkeys are what WUAgent will honour. ConfigMgr SU pokes the regkeys. The windowsupdate.log will show what keys/values were read at WUAgent startup, and WUAgent doesn't re-read those keys unless poked/restarted.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Thursday, September 15, 2016 10:32 AM
    • Marked as answer by Chad Quinlan Monday, September 26, 2016 6:16 PM
    Thursday, September 15, 2016 10:29 AM

All replies

  • Try putting this into a text file and saving it as a .vbs file. Then go to one of the prolematic clients and merge it with the registry. If the client then appears on your new WSUS server it would then at least point to the GPO as the problem. I don't know what port your WSUS server is on but you can change that in the text.

    You could also go to the key in the registry and see what it currently says..

    also you could create an OU further down and put those clients in it and enforce another GPO with the new WSUS settings and see if that helps.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
    "WUServer"="http://mywsusServer:8530"
    "WUStatusServer"="http://mywsusServer:8530"
    "ElevateNonAdmins"=dword:00000000

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
    "NoAutoUpdate"=dword:00000000
    "AUOptions"=dword:00000004
    "AutoInstallMinorUpdate"=dword:00000001
    "DetectionFrequencyEnabled"=dword:00000004
    "DetectionFrequency"=dword:00000004
    "NoAutoRebootWithLoggedOnUsers"=dword:00000001
    "RebootRelaunchTimeout"=dword:000005a0
    "RebootRelaunchTimeoutEnabled"=dword:00000001
    "RebootWarningTimeout"=dword:0000001e
    "RebootWarningTimeoutEnabled"=dword:00000001
    "RescheduleWaitTimeEnabled"=dword:00000001
    "RescheduleWaitTime"=dword:0000001e
    "ScheduledInstallDay"=dword:00000000
    "ScheduledInstallTime"=dword:00000010
    "UseWUServer"=dword:00000001



    Wednesday, September 14, 2016 7:55 PM
  • Create a new GPO for Windows Update and provide update path as new WSUS server then deploy to client.

    On client site run a gpupdate /force command and verify the registry value.


    Harvansh Singh

    Thursday, September 15, 2016 9:57 AM
  • For the ConfigMgr/SUP scenario, the settings within the client WUAgent are controlled by ConfigMgr client settings, and essentially the ConfigMgr client agent uses LocalGP/registry to poke the settings into play.
    When you disable the SU client settings in ConfigMgr, this will typically abandon the settings at the client, not remove them nor reset them, so you're left with those client machines configured to use the WSUS/SUP.
    It's not particularly graceful. This is the most likely cause of those clients continuing to contact the WSUS/SUP.
    If those ConfigMgr clients are no longer contacting ConfigMgr, they won't get the revised Client Settings, so they'll just keep using cached Client Settings.

    Check what's happening on one of those clients by looking into the windowsupdate.log, and check the WU registry keys.
    Check the ConfigMgr client agent logs on the client machine, those logs relating to WUAhandler is a good place to start:
    https://technet.microsoft.com/en-au/library/bb735866.aspx

    As dubsdj suggests, the regkeys to look into, on the client machine, are:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
    "WUServer"="http://mywsusServer:8530"
    "WUStatusServer"="http://mywsusServer:8530"


    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]

    The regkeys are what WUAgent will honour. ConfigMgr SU pokes the regkeys. The windowsupdate.log will show what keys/values were read at WUAgent startup, and WUAgent doesn't re-read those keys unless poked/restarted.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Thursday, September 15, 2016 10:32 AM
    • Marked as answer by Chad Quinlan Monday, September 26, 2016 6:16 PM
    Thursday, September 15, 2016 10:29 AM