So back in the late nineties, with Microsoft releasing Windows 2000 server and Workstation, they’d got the news that administrators needed a way of keeping check of users’ computer settings and such. So they make Group Policy Objects and ADM templates available for deployment in Active Directory. A GPO contains Computer and User settings and are read from %Logonserver%\SysVol\%userdnsdomain%\Policies\, parsed and showed into the registry.
Computer settings go under HKEY_LOCAL_MACHINE\SOFTWARE\Policies and user settings reside in HKEY_CURRENT_USER\Software\Policies. You can apply GPO’s to particular Organizational Units in AD, decide what groups should have access to them and filter based on WMI. When you first create your AD-forest, each domain are asigned a couple of standard GPOs, “Default Domain Policy” and “Default Domain Controllers Policy”. They contain MS’ standard settings for computers and DC’s. The first are linked to the root of your domain, while the other is linked to the Domain Controllers OU.
The standard way MS have these settings exposed, it what you see above. And it works pretty well, what the radio buttons do is rather self-explanatory. As long as the policy is either “Not Configured” or “Disabled”, the sub-items are disabled and can’t be set. You even have a “Explain” tab to the right there, that goes into detail about what the ramifications of using this particular option is.
Now, enter the stinking pile of turd, that is IE-profiles.
Thing is, you see, GPO’s can be done as above – or they might be extended with com-objects, dlls or probably pretty much anything. The reason why this is a setup for epic failure is because this makes for controls that don’t behave as expected, or might very well leave behind junk in GPO’s – that basically can’t be deleted! Now, couple that with this: The Default Domain Policy also cannot be deleted!
Yay – you’ve got yourself a real super-ghost-gpo-setting.. To check for this überpolicy, look for the folder %Logonserver%\SysVol\%userdnsdomain%\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\USER\MICROSOFT\IEAK\.
Solution to this issue? I’ve looked quite a bit, and the closest I came was this tool made by ms called dcgpofix. Basically, it b0rkes the policy of choice (either one of them, or both), and creates a new with the defaults. Then it applies the security policies that youd normally have after a blank adprep. In other words: all security-settings you might have made on the server before initiating the domain will be lost. In most cases this won’t matter much, but be sure to write down any specifics you might have so you can manually apply them afterwards. Ms advices against using this tool, unless it’s the very last resort. I’ve used it on a domain that thankfully didn’t have many changes made to it other than the ghost-proxy-thingie – in Default Domain policy.
Things to consider:
Never ever, shall you make changes to “Default Domain Policy” nor “Default Domain Controllers Policy” beyond the policies that’s defined in them by default. They cannot be reset, undone or fixed in any practical way, should the setting have unexpected consequence. As stated above, GPO’s might be extended to do unexpected things when you least want it to. For instance; some of the IE settings, as well as the Wlan settings available in the standard policy sets, rely partially on external programs/tools to function. You might also experience that working on a GPO suddenly changes local settings – now wth? Again: be extremly careful when editing these gpo’s, leave the default ones alone unless you have to alter the already defined settings.