1

I have a new Windows 7 SP1 workstation. Installation of updates failed, in part I believe because of a misconfigured AD domain controller. So I went through a lot of trouble on the workstation to get the updates to work (installing patches and deleting the below-mentioned registry entry), and I also went to the group policy editor in my Domain Controller and told it to no longer control Windows Updates in my domain. But hours later the workstation still says "Some settings are managed by your system administrator" in the windows update settings control panel, and I notice that- after I had removed HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate using regedit, and performed the updates- it is now back with the old settings (I can see that WUServer has the old entry in it).

My domain controller is running on Windows Server 2003 :-( (old, I know). How do I tell it to stop trying to control updates in the domain?

I had gone to the Group Policy Object Editor in the domain controller and changed all settings in Computer Configuration->Administrative Templates->Windows Components->Windows Update so that the state for each setting is "Not Configured". I also went to User Configuration->Administrative Templates->Windows Components->Windows Updates and made sure that all of those states are "Not configured".

I went to the Workstation and ran gpupdate /force in a cmd window as Administrator. I also have waited some hours since making these changes.

Still, it has reared its ugly head. How can I tell the domain controller to leave my poor workstations alone?

Ultimately, I want to configure a new domain controller with Windows 2012 r2 but I need the updates running nowish, and I'm too green to feel comfortable slamming an upgraded DC into place so I can get a supported solution. I just need this strange little problem to go away for right now.

2
  • Check the following registry settings on the Windows 7 workstation: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate if there is an entry named "DisableWindowsUpdate" in this path, then change the its value of 1 to 0. Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\ExplorerNoWindowsUpdate (REG_DWORD) - change the value from 1 to 0. I don't know for sure if changing one of these values will fix the issue because, honestly, it is hit and miss – Art.Vandelay05 Aug 11 '16 at 14:32
  • In the past, I've had a workstation just not let go of the Domain level GPO giving it WSUS settings. I had to edit the registry key "disablewindowsupdate" from 1 to 0. – Art.Vandelay05 Aug 11 '16 at 14:38
2

I went to the Group Policy Object Editor and changed all settings in Computer Configuration->Administrative Templates->Windows Components->Windows Update so that the state for each setting is "Not Configured". I also went to User Configuration->Administrative Templates->Windows Components->Windows Updates and made sure that all of those states are "Not configured".

Do you mean that you did this on the local machine? If so, then you've modified the local Group Policy and not the domain Group Policy. You need to edit/modify the domain Group Policy by using the Group Policy Management Console on your Domain Controller.

9
  • No, it was on my domain controller. Updated my question. – Mike S Aug 11 '16 at 12:45
  • 1
    My apologies for being pedantic about this, I'm just trying to understand how you're doing this. When you say that you're using the Group Policy Object Editor on the Domain Controller do you mean that you're using GPEDIT.msc or are you using the GPMC (Group Policy Management Console.? They're not the same thing. – joeqwerty Aug 11 '16 at 15:04
  • @joeqwerty that is a great question to ask. I would only add, using Group Policy Object Editor (gpedit.msc) on the Domain Controller is only looking at the local Group Policies for the domain controller. Thus, only affecting the domain controller computer. To control all computers in the domain you need to use the Group Policy Management Console. – Art.Vandelay05 Aug 11 '16 at 15:27
  • No problem about pedanticness (obviously, I barely know what I'm doing). Regarding your question, I don't know for sure but I'll make a guess: GPEDIT.msc is run from a CMD window, and I didn't do that, but it does bring up a window that's identical to the one I've been using. It's entitled "Group Policy Object Editor". What I did do was open an app called "Group Policy Management" from the start menu. There, I drilled down into my Forest->Domains->(my domainname)->Default Domain Policy, then right-clicked, chose Edit, and it brought up the same window. – Mike S Aug 11 '16 at 15:30
  • @MikeS: OK. Understood. As Art stated, using GPEDIT.MSC would be editing and affecting the local Group Policy on the Domain Controller, which is not what you want. Using the GPMC is what you want. If you've used the GPMC and are seeing the same results I'd suggest looking at the Scope of Management of the GPO. Is the Security Filtering set to "Authenticated Users"? – joeqwerty Aug 11 '16 at 15:41
2

As it turns out, there are a number of items in the Group Policies that control your domain. For a neophyte like myself, the methods are myriad and daunting. Thanks to @joeqwerty, this is what I discovered:

  1. You can have local group policies and domain group policies. Make sure you are controlling the domain, by entering the Group Policy Editor from the Group Policy Management (GPM) window.
  2. Inside GPM, you drill down into your Forest, then Domain, then your specific domain name. There you will see a list of items. My settings were in more than one of the items, including the Default Domain Policy and the Small Business Server Update Services Client Computer Policy.
  3. Go to the workstation in question. We need to find which group policies are applied to my computer and account. See http://www.howtogeek.com/116184/how-to-see-which-group-policies-are-applied-to-your-pc-and-user-account/ . Specifically, from the Start Menu->Run box, enter rsop.msc
  4. There, you'll find all the policy settings that were applied to the machine. Drill through them to find the setting that seems to apply.
  5. Right click on it and chose "Properties". Click on the Precedence tab. It will show you the GPO Name that made this apply.
  6. Go back to the Domain Controller, and find that Policy. Go into it and shut it off.
  7. Wait a couple hours for the Group Policies to propagate, or run in an Administrator command prompt: gpupdate /force
  8. Rerun rsop.msc and review your settings.
4
  • Re: #1 - There is "local policy" and "group policy". There are not any "local group policies" – Clayton Aug 15 '16 at 15:01
  • @Craig620: I don't understand your comment. Of course there is a local group policy. The order of group policy processing is: LSDOU. Local, Site, Domain, Organizational Unit. – joeqwerty Aug 15 '16 at 16:03
  • Oops... never mind, my mistake. Thought we were making up new terms. But I see know that is an actual term. I find the term "local group policy" misleading. If its "local" there nothing "group" about it, it's a single individual instance. Whats "group" about that?! – Clayton Aug 15 '16 at 18:05
  • True enough. Microsoft goofed by calling it "Group" Policy. :) – joeqwerty Aug 15 '16 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.