none
Allow Domain admins to install MS patches/updates

    Question

  • We have a server 2012R2 Domain with SCCM 2012R2 for updates. However I need to allow my domain admins to install updates and patches. As it stands we either HAVE to push or log in to the system(s) as THE local administrator. Simply being a domain admin or member of local admins group is insufficient. We get the message about "Windows Update can't check for updates because settings on this PC are controlled by your system administrator."

    So my question is what can I do to allow Domain admins to be able to install updates, but still keep this out of the hands of end users?  What GPO settings govern whom can and cannot run updates?


    # When I wrote this script only God and I knew what I was doing. # Now, only God Knows!

    Tuesday, May 17, 2016 9:22 PM

Answers

  • It's been some time since I played around with the combination of settings you've mentioned, but when I did that years ago, on Win7, I found it was possible to have ConfigMgr doing its thing and also to have the user able to bypass the SUP and scan against WU/MU.

    From memory, "windows couldn't check for updates", and, "some settings are managed by your administrator", are unrelated to each other, but, there may be an interaction of some kind.

    The ConfigMgr client settings related to WUAgent are deployed into the client machine by (LocalGP) registry settings if you enable SUM on your site. This is done by the ConfigMgr client agent populating the registry keys/values into the policies area, so WUAgent will scan/detect against the SUP (the WSUS controlled by ConfigMgr).

    The WUAgent/UI will show "some settings are managed by your administrator" if *any* of these policy keys are populated, regardless of the method used to populate those keys/values (Domain GP/Local GP/Registry).

    From memory, the Win7 WU/UI will show "check for updates" (which will initiate a detection against the configured WUServer), and it will also show "check online for updates" (which will bypass the WUServer and perform detectionagainst windowsupdate.com).
    This assumes that you aren't using "Remove access to use all WU features", and also assumes that the computer can successfully traverse your network/proxy/firewall to be able to connect to windowsupdate.com (which would be determined by your network egress configuration, i.e. unauthenticated or whatever)

    I also noticed that you have some settings listed, relating to scheduled updates for AU. That's typically not necessary/not recommended when you're using ConfigMgr SUM, since ConfigMgr SUM totally ignores those settings, but, WUAgent will attempt to honour those settings, which can lead to unexpected/undesirable behaviour at the client machine.
    Generally for a ConfigMgr SUM scenario, AU and AU-settings are not to be used. This allows ConfigMgr to control what happens and when it happens. (other than a user-manually-initiated action)

    The windowsupdate.log, and the ConfigMgr client agent logs, would most likely reveal what's going on (for the issue of "Windows couldn't check for updates" aspect)


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

    Friday, May 20, 2016 11:39 PM

All replies

  • Hi,

    Thanks for your post.

    In my opinion, this doesn't look like a problem with the account that you're using. It sounds like you have a Computer GPO configured to restrict Windows Update. You can verify this by running gpresult /H and viewing the output. It should be obvious where the offending GPO is.

    If this really is a group membership problem, you can view detailed group information for each account by logging in and running whoami /groups.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, May 18, 2016 2:26 AM
    Moderator
  • Hi,

    Thanks for your post.

    In my opinion, this doesn't look like a problem with the account that you're using. It sounds like you have a Computer GPO configured to restrict Windows Update. You can verify this by running gpresult /H and viewing the output. It should be obvious where the offending GPO is..

    I'm not discounting this possibility/probability, but I'm uncertain what I should be looking for. What hive(s) govern whom can run the updates?

    Thx,


    # When I wrote this script only God and I knew what I was doing. # Now, only God Knows!

    Wednesday, May 18, 2016 1:21 PM
  • So like Alvin was saying, if this is a GPO applied to the computers then it's going to block anyone who logs in from doing what you want. Below is a good article about gpresult:

    https://blog.thesysadmins.co.uk/group-policy-gpresult-examples.html


    If it answered your question, remember to “Mark as Answer”.

    If you found this post helpful, please “Vote as Helpful”.

    Postings are provided “AS IS” with no warranties, and confers no rights.

    Wednesday, May 18, 2016 7:30 PM
  • So, you have ConfigMgr. But you have the need to bypass ConfigMgr and check for updates directly at windowsupdate.com?
    But only in certain circumstances, for specific domain user accounts such as members of domain admins group?

    What is the OS of the machines where you need to do this task?

    How are you currently blocking/disabling WU? (presumably via a domain group policy, which is causing you this difficulty?)


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

    Wednesday, May 18, 2016 9:49 PM
  • So, you have ConfigMgr. But you have the need to bypass ConfigMgr and check for updates directly at windowsupdate.com?

    YES

    But only in certain circumstances, for specific domain user accounts such as members of domain admins group?

    YES

    What is the OS of the machines where you need to do this task?

    Windows 7, 8 & 8.1

    How are you currently blocking/disabling WU? (presumably via a domain group policy, which is causing you this difficulty?)

    A GPO is configured for updates to come from our SCCM server, but I see nothing regarding specific users rights.  In order to manually run updates, again, you need to be logged in as THE local admin, but Management wants me to ensure that it can be done by Domain Admins, & I'm not sure how.  I dont' know why either, but that's above my pay grade so to speak.

    gpresult doesn't yield the information I'm seeking.



    # When I wrote this script only God and I knew what I was doing. # Now, only God Knows!

    Thursday, May 19, 2016 2:47 PM
  • Can you give us the output of gpresult?

    If it answered your question, remember to “Mark as Answer”.

    If you found this post helpful, please “Vote as Helpful”.

    Postings are provided “AS IS” with no warranties, and confers no rights.

    Thursday, May 19, 2016 2:50 PM
  • This is the portion dealing with updates. I can't post the entire HTML as it contains data I'm unable to share.

    Windows Components/Windows Update hide
    Policy - Setting - Winning GPO
    Allow Automatic Updates immediate installation - Enabled - Computer TLS & Windows Update
    Allow signed updates from an intranet Microsoft update service location - Enabled - Computer TLS & Windows Update
    Automatic Updates detection frequency - Enabled - Computer TLS & Windows Update
    Check for updates at the following
    interval (hours):  1
     
    Policy - Setting - Winning GPO
    Configure Automatic Updates - Enabled - Computer TLS & Windows Update
    Configure automatic updating: 4 - Auto download and schedule the install
    The following settings are only required
    and applicable if 4 is selected.
    Scheduled install day:  0 - Every day
    Scheduled install time: 00:00
     
    Policy - Setting - Winning GPO
    Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box - Enabled - Computer TLS & Windows Update
    Enabling Windows Update Power Management to automatically wake up the system to install scheduled updates - Enabled - Computer TLS & Windows Update
    No auto-restart with logged on users for scheduled automatic updates installations - Enabled - Computer TLS & Windows Update
    Reschedule Automatic Updates scheduled installations - Disabled - Computer TLS & Windows Update
    Specify intranet Microsoft update service location - Enabled - Computer TLS & Windows Update
    Set the intranet update service for detecting updates: HTTP://SCCM01.My.Domain.com:80
    Set the intranet statistics server: HTTP://SCCM01.My.Domain.com:80
    (example: http://IntranetUpd01)
     
    Policy - Setting - Winning GPO
    Turn on recommended updates via Automatic Updates - Enabled - Computer TLS & Windows Update


    # When I wrote this script only God and I knew what I was doing. # Now, only God Knows!

    Thursday, May 19, 2016 3:40 PM
  • It's not too clear from your (understandably) redacted output, but do you have this enabled?

    Policy Setting Name  
    - Remove access to use all Windows Update features  

    Scope  
    - User  

    Policy Path  
    - Windows Components\Windows Update  

    Registry Information  
    - HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate!DisableWindowsUpdateAccess;
    - HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate!DisableWindowsUpdateAccessMode  

    Supported On  
    - At least Windows XP Professional Service Pack 1 or At least Windows 2000 Service Pack 3 through Windows 8.1 or Windows Server 2012 R2 with most current service pack  

    Help Text
    This setting allows you to remove access to Windows Update.
    If you enable this setting all Windows Update features are removed.
    This includes blocking access to the Windows Update Web site at http://windowsupdate.microsoft.com from the Windows Update hyperlink on the Start menu and also on the Tools menu in Internet Explorer.
    Windows automatic updating is also disabled; you will neither be notified about nor will you receive critical updates from Windows Update.
    This setting also prevents Device Manager from automatically installing driver updates from the Windows Update Web site.

    If enabled you can configure one of the following notification options:
    0 = Do not show any notifications
    This setting will remove all access to Windows Update features and no notifications will be shown.

    1 = Show restart required notifications
    This setting will show notifications about restarts that are required to complete an installation.
    On Windows 8 and Windows RT if this policy is Enabled then only notifications related to restarts and the inability to detect updates will be shown. The notification options are not supported. Notifications on the login screen will always show up.


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


    • Edited by DonPick Thursday, May 19, 2016 9:29 PM
    Thursday, May 19, 2016 9:18 PM
  • If you can't determine from a gpresult that "Remove access to use all Windows Update features" *is* in use, either from the DDP or any other GP linked to the domain root, check those.

    Or it could be another method being used to deploy the registry setting detailed in my above post.

    Another thing worth considering is if Loopback Processing is enabled - that will change the game a little bit.

    As an example, if you have "Remove access to use all Windows Update features" set to enabled in the DDP, that would apply to all domain user accounts, but would not apply to local user accounts.
    To be able to exempt *some* domain accounts from such a broad GP link, you'll need to consider where best to link the GP instead of at the domain root, or, consider if a GP-deny might work. Attempting to apply a GP-deny to the DA group might prove tricky.
    If you *do* have Loopback Processing enabled, things get trickier.

    Another method to implement, and allow some granular targeting, might be to use GPP-Registry instead of the classic templates method, because GPP-Registry allows you to use Item-Level-Targeting, where you could say "apply this unless the current user is a member of DAs"


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

    Thursday, May 19, 2016 9:38 PM
  • @Don

    No that setting "Remove access to use all Windows Update features" is not enabled.  It still appears for users in the control panel, & in some cases in the Start menu.  However it is effectively unusable.  The reason I say this is because when any network account is used to try to run updates the message appears instead stating that some settings are managed by the sys admin.  I'm paraphrasing a bit there.

    Someone correct me if I am wrong here, but it seems that when WSUS/SCCM is configured and thus an attendant GPO is set up, that the behavior I've described of network accounts being unable to run updates occurs as a side-effect, not that other accounts are actively being blocked, it just happens that way.   An analogous behavior (it seems to me) is how disabling the firewall service effectively firewalls a workstation off completely as if it is being attacked. 

    So I have to wonder if that is my answer.


    # When I wrote this script only God and I knew what I was doing. # Now, only God Knows!

    Friday, May 20, 2016 2:53 PM
  • It's been some time since I played around with the combination of settings you've mentioned, but when I did that years ago, on Win7, I found it was possible to have ConfigMgr doing its thing and also to have the user able to bypass the SUP and scan against WU/MU.

    From memory, "windows couldn't check for updates", and, "some settings are managed by your administrator", are unrelated to each other, but, there may be an interaction of some kind.

    The ConfigMgr client settings related to WUAgent are deployed into the client machine by (LocalGP) registry settings if you enable SUM on your site. This is done by the ConfigMgr client agent populating the registry keys/values into the policies area, so WUAgent will scan/detect against the SUP (the WSUS controlled by ConfigMgr).

    The WUAgent/UI will show "some settings are managed by your administrator" if *any* of these policy keys are populated, regardless of the method used to populate those keys/values (Domain GP/Local GP/Registry).

    From memory, the Win7 WU/UI will show "check for updates" (which will initiate a detection against the configured WUServer), and it will also show "check online for updates" (which will bypass the WUServer and perform detectionagainst windowsupdate.com).
    This assumes that you aren't using "Remove access to use all WU features", and also assumes that the computer can successfully traverse your network/proxy/firewall to be able to connect to windowsupdate.com (which would be determined by your network egress configuration, i.e. unauthenticated or whatever)

    I also noticed that you have some settings listed, relating to scheduled updates for AU. That's typically not necessary/not recommended when you're using ConfigMgr SUM, since ConfigMgr SUM totally ignores those settings, but, WUAgent will attempt to honour those settings, which can lead to unexpected/undesirable behaviour at the client machine.
    Generally for a ConfigMgr SUM scenario, AU and AU-settings are not to be used. This allows ConfigMgr to control what happens and when it happens. (other than a user-manually-initiated action)

    The windowsupdate.log, and the ConfigMgr client agent logs, would most likely reveal what's going on (for the issue of "Windows couldn't check for updates" aspect)


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

    Friday, May 20, 2016 11:39 PM
  • Hi,

    Just want to confirm the current situations.

    Please feel free to let us know if you need further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, May 23, 2016 6:45 AM
    Moderator
  • Don't know if this was ever resolved, but I've discovered that tweaking the following reg key works: (located just above the WindowsUpdate section)

    HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer!NoWindowsUpdate

    - modify value of this key to '0'

    - services.msc > Restart Windows Update Service

    Voila

    Tuesday, May 16, 2017 9:26 PM