This gives very inconsistent application of policy. One fine day, you find that all policies are working fine, and when next day you introduce new policy, which has settings no way related to earlier policies and it goes on to break unrelated policy.
I will give you something to test...
parent OU policy contains : DENY 'Authenticated Users' permission on one of the registry key
(in my case USBSTOR service) & ADM template which tries to change a value inside that registry key (making value start = 4)
Child OU policy : is simply any setting from existing administrative templates (in my case WSUS policy)
You would expect processing of both polices by Registry CSE, but in this case child policy won't be processed as registry CSE will fail while changing value specified in parent OU policy, due to restrictive permission.
In another case it was mis-spelled file name, configured for file system security.
--
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Be the change you want to see in the World"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On 2/23/06, Darren Mar-Elia <[EMAIL PROTECTED]> wrote:
Well, it won't be the first time I've heard something about GP called "stupid" :).I suspect it depends upon how you think about this. Certain CSEs are more resilient than others. I honestly haven't come across your scenario but in a lot of cases, if a CSE fails to do something, GP processing will simply continue along. I will try to take a deeper look at this and see if I can understand why that is happening.One thing I usually recommend is to stay away from using registry and/or file security policy to set perms. First of all, I find it kind of a klunky way to manage permissions. Secondly, if you do a lot of it in policy, it can really slow down processing. I think its just better to manage security permissions on files and registry keys with a different, and more deterministic method.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kamlesh Parmar
Sent: Wednesday, February 22, 2006 11:48 PM
To: [email protected]
Subject: [ActiveDir] Stupid Group Policy CSE behaviorI had high hopes for group policy, but now it has started waning...Simply stated, what happens is ... you have different policies applying to machine.And say all policies contain different registry or security related settings.Now, when at workstation registry or security CSE tries to process these settings...It will just stop processing at first error it encountered and never process settings from remaining policies.so if registry CSE found that it has 10 values in registry to set and if it encountered error at 5th, it will never go ahead and process 6 to 10.here is my case:I had set deny permission on one registry key in one policy and I was trying to change that setting from another policy.One would guess that, 2nd policy would simply fail and CSE would continue processing other polices which are no way related to this setting. But it doesn't.I have seen this for Registry and Security CSE.Thanks for listening :-)
--Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Be the change you want to see in the World"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
