Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
group policy query
- Thread starter paul8811
- Start date
ahalecitrix
MIS
To troubleshoot group policy you will want to start by watching how each policy is being applied. Settings in one policy can override settings in another policy.
Each policy is applied in sequence of priority, plus you can block overriding of settings in one policy by another policy.
So check all those settings and walk through how the policy is applied. In this case it should be fairly simple because you know the specific setting you want to see applied. So look at this setting, the order of the policies and how it is handled in each policy.
Also there is a file that can be helpful in troubleshooting Group Policy called userenv.log in %systemroot%\Debug\UserMode. Review this file and make sure each GP is getting processed.
Each policy is applied in sequence of priority, plus you can block overriding of settings in one policy by another policy.
So check all those settings and walk through how the policy is applied. In this case it should be fairly simple because you know the specific setting you want to see applied. So look at this setting, the order of the policies and how it is handled in each policy.
Also there is a file that can be helpful in troubleshooting Group Policy called userenv.log in %systemroot%\Debug\UserMode. Review this file and make sure each GP is getting processed.
Policies are applied to objects in active directory in this order... local policy (on the client itself), site policy, domain policy, top OU policy, sub OU policies. If you define a policy in any of the above, it will overwrite any previous definition. Here's a brief example... I set the log on locally policy in the domain policy to include the everyone group. Then I try to log on to a domain controller with a normal user in the everyone group and it didn't work. Why? Because the domain controller resides in the domain controller's OU and the policy for that OU also defines a log on locally policy and my user wasn't in any of the groups defined there. No matter who I said could log on locally in the domain policy, it all got overwritten by the domain controller OU policy. I went to a client machine and I could log on locally to it just fine because the computer object was located in another OU and its log on locally policy was undefined (log on locally is a computer policy so it applies to computer objects, not user objects).
So... to help you find the problem, 1. determine if it is a user policy or a computer policy to see which object to find in active directory. If a computer policy, find the computer name of the client, if a user policy, find the client's username. 2. Work your way backwards through the OU's, to the domain policy. Check to see if a policy is applied to the OU and if it defines a setting for the particular policy of interest. If yes, you have most likely found the one location where you need to make changes. If you get all the way back to the domain policy with not defined, then your domain policy is in question.
Are you using more than one policy in an OU or in the domain level? These apply differently and depend on the order they exist in the OU or domain level and have strange effects depending on if they deny or grant. The behavior goes from the first policy on the list to see if your group is there and if it grants or deny's. If it gets a setting, it can ignore the rest of the policies behind it. Try to avoid multiple policies and try to consolidate to one policy per OU or one domain policy. There are only a few exeptions where its prudent to do otherwise and it will speed up logons by keeping the number of policies to a minimum.
If all else fails, keep in mind that like your NTFS file system where each file and folder has permissions, Active Directory also has access control lists (ACL's) on all its objects and OU's. You will have to turn on the advanced view in active directory to see them. The security permissions required to make a policy applied are: the user or group must have read and apply policy permissions to the policy in question.
So... to help you find the problem, 1. determine if it is a user policy or a computer policy to see which object to find in active directory. If a computer policy, find the computer name of the client, if a user policy, find the client's username. 2. Work your way backwards through the OU's, to the domain policy. Check to see if a policy is applied to the OU and if it defines a setting for the particular policy of interest. If yes, you have most likely found the one location where you need to make changes. If you get all the way back to the domain policy with not defined, then your domain policy is in question.
Are you using more than one policy in an OU or in the domain level? These apply differently and depend on the order they exist in the OU or domain level and have strange effects depending on if they deny or grant. The behavior goes from the first policy on the list to see if your group is there and if it grants or deny's. If it gets a setting, it can ignore the rest of the policies behind it. Try to avoid multiple policies and try to consolidate to one policy per OU or one domain policy. There are only a few exeptions where its prudent to do otherwise and it will speed up logons by keeping the number of policies to a minimum.
If all else fails, keep in mind that like your NTFS file system where each file and folder has permissions, Active Directory also has access control lists (ACL's) on all its objects and OU's. You will have to turn on the advanced view in active directory to see them. The security permissions required to make a policy applied are: the user or group must have read and apply policy permissions to the policy in question.
- Thread starter
- #4
- Status
Similar threads
