none
Server 2008 "Check for Updates" Grayed Out

    Question

  • I have a problem that I have been unable to resolve in spite of considerable research. We just created several new Windows 2008 Servers and added them to our domain. We have WSUS installed and our servers are set to obtain their updates from our WSUS server rather than from the Microsoft site through group policy settings. Group policy for the 2008 servers is set to automatically download updates but allow the logged on administrator to choose when and which ones to install. The updates automatically download to the servers and the administrator is notified that updates are available, however, Windows Update the Check for Updates link is grayed out and he is notified that "Some settings are managed by your system administrator." (Which is true because we set it through policy) The logged on administrator has no way of picking and choosing which updates to install. The option to Install Updates and Shut Down is displayed on logon though so we are able to apply updates that way. This is not, however, the way we want to install updates on our 2008 servers. We want the administrator to be able to see and select the updates he wishes to install. I have tried playing around with every policy setting I can think of and have come up blank. What has changed from 2003 to 2008 that would cause this and how do I resolve the issue?

    I have found references to the User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Remove links and access to Windows Update policy in Group Policy and have made sure that that setting is disabled for the Windows 2008 Servers, however, it makes no difference.

    Our Windows 2003 Servers work fine with the existing policy and no policy changes were made before installing the 2008 servers.

    Friday, December 11, 2009 6:04 PM

Answers

  • This question was actually asked and answered in this very forum - only 3 hours ago.

    Interestingly enough, the title of the thread is "Windows Updates not working on Server 2008" and likely appears only a few items below this one in the thread listing. 
    Quoting from "Windows Updates not working on Server 2008":

    What I really don't understand is why I am unable to change the update settings under control panel? They are greyed out. It is not being managed by GP, I have checked.

    The WSUS Group Policy does not grey out the Windows Update applet on Vista/Win7/Win2008 like it did with the Control Panel AU app in WinXP/Win2003. If this applet is greyed out it's more likely that access to the entire functionaliy is being blocked by the Disable access to Windows Update policy. See Configure Clients Using Group Policy in the WSUS Deployment Guide for more details on this policy setting.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, December 11, 2009 6:29 PM
    Moderator

All replies

  • This question was actually asked and answered in this very forum - only 3 hours ago.

    Interestingly enough, the title of the thread is "Windows Updates not working on Server 2008" and likely appears only a few items below this one in the thread listing. 
    Quoting from "Windows Updates not working on Server 2008":

    What I really don't understand is why I am unable to change the update settings under control panel? They are greyed out. It is not being managed by GP, I have checked.

    The WSUS Group Policy does not grey out the Windows Update applet on Vista/Win7/Win2008 like it did with the Control Panel AU app in WinXP/Win2003. If this applet is greyed out it's more likely that access to the entire functionaliy is being blocked by the Disable access to Windows Update policy. See Configure Clients Using Group Policy in the WSUS Deployment Guide for more details on this policy setting.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, December 11, 2009 6:29 PM
    Moderator
  • What exactly fixed this for you?
    Monday, March 29, 2010 3:58 PM
  • Hi - we are also having this problem. No matter what we set in local and domain group policy, on our 2008 R1 (and only these) servers the "Check for updates" option is greyed out. I can change all other WU settings, though.

    We used to have a WSUS policy applied to these servers, but I have removed and over-ridden it with another policy to unlock the settings from WSUS, and RSOP shows this is successful.

    Does anyone know of a way of forcing this option to be enabled?

    Cheers,

    Rob

    Tuesday, July 06, 2010 2:35 AM
  • What exactly fixed this for you?


    As noted in the marked answer -- almost certainly this is being caused by a policy setting being applied to the machine that is blocking access to the WUApp. There are three different policy settings that can be used to restrict functionality. They are documented in the WSUS Deployment Guide in the section Configure Clients Using Group Policy.

    Generally, in this scenario, the key is not confirming that the "WSUS" policy object is being applied, but identifying ALL GPOs that are being applied and verifying (by inspection of the GPO) that there are no settings in those GPOs that would impose this restriction.

    Tuesday, July 06, 2010 3:06 PM
    Moderator
  • but I have removed and over-ridden it with another policy to unlock the settings from WSUS, and RSOP shows this is successful.

    As noted, it is not so relevant that your selected policy is being applied, but rather what SETTINGS are being applied, or in this case, perhaps, what settings are NOT being applied.

    The WSUS GPOs are registry-based GPOs. Merely removing an active GPO and replacing it with another with values set to Not Configured, may not necessary revert certain registry settings imposed by the previous policy. If you want to verify that nothing is blocking access to the WUApp, then in your WSUS Policy you need to set all three policies to DISABLED to ensure this is being done.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, July 06, 2010 3:13 PM
    Moderator
  • Hi Lawrence, I have tried probably every single combination of disabled, not configured, etc, etc. I have even deleted the entries under HKLM\Software\Polices\... and HKLM\Software\Microsoft\... with no change.

    If I reapply policy, I can see the registry updates and I can see different values changed, deleted or created as I try different policy settings. I can also see various options and features in the GUI being disabled, set or enabled.

    However, I can see absolutely nothing that should disable the "check for updates" option.

    Also, this only happens on our 2008 (R1) systems. It is not happening on Windows 2003 or 2008 R2.

    There is also nothing set in local policy.

    At this point I am just giving up and these servers are going to stay unpatched.

    Wednesday, July 07, 2010 12:25 AM
  • At this point I am just giving up and these servers are going to stay unpatched.

    Well... shucks... that'll teach 'em!

    Okay.. so the process doesn't really take a lot of trial and error. A logical approach to the issue will usually identify the source very quickly.

    There are only three policies, three registry settings, and howevermany GPOs you actually have applied. So, first, check these three registry values and make sure they do not exist, or if they do, they are disabled (set to False):

    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate - DisableWindowsUpdateAccess
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer - NoWindowsUpdate
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate - DisableWindowsUpdateAccess

    If all three registry values are absent, then your problem is not policy-based; skip to the last paragraph.

    If one of those values does exist then you've not identified the correct policy object, or have looked in the wrong places of the policy object for the settings to disable.

    • The first is in Computer Configuration\System\Internet Communication Management\Internet Communication Settings and is called Turn off access to all Windows Update features.
    • The second is in User Configuration\Administrative Templates\Start Menu and Taskbar and is called Remove links and access to Windows Update.
    • The third is in User Configuration\Administrative Templates\Windows Components\Windows Update and is called Remove access to use all Windows Update features.

    If identifying the GPO with these settings is not easily done, then another option for troubleshooting purposes is to create a new OU where there are =NO= policies linked, and then you only need to troubleshoot the Default Domain Policy. Put ONE system in that OU to use as your test system. Do a GPUPDATE and see if the Default Domain Policy is the culprit. If not, then add one policy back, at a time, which can help to identify the policy that may be causing the issue.

    If the registry values are not present, then as noted this is not a policy-based issue. From the server's Administrator account on the Windows Server 2008 system go to Control Panel | Windows Update | Change Settings. In Change Settings observe whether the option Allow all users to install updates on this computer option is checked or unchecked. If it unchecked, then you've likely identified your cause.

     

     

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, July 07, 2010 12:40 PM
    Moderator
  • Hi Lawrence, thanks for trying to help me with this. I actually believe something is broken on these servers, it's not a major problem for us to not have them patched as they are not in production. Anyhow, none of the registry entries you mentioned exist. Logging on as the local administrator account, I don't have the Allow all users to install updates on this computer option, isn't that only on 2008 R2/Windows 7?

    Cheers,

    Rob

    Monday, July 12, 2010 8:39 PM
  • I actually believe something is broken on these servers,
    Much more likely that something has simply been misconfigured.
    Anyhow, none of the registry entries you mentioned exist.
    Good info.
    Logging on as the local administrator account, I don't have the Allow all users to install updates on this computer option, isn't that only on 2008 R2/Windows 7?

    No, it's not only on 7/R2 systems. It's been available on every system since Windows Vista was released.

    So, what options DO you have on the Change Settings dialog?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, July 13, 2010 1:50 PM
    Moderator
  • I had the same problem and managed to inadvertently resolve it.  None of Lawrence's scenarios applied (from the post on July 07, 2010 12:40 PM) and checking the Allow all users to install updates on this computer option didn't seem to make any difference, so b ecause I couldn't change it in the Windows Update dialog, I decided to tweak the registry settings.

    Under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, I thought that if I removed the schedule settings, it would go back to daily updates at 3am, which is what I wanted.  So I renamed a couple of keys:

            ScheduledInstallDay -> XX_ScheduledInstallDay
            ScheduledInstallTime -> XX_ScheduledInstallTime

    Then when I went back into the Windows Update dialog, it was displaying the current setting for updates as disabled (i.e. "Never check for updates") but now letting me edit the settings at least.

    Don't know if it was just a fluke amongst the many other things I've tried but it might be worth looking at.

    Dave.

    • Proposed as answer by RevHead Wednesday, July 09, 2014 8:07 PM
    Saturday, July 17, 2010 4:00 PM
  • Hi, Dave, had a look but that's not the cause for me but thanks for letting me know.

    Cheers,

    Rob

    • Proposed as answer by RevHead Wednesday, July 09, 2014 8:07 PM
    • Unproposed as answer by RevHead Wednesday, July 09, 2014 8:07 PM
    Tuesday, July 27, 2010 9:55 PM
  • At this point I am just giving up and these servers are going to stay unpatched.

    Well... shucks... that'll teach 'em!

    Okay.. so the process doesn't really take a lot of trial and error. A logical approach to the issue will usually identify the source very quickly.

    There are only three policies, three registry settings, and howevermany GPOs you actually have applied. So, first, check these three registry values and make sure they do not exist, or if they do, they are disabled (set to False):

    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate - DisableWindowsUpdateAccess
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer - NoWindowsUpdate
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate - DisableWindowsUpdateAccess

    If all three registry values are absent, then your problem is not policy-based; skip to the last paragraph.

    If one of those values does exist then you've not identified the correct policy object, or have looked in the wrong places of the policy object for the settings to disable.

    • The first is in Computer Configuration\System\Internet Communication Management\Internet Communication Settings and is called Turn off access to all Windows Update features.
    • The second is in User Configuration\Administrative Templates\Start Menu and Taskbar and is called Remove links and access to Windows Update.
    • The third is in User Configuration\Administrative Templates\Windows Components\Windows Update and is called Remove access to use all Windows Update features.

    If identifying the GPO with these settings is not easily done, then another option for troubleshooting purposes is to create a new OU where there are =NO= policies linked, and then you only need to troubleshoot the Default Domain Policy. Put ONE system in that OU to use as your test system. Do a GPUPDATE and see if the Default Domain Policy is the culprit. If not, then add one policy back, at a time, which can help to identify the policy that may be causing the issue.

    If the registry values are not present, then as noted this is not a policy-based issue. From the server's Administrator account on the Windows Server 2008 system go to Control Panel | Windows Update | Change Settings. In Change Settings observe whether the option Allow all users to install updates on this computer option is checked or unchecked. If it unchecked, then you've likely identified your cause.

    I have to say that I have been racking my brain with this and need to just say thank you. I had disabled all GPO's that would cause me to not get updates to my SBS 2011 server. It was deploying updates to all the workstations and other servers but for some reason it would not work on the SBS Server. I deleted HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer - NoWindowsUpdate and bang it started to work.

    • Edited by Lawrence GarvinMVP, Moderator Sunday, December 01, 2013 8:00 PM Moved new response outside of blockquote and removed my sig from blockquote.
    Friday, November 29, 2013 11:25 PM
  • Thank you Dave. That worked for me. 
    Wednesday, July 09, 2014 8:08 PM
  • Thank you Dave. That worked for me. 

    Most interesting, considering that what Dave did should have had ZERO impact on the actual functioning of that client.

    Changing registry values without restarting the Windows Update service does nothing.

    Changing the two specified registry values will have minimal functional impact on the client anyway. If AUOption<>'4', then those two values are ignored. If AUOption='4', then missing values will simply be treated as defaults (install at 3am anyday). Dave was correct about that assumption; however, there's no logical reason why changing those two registry values would have had any impact on the ability to use the WUApp to configure Windows Updates.

    In fact, if the client IS configured to use a WSUS server, you cannot configure the client from the WUApp, so anytime you CAN configure the client via the WUApp is prima facie evidence that the client is not configured to use a WSUS server.

    Whatever else was blocking access to the ability to run an update scan from the WUApp had nothing to do with the two registry values changed.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Proposed as answer by ryan.nehring Thursday, September 04, 2014 8:22 PM
    • Unproposed as answer by ryan.nehring Thursday, September 04, 2014 8:22 PM
    Thursday, July 10, 2014 10:57 PM
    Moderator
  • To answer the OP, the GP change must be made on the sbs machine. Start>Administrative Tools>Group Policy Management. Expand domains and double click your local domain listed under the tree. Click "Default Domain Policy" then choose the settings tab at the top. From here: Computer Configuration>Policies>Administrative Templates>Windows Components/Windows Updates. Right click and edit "Configure Automatic Updates" select setting 5. Hit the windows key+R and type in gpupdate /force. Do this for all machines on the domain for immediate effect or wait for changes to take effect on their own.

    I've been trying to figure this one out for some time too and I haven't seen this solution listed anywhere or google didn't find it at least. What eventually lead me to the find was running rsop.msc then that allowed me to see which policy was messing with me.

    Hope this helps.

    Thursday, September 04, 2014 8:35 PM
  • To answer the OP, the GP change must be made on the sbs machine. Start>Administrative Tools>Group Policy Management. Expand domains and double click your local domain listed under the tree. Click "Default Domain Policy" then choose the settings tab at the top. From here: Computer Configuration>Policies>Administrative Templates>Windows Components/Windows Updates. Right click and edit "Configure Automatic Updates" select setting 5. Hit the windows key+R and type in gpupdate /force. Do this for all machines on the domain for immediate effect or wait for changes to take effect on their own.

    I'm confused as to what this has to do with the conversation (three months old and dead as it is anyway)...

    I see nothing in this thread that mentions SBS.

    Even if it did, modifying a Group Policy does NOT *require* that it be done from the SBS Server. Just like any other AD environment, it can be done from any domain-member system running the Group Policy Management Console.

    Third, WSUS policies (or any other user-defined policies, for that matter) should *never* be configured in the Default Domain Policy!

    On top of that... why would you suggest setting AUOption='5' in a GPO??? That's about as anachronisitic as a GPO can get, methinks.

    I've been trying to figure this one out for some time too and I haven't seen this solution listed anywhere or google didn't find it at least.

    You didn't find it anywhere because it's flat-out wrong.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, September 05, 2014 3:07 AM
    Moderator
  • To answer the OP, the GP change must be made on the sbs machine. Start>Administrative Tools>Group Policy Management. Expand domains and double click your local domain listed under the tree. Click "Default Domain Policy" then choose the settings tab at the top. From here: Computer Configuration>Policies>Administrative Templates>Windows Components/Windows Updates. Right click and edit "Configure Automatic Updates" select setting 5. Hit the windows key+R and type in gpupdate /force. Do this for all machines on the domain for immediate effect or wait for changes to take effect on their own.

    I'm confused as to what this has to do with the conversation (three months old and dead as it is anyway)...

    I see nothing in this thread that mentions SBS.

    Even if it did, modifying a Group Policy does NOT *require* that it be done from the SBS Server. Just like any other AD environment, it can be done from any domain-member system running the Group Policy Management Console.

    Third, WSUS policies (or any other user-defined policies, for that matter) should *never* be configured in the Default Domain Policy!

    On top of that... why would you suggest setting AUOption='5' in a GPO??? That's about as anachronisitic as a GPO can get, methinks.

    I've been trying to figure this one out for some time too and I haven't seen this solution listed anywhere or google didn't find it at least.

    You didn't find it anywhere because it's flat-out wrong.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Sorry, in our environment our SBS server is the DC so I guess I assumed when he said they added 2008 servers to their domain, perhaps it was similar to what I'm dealing with. I'm not sure how our servers got configured from the Default Domain Policy but someone had it set to reboot at 16:00. That's 4:00pm in the afternoon during work hours. Default Domain Policy was the root of the problem here. Lastly, choosing option 5 removes the greyed out options, which is what the OP had in his topic. Thanks for your thoughts, Lawrence.

    Friday, September 05, 2014 12:47 PM