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)

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?
–
PaulJul 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.
–
MDMarraJul 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
–
PaulJul 18 '12 at 19:28

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:

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.
–
PaulJul 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.
–
PaulJul 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.
–
MDMarraJul 18 '12 at 15:09