I don't think, there is a problem with processing precedence.
I have problem that, there is no easy way to revert to stage where that setting was not configured at all.
Did u enforce the domain policy and check the settings in "Internet Options"
Problem is when you enforce it, domain policy will take precedence, and it assumes that in domain policy the proxy settings are disabled and it overrides settings in OU policy.
Problem is when you enforce it, domain policy will take precedence, and it assumes that in domain policy the proxy settings are disabled and it overrides settings in OU policy.
You don't see proxy settings in GP editor or in GPMC, but if you go to sysvol and open the install.ins file in USER\Microsoft\IEAK folder, you will see that Proxy_Enable=0
is set, and which creates the problem when domain level or any higher level policy is enforced.
Anyway, I have edited the policy in sysvol and up the version in gpt.ini and DS.
Just thought, it would be helpful to someone.
On 11/3/05, Darren Mar-Elia <[EMAIL PROTECTED]> wrote:
Ok, I tested this myself. I think what is happening is that RSOP is reporting incorrectly, rather than there being something broken in policy processing precedence. For example, I set up the scenario you described below and ran GP Results from GPMC on the user logging into my test client and it showed, as you indicated, that the winning policy was the domain linked one. However, at the client, the user was receiving the OU policy as expected. Also, when I run rsop.msc from the client, it reports the correct winning GPO. So it looks like a RSOP bug.In terms of directly editing SYSVOL, I don't typically recommend it, but if you do that, and modify the gpt.ini file, you also need to update the versionNumber attribute on the GPC object in AD to have the same version number. Note that as of XP and 2003, mismatched version numbers no longer prevent the GPO from being processed, as they did in Win2K.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Kamlesh Parmar
Sent: Wednesday, November 02, 2005 12:14 PM
To: [email protected]
Subject: Re: [ActiveDir] GP version mismatch between DS & SYSVOL
Darren,
Try this,
create one GPO at domain level, and one at OU level,
configure the proxy settings at both levels.
now, according to GPO processing rules, OU level GPO should win.
Now, go ahead remove the proxy settings from domain level GPO.
In this case also OU level GPO should win.
But you will notice that domain level GPO is still mentioned as processed for proxy settings. (in the precedence tab)
So, if I happen to enforce the GPO at domain level, even though I have removed proxy settings, it takes precedence and nullifies the proxy settings at OU level.
So, I want to reach that stage where it was never configured at domain level GPO, so that I can enforce GPO for other settings.
I hope it is clear,
So one way to achieve is, create new GPO and copy settings other than proxy from old GPO and enforce this new GPO. Other is, edit at sysvol level and increment version in gpt.ini.
I know, masters will recommend creating new GPO and copying settings[1], but I thought lets try something like this.[2]
[1] Copying GPO using GPMC interface doesn't help as it creates the same settings, so can't revert back to stage where proxy settings were never configured.
[2] I have read a KB article in which if you happen to lock yourself out of DC, due to mis-configured security options in default DC policy or something, you can edit the security INF file in sysvol and increment the version in gpt.ini to get back to functional state.
--
Kamlesh
On 11/3/05, Darren Mar-Elia <[EMAIL PROTECTED] > wrote:Kamlesh-I'm not sure I understand what you're saying about "Not Configured". If I check "Automatically Detect configuration settings" in IE Maintenance policy, then that box is checked for all users that process the policy. If you uncheck that box, the box is unchecked for the user the next time they process the policy. What behavior are you trying to achieve?Darren
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Kamlesh Parmar
Sent: Wednesday, November 02, 2005 9:33 AM
To: [email protected]
Subject: [ActiveDir] GP version mismatch between DS & SYSVOL
You know, there are some settings like, "automatically detect configuration settings" under IE maintenance and some certificate enrollment settings etc.
Which once configured, can't be made "not - configured" as you can do with other settings.
This values are either disable or enable, there is no option like "not configured"
I have two or three such policies, and I want to get rid of these settings, without recreating the GPO.
so I thought I would go directly in SYSVOL folder of this policies and delete the appropriate settings and UP the version number in gpt.ini so that it replicates.
But, since I have not used standard group policy editor, the version in Active Directory remains old.
Now it gives error in monitoring tools saying version mismatch between DS & SYSVOL.
So,
1) Is there better way to handle these sticky settings? other than recreating GPO.
2) Can I change the version in DS using adsiedit.msc to reflect the same as SYSVOL? will it have any effect on GP application?
--
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
