none
Group policy not updating registry for WSUS settings RRS feed

  • Question

  • Hello

    A few months back we replaced our WSUS server, and updated the GPO to point our clients at the new server.
    Once I'd spotted some of them starting to appear in the WSUS console I assumed that everything was ok and moved on to the next problem.

    We've since spotted that a significant number of our machines - about half at a quick glance - haven't registered.
    If I look in the registry on one of the problem machines it still shows the old WSUS address.

    I've double and triple checked that they should be getting the "new" server address - group policy modelling wizard clearly shows that it should be there.

    I've also made a harmless change in that GPO (desktop wallpaper) and that *is* being applied which confirms that I'm getting and processing (at least some of) the GPO I expected.

    If I do a GPUpdate /force on some of the problem machines I get "The processing of Group Policy failed because of an internal system error" half a dozen times. In the Windows System log there are event ID 1125 from Group Policy , repeating the message above.

    If I look at the Group Policy Operations log I see Error 7016, but that just says "Completed Registry Extension Processing in xxx milliseconds" or similar.

    I have tried so far....
    Removing the PC from the domain and rejoining - no change.
    Moving it to an entirely different OU with a new GPO that's applied - no change, still have the incorrect registry settings for WSUS.
    Deleting secedit.sdb followed by gpupdate /force - no change.
    Manually editing the registry to update the WSUS settings - they come back after a reboot.

    New PCs are picking up the correct settings from the current GPO, but I clearly don't want to have to wipe and rebuild half of my machines to fix this.


    Any suggestions will be gratefully received.
    Any suggestions that fix it will be *very* gratefully received.

    Friday, October 11, 2013 11:44 AM

Answers

  • Ours is now fixed after half a dozen remote support sessions from Microsoft, and it's something I'd never have found myself.

    On a domain controller, open ADSIEdit then expand the default naming context - expand your domain - CN=System - CN=Policies and then you'll see each of your GPOs. You can look up the GUID in Group Policy Management to see which is which, but our problem was with the default domain policy.

    If you right click and select properties to go to the Attribute editor there's a couple of strings for gPCMachineExtensionNames and gPCUserExtensionNames which are a long list of GUIDs like this.

    [{3BAE7E51-E3F4-41D0-853D-9BB9FD47605F}][{0ACDD40C-75AC-47AB-BAA0-BF6DE7E7FE63}{2DA6AA7F-8C88-4194-A558-0D36E7FD3E64}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}{D02B1F72-3407-48AE-BA88-E8213C6761F1}][{7150F9BF-48AD-4DA4-A49C-29EF4A8369BA}{3BAE7E51-E3F4-41D0-853D-9BB9FD47605F}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{C6DC5466-785A-11D2-84D0-00C04FB169F7}{942A8E4F-A261-11D1-A760-00C04FB9603F}][{F3CCC681-B74C-4060-9F26-CD84525DCA2A}{0F3F3735-573D-9804-99E4-AB2A69BA5FD4}]

    Mixed in with that was one that was all zeros that apparently shouldn't have been there, so we removed it and that seems to have done the trick - we now have all of our machines registered with the new WSUS server.

    On one of the machines we did the testing with he also got us to delete the group policy history from Regedit (HKLM-Software-MS-Windows-Current Version-Group Policy-History, and the same in HKCU) but that doesn't seem to be necessary.

    Hopefully this will help someone else.

    • Proposed as answer by DonPick Monday, November 11, 2013 9:29 AM
    • Marked as answer by Justin GuModerator Monday, November 11, 2013 11:37 AM
    Monday, November 11, 2013 8:59 AM

All replies

  • check with RSOP / gpresult

    it sounds like you may have more than one GPO delivering the WSUS server settings, and you've only found one of them...


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Saturday, October 12, 2013 11:59 AM
  • Hello.

    Nope, there's only two or three GPOs that are processed by these client devices with just the one having WSUS settings.

    I've checked this manually and through the RSOP and modelling wizard, plus we have the errors in the event log when it's processed.

    Monday, October 14, 2013 9:09 AM
  • 1. I would start with basic connectivity test to new WSUS server, delete cache with ipconfig /flushdns and check if "bad" computers resolve the name correctly.

    2. From another discussion:

    Review the WindowsUpdate.log and see if they're trying to execute a call to the ReportingWebService, and if so, what error is befalling them. More significantly, are they actually detecting from the WSUS server at all. Registration with the server, and actually detecting/downloading/installing/reporting update activity are very separate things. Incidentally, the /reportnow won't be of much help unless there is actually some event to report to the WSUS server.

    3. For troubleshooting I use often

    http://technet.microsoft.com/en-us/magazine/gg153542.aspx

    Regards

    Milos

    Monday, October 14, 2013 9:25 AM
  • We are having the exact same problem. Our old WSUS server was on a 2003 server. We installed a new instance of WSUS on a 2012 host and updated our GPOs. We shutdown the old server.

    About 450 out of 700 clients have reported into the new server. It's been nearly 3 weeks.

    I have a Surface Pro and in the registry it shows the wrong WSUS server. I point it to the new one by manually altering the registry entry and it installs the updates. But after a reboot the register setting is reverted back to the old server. I have no idea why. We have no conflicting GPOs.

    The only difference is that we now use a DNS CNAME "WSUS" that is directed at the WSUS server.

    A gpupdate /force does not update the registry settings.

    The strange thing is more than half of the clients updated fine... I've been trying to figure it out for weeks.


    • Edited by C0rmang Thursday, October 17, 2013 12:28 PM
    Thursday, October 17, 2013 12:27 PM
  • Here's something else that is interesting. I was told to try to hit these URL's:

    http://wsus:8530/iuident.cab  (NOT working)

    http://wsus:8530/selfupdate/iuident.cab  (working)

    http://wsus:8530/simpleauthwebservice/simpleauth.asmx  (working)

    The first link returns ERROR 404. I tried on my old WSUS server and all three links work fine.

    Thursday, October 17, 2013 12:44 PM
  • Run a RSOP.MSC on the offending computers and see what policy they are pulling their settings from
    Thursday, October 17, 2013 1:40 PM
  • RSOP shows that it has used the "client PCs" GPO to set the WSUS server, but it's still the incorrect "old" address.

    I'm glad I'm not the old person that has this problem though.

    Friday, October 18, 2013 8:45 AM
  • Add another to the list of admins with this issue. I've done the following:

    - Changed the system policy to reflect the actual sus server.

    - Generated a report (gpresult) to see list of policies and the correct setting for the sus server is there

    - Looked (through a cmd prompt) at registry setting through the following command: reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate which shows old sus server setting.

    - Open regedit and change the HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer and HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer to current sus server setting (Windows update works!)

    - gpupdate /force changes settings back to old server

    Group Policy manager shows the settings that I think I have.  gpresult -h report.htm shows the actual settings in the registry.  No problems pinging the sus server or downloading (through IE) any files in the wsuscontent folder.  I'm thinking there is something wrong with being able to write to the registry of the machine under the system account.

    Thursday, October 31, 2013 10:57 PM
  • Add another to the list of admins with this issue. I've done the following:

    - Changed the system policy to reflect the actual sus server.

    - Generated a report (gpresult) to see list of policies and the correct setting for the sus server is there

    - Looked (through a cmd prompt) at registry setting through the following command: reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate which shows old sus server setting.

    - Open regedit and change the HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer and HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer to current sus server setting (Windows update works!)

    - gpupdate /force changes settings back to old server

    Group Policy manager shows the settings that I think I have.  gpresult -h report.htm shows the actual settings in the registry.  No problems pinging the sus server or downloading (through IE) any files in the wsuscontent folder.  I'm thinking there is something wrong with being able to write to the registry of the machine under the system account.


    if you manually change the setting, and then perform gpupdate /force, and the setting is reverted to the old setting, this suggests that GPO is not having any issues writing the registry setting, and, it confirms that GPO is delivering the setting. Somewhere, you have a GPO which is delivering that setting. You may need to use gpresult /z (to get super-verbose detail) to identify which GPO is doing this.

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, November 1, 2013 7:33 AM
  • Well, I've now got a case logged with MS TAC and after at least ten hours o a remote session with them we still haven't got to the bottom of it.


    They've agreed that it is definitely a fault and not me just being dumb and having an extra GPO that I'd forgotten about, but we can't fix it yet.

    Friday, November 1, 2013 9:06 AM
  • Thanks for answering Don.

    So gpresult /z tells me the same thing as that gpresult did.  I even tried gpresult with the /scope computer flag and the results were the same. The winning GPO is the same in each instance unfortunately.  When I [double / tripple / double triple] check the GPO, the value is the newer sus server.

    Friday, November 1, 2013 10:04 PM
  • Ours is now fixed after half a dozen remote support sessions from Microsoft, and it's something I'd never have found myself.

    On a domain controller, open ADSIEdit then expand the default naming context - expand your domain - CN=System - CN=Policies and then you'll see each of your GPOs. You can look up the GUID in Group Policy Management to see which is which, but our problem was with the default domain policy.

    If you right click and select properties to go to the Attribute editor there's a couple of strings for gPCMachineExtensionNames and gPCUserExtensionNames which are a long list of GUIDs like this.

    [{3BAE7E51-E3F4-41D0-853D-9BB9FD47605F}][{0ACDD40C-75AC-47AB-BAA0-BF6DE7E7FE63}{2DA6AA7F-8C88-4194-A558-0D36E7FD3E64}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}{D02B1F72-3407-48AE-BA88-E8213C6761F1}][{7150F9BF-48AD-4DA4-A49C-29EF4A8369BA}{3BAE7E51-E3F4-41D0-853D-9BB9FD47605F}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{C6DC5466-785A-11D2-84D0-00C04FB169F7}{942A8E4F-A261-11D1-A760-00C04FB9603F}][{F3CCC681-B74C-4060-9F26-CD84525DCA2A}{0F3F3735-573D-9804-99E4-AB2A69BA5FD4}]

    Mixed in with that was one that was all zeros that apparently shouldn't have been there, so we removed it and that seems to have done the trick - we now have all of our machines registered with the new WSUS server.

    On one of the machines we did the testing with he also got us to delete the group policy history from Regedit (HKLM-Software-MS-Windows-Current Version-Group Policy-History, and the same in HKCU) but that doesn't seem to be necessary.

    Hopefully this will help someone else.

    • Proposed as answer by DonPick Monday, November 11, 2013 9:29 AM
    • Marked as answer by Justin GuModerator Monday, November 11, 2013 11:37 AM
    Monday, November 11, 2013 8:59 AM
  • Hi,

    I’m glad to hear that you have resolved the issue and thanks for sharing your solution in the forum. This will help others who face the same scenario resolve the issue quickly. Your time and efforts are highly appreciated.

    Best regards,

    Justin Gu
    Monday, November 11, 2013 11:37 AM
    Moderator
  • "Mixed in with that was one that was all zeros that apparently shouldn't have been there, so we removed it..."

    Don, what exactly did you delete?  Was it the entire policy object in ADSI Edit or did you just clear the offending value?

    Monday, November 11, 2013 5:48 PM
  • "Mixed in with that was one that was all zeros that apparently shouldn't have been there, so we removed it..."

    Don, what exactly did you delete?  Was it the entire policy object in ADSI Edit or did you just clear the offending value?

    I didn't ultimately assist much with this, Vespa Alex logged a case and MS helped to resolve it, so I just proposed that as the answer.

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Monday, November 11, 2013 7:58 PM
  • We just removed the all-zero guid and left the rest in there.
    Monday, November 11, 2013 8:27 PM
  • Unfortunately it didn't work for me. Looks like I'll have to duplicate your steps with Microsoft.  Thanks for all the help though! 
    Monday, December 2, 2013 6:31 PM
  • Thanks!  This just solved my problem with WSUS as well.  GPO kept failing claiming that the path wasn't found for changing the reg key.  
    Thursday, February 5, 2015 8:42 PM