I have a lab(ish) environment where I have a single domain in a single forest. I have a Windows 7 image for the clients that was given to my by my organization (I didn't build it, not entirely sure who did) and I'm finding that there are a number of items that users (even admin users, even domain admin users) can't change in the Windows 7 environment, including but not limited to Trusted Sites in IE, Power Options (specifically, configuring when to lock the display), etc. Those are the main two that I want to affect, but am presented the message that "some settings are controlled by your administrator.." that I've seen about a million posts about.

What I've tried so far - Group Policies - Registry settings - Local Security Policies - Unlocking the 'hidden' admin & using them - Adding the users to the 'restricted group'

None of these seem to have an effect. The Group policies are applied, and GPResult show the as I would expect. As an example, I see a custom power profile that I applied in a GPO, and it even sets all the settings as I had it, except the 'disable display' setting, which is still set to what it was w/o my policy, and is still grayed out to prevent change.

Is there anything else I can look at to regain control over my client machines?

**** UPDATE **** I didn't call it out before explicitly, but I have moved the computer into a new OU that doesn't inherit the GPO, and per suggestion I removed the machine from the domain. The settings remained in place. When that failed, I re-enabled the local admin and logged on as same to see if that would solve the issue, it did not. I suspected from the beginning that whatever the issue is was done at the image level, since all the workstations are built off the same image and (as demonstrated) it seems to be a setting that's neither set by the domain nor ignorable via group policies (at least not by means that I'm aware of)

  • When you say 'hidden' admin, you mean the default Administrator account that's disabled in Windows7 by default, right? Jul 18 '12 at 15:13
  • Yes, that's what I mean. It was referred to as the 'hidden' admin in a article i read once and the term stuck in my brain.
    – Paul
    Jul 18 '12 at 16:13

If the GPOs for these settings aren't defined on your domain, chances are that they are set in the Local Policy for the image.

Run gpedit.msc from the local machine and examine the settings there, I bet you'll find what you're looking for.

  • damn, I was looking for it in the Local Security Policies UI itself, didn't think to use gpedit from the client. Thanks. I assume this also means there's no way to override it from the GPO if it's baked into the image's LSP's then, right?
    – Paul
    Jul 18 '12 at 19:06
  • GPO takes precedence over local policy. If you have a GPO configured that contradicts a local policy, the GPO will win. Keep in mind that "Not Configured" isn't considered a "configured" policy item. GPO applies in the following order: Local, Site, Domain, OU. The last GPO to apply wins. That means that local policy can be overridden by any other policy.
    – MDMarra
    Jul 18 '12 at 19:21
  • Ah, tx. Yeah, the GPO was set to 'not configured' and the LSP (once I was looking w/ the right tool) was set to Enabled on the policies in question. Thanks again
    – Paul
    Jul 18 '12 at 19:28

The settings you "can't change" that give you the some settings are controlled by your administrator message are settings that are being controlled by GPO.

"Correcting" this involves stopping the GPOs that force these settings down from applying to the machine in question. You mention that you have domain admin rights, so...

[If you haven't done it already, you'll want to use RSAT.]

What you probably should do is create a Testing OU in AD, using Active Directory Users and Computers (%SystemRoot%\system32\dsa.msc), and move this machine into it. Then, using Group Policy Management (%SystemRoot%\system32\gpmc.msc), you'd want to block inheritance to that OU. Since you just created it, there shouldn't be any GPOs linked in it directly. Run gpupdate /force from a command line to apply the new [lack of] GPOs, and reboot. Then you'll be free to change the settings you want, or test GPOs on the machine as you see fit (by creating and linking them in that OU you created).

Alternately, as a one-off approach, you could always remove the machine from the domain, which will stop the GPOs from being applied to it as well.

I suppose you could also just change/remove the GPOs in question, but that's a global change that would apply to more than just your machine, so be careful. Also a great way to piss off your AD admin(s), if they exist, or discover why should have a professional admin handling your AD environment if they don't exist.

EDIT: As pointed out by MDMarra, this won't magically reverse [most of] the settings applied by GPO, but will allow you to change them to what you want. Changing them to what you want, after the GPOs are no longer applying, is a matter of using GPEdit.msc to edit the local policies, or using regedit to remove the following keys, as suggested here:


[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects]


(Apologies, I got focused in on how to "regain control" from the domain, and didn't think about reversing the applied GPOs.)

  • No, as I said this is basically a lab environment right now. But as I mentioned, I looked at the GPResult for the machine/user in question and it's not being set by GPO, at least not according to the report.
    – Paul
    Jul 17 '12 at 23:24
  • OK, so I had previously tried all of the steps you suggested, except for removing the computer from the domain, and had no success. I guess I was vague in my initial post. In any event, I removed the computer from the domain as well and re-enabled the hidden administrator, logged in as that administrator, and I still get the 'some settings managed by your system administrator" message. Adding this info to the question.
    – Paul
    Jul 18 '12 at 15:00
  • 3
    Removing a computer from a domain won't magically undo GPO settings. They're mostly just registry keys that are set to a certain value. In almost all cases, they will remain set to this value when moved to a different OU or even removed from the domain unless the other OU's policy explicitly overrides these settings.
    – MDMarra
    Jul 18 '12 at 15:09
  • That's odd. Try the steps here: social.technet.microsoft.com/Forums/en-US/winserverGP/thread/… (And let me know if that works - I'll reference it in my answer if that's the case.) I'm also going to add a comment to your OP, since some of what you say is confusing me. Jul 18 '12 at 15:11
  • yeah, following that article leaves me with a laptop that won't boot by itself. Working on repairing the registry now.
    – Paul
    Jul 18 '12 at 16:26

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.