Unable to run Windows Update


  • Greetings,

    We recently let our MSP go and brought the IT in house. However we are having a really strange issue. Since the MSP pulled out and removed their software and GPs that pushed their software out to our PCs we have been unable to manually run Windows Update. When you launch WU it give a message "Some Settings are managed by your system administrator". I have gone thru the GPOs and cannot find that any of them have any entries pertaining to Update services. In each GPO the Windows updates are set to "not  defined". Its really driving us crazy. Any ideas or suggestions?

    Thursday, March 09, 2017 4:24 PM

All replies

  • Hi,
    Please check the account which you are using to launch WU if it has enough permission to do that.
    In addition, rather than GPOs, please check if any WU policy settings are configured in the local group policy editor.
    And referring to the following article, you could have a try:
    “delete added subkey under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU to leave only the "default" subkey”
    please make sure that you back up the registry before you modify it and you know how to restore the registry if a problem occurs.
    Best regards,

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, March 10, 2017 2:58 AM
  • Hi There. I tried the registry change you suggested and it made no difference. Also the issue remains no matter who is signed into the PC and no matter what permissions they have. Its very frustrating.
    Friday, March 10, 2017 9:20 PM
  • any updates on this, same problem
    Friday, March 10, 2017 9:23 PM
  • "some settings are managed by your system administrator" is displayed in the UI, when a Group Policy (either Domain or Local), or, the equivalent registry settings are present.

    You can use the command: gpresult /h somefilename.htm
    on a client workstation, to generate an RSoP report, which you can open with IE to view all GP settings effective on the client workstation.

    This is a slightly-prettier way of checking, a little easier than wandering through the registry maze.

    But ultimately, all most Group Polices do, is to implant registry keys/values.

    As Wendy suggests, the registry keys/values @ HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\
    are the main keys/values of interest for the AutomaticUpdates feature of Windows.

    Note that if you do make a change to those keys/values, the change is not effective until the wuauserv service is restarted (and the easiest way to do that is to restart the PC)

    You can check into the c:\windows\windowsupdate.log file, to see what the WUAgent is doing and look for the SERVICE STARTUP section of the logfile, where it will show the service configuration settings read from registry at startup.

    Generally, for machine-wide/system-level settings such as WU, the logged-on user is irrelevant - such machine-wide settings will be applicable to all/any users (that's the intent of a machine-wide setting)

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

    Friday, March 10, 2017 11:17 PM
  • Thanks for info Don. I ran the gpresult and there isnt a mention at all of Windows Update. One way or another. Nor are the registry settings mentioned activated. In the WindowsUpdate.log the only entry that seems to pertain is "Windows Update is disabled by policy for user"
    Thursday, March 16, 2017 3:49 PM
  • that's odd.

    if it's not a domain GPO, and it's not a Local GPO and it's not a regkey implant, then this is something I've never encountered in nearly 20years..

    it's possible that there is a stale/stuck registry.pol or mandatory profile or some other script/agent fiddling with things when you're not expecting it, or, your previous service provider has done something funky and there are remnants or artefacts from that?

    do you have a test machine which you can use to disjoin from domain (make sure you establish a local admin account prior to disjoin), to see if it's some domain-based policy or script as cause?

    any agent/services running that are non-MSFT things?

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

    Thursday, March 16, 2017 8:18 PM
  • Hi,

    Just checking in to see if the information provided was helpful. And if the replies as above are helpful, we would appreciate you to mark them as answers, please let us know if you would like further assistance.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, March 21, 2017 9:38 AM