Group Policy Central

In my previous article In this article Best Practice:Active Directory Structure Guidelines – Part 1 I spoke about some of the guidelines I personally use when developing an Active Directory OU structure. In this next part I will discuss some guidelines I use when designing a Group Policy Object infrastructure.

Ideally you should make the the Active Directory OU and GPO design decision together to best ensure that you have the most efficient design possible. However if you have an existing OU structure designed a lot of these guidelines can still be applied to most existing environments.

As in Part 1 these are simply guidelines that I use and should not be taken as hard an fast rules. I quite often finding myself having to break these rules due to real world conflicts or just because one rule might conflict with the other rule. If you do find your self in a situation where you are not sure which path to take try to chose the option that will result in the least administrative effort in the long term.

Active Directory Group Policy Design Guidelines

Keep the GPO’s name consistent with the OU names

When naming the GPO try to keep the name of the policy the same as the concatenated name of all the OU’s to where the group policy object is applied. Having the fully concatenated name will make it intently know what that policy is applied when just looking at the GPO name. This is very handy to know when looking at a Group Policy Results report which only gives you the name of the GPO without the linked OU details.

Bad Example “Workstations”	Good Example “Sydney Workstations”

In keeping with having names consistent this also means you should adhere to the same naming conventions as mentioned in Part 1 with the OU’s (i.e. “Keep it short”, “Be Intuitive” & “Most to least signification from left to right”… So in saying that please read the next guideline…

References

TechNet: Establishing Group Policy Operational Guidelines

Define a meaningful naming convention for GPOs that clearly identifies the purpose of each GPO

Don’t use the work “POLICY”  or “GPO” in the GPO name

Nothing annoys me more to see a group policy called “Workstations Policy” or “Workstation GPO”…. I KNOW ITS A POLICY!!!! I AM LOOKING AT IT IN THE GROUP POLICY MANAGEMENT CONSOLE. Please drop the work “policy” or “GPO” from the name of the Group Policy object as you are simple adding more characters to what might already be a long name only for the sake of pointing out the obvious.

I also realise that the two GPO’s that come with AD are called “Default Domain Policy” and “Default Domain Controller Policy” which goes against this rule…

Remember at the start of part 1 how rules were meant to be broken…  So I do NOT recommend that you rename these polices there is just to much risk and confusion that doing this might cause. But this would have to be the only exception to this rule that I would be happy to let though…

Treat your terminal servers like workstations

Terminal Servers (now known as Remote Desktop Services) are essentially a multi-user workstation and as such should be treated more as a workstation than a server. Ideally you should configure you Terminal Server to be as close as possible as your workstations to provide your users with a consistent experience. The best way to make sure the configuration is consistent is to apply the same policy settings to the Terminal Serves as your workstations.

That being said don’t apply the same computer Group Policy Object to the Terminal Servers if for no other reason than it helps reduce the risk of making a change to a workstation that could affect the stability of the servers (e.g. Automatic Update reboot schedule). Therefore you will need to maintain some level of manually synchronisation between you default workstation and terminal server policy.

Unlike computer GPO’s it far more acceptable to apply the same user GPO’s to your users when logging on to the Terminal Server as the GPO are applied to the User Object rather than the computer account. Using the same policy means that any changes made to the user policies will automatically apply to terminal servers without the administrative overhead of making duplicate updates when there are policy changes. If you have any user configuration that you want to configure that is specific to the terminal servers (e.g. disable adding PST file) then you can override this policy using the Group Policy Loopback option on the computer GPO you apply to the Terminal Server. This is another  reason why you would want to have a separate computer GPO as it allow you to apply specific Terminal Server user settings via a loopback policy.

For more information on troubleshooting Loop back policies check out Loopback Policy Processing Debug Series  | CB5 Blog and Aaron Parker’s StealthPuppy blog.

Reference

TechNet: Using Loopback Processing to Configure User Settings

The User Group Policyloopback processing mode policy setting is an advanced option that is intended to keep the configuration of the computer the same regardless of who logs on. This option is appropriate in certain closely managed environments, such as servers, terminal servers, classrooms, public kiosks, and reception areas.

Listen

Multiple Page Post: Page 1 Page 2 Page 3 Page 4 Page 5 Page 6