Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

The concepts here are valid whether your Active Directory domains are Windows 2000 or Windows 2003. The point is that to make the most use of Group Policy, you'll need an Active Directory. But the best news is that the GPMC (once loaded on a Windows XP or Windows 2003 machine) can control either Windows 2000 or Windows 2003 domains.

The more you use and implement GPOs in your environment, the better you'll become at the basic use while at the same time avoiding pitfalls when it comes to using them. The following tips are scattered throughout the chapter, but are repeated and emphasized here for quick reference, to help you along your Group Policy journey:

GPOs don't "live" at the site, domain, or OU level. GPOs "live" in Active Directory and are represented in the swimming pool of the domain called the Group Policy Objects container. To use a GPO, you need to link a GPO to a level in Active Directory that you want to affect: a site, a domain, or an OU.

GPOs apply to Active Directory sites, domains, and OUs. Active Directory is a hierarchy, and Group Policy takes advantage of that hierarchy. There is one local GPO that can be set, which affects everyone who uses that machine. Then, Active Directory Group Policy Objects applysite, domain, and then OU. Active Directory GPOs "trump" any local policy settings if set within the Local Group Policy.

Avoid using the site level to implement GPOs. Users can roam from site to site. When they do, they can be confused by the settings changing around them. Use GPOs linked to the site only to set up special site-wide security settings, such as IPSec or the Internet Explorer Proxy. Use the domain or OU levels when creating GPOs whenever possible.

Implement common settings high in the hierarchy when possible. The higher up in the hierarchy GPOs are implemented, the more users they affect. You want common settings to be set once, affecting everyone, instead of having to create additional GPOs performing the same functions at other lower levels, which will just clutter your view of Active Directory with the multiple copies of the same policy setting.

Implement unique settings low in the hierarchy. If a specific collection of users is unique, try to round them up into an OU and then apply Group Policy to them. This is much better than applying the settings high in the hierarchy and using Group Policy filtering later.

Use more GPOs at any level to make things easier. When creating a new wish, isolate it by creating a new GPO. This will enable easy revocation by unlinking it should something go awry.

Strike a balance between having too many and too few GPOs. There is a middle ground between having one policy setting within a single GPO and having a bajillion policy settings contained within a single GPO. At the end of your design, the goal is to have meaningfully named GPOs that reflect the "wish" you want to accomplish. If you should choose to end that wish, you can easily disable or delete it.

As you go on your Group Policy journey Don't go at it alone. There are some nice third-party independent resources to help you on your way. I run www.GPanswers.com . My pal Dar ren Mar-Elia runs www.GPOguy.com . And, there's also Microsoft's independent Group Policy Wiki at http://grouppolicy.editme.com/ . All of these locations are here to help you get more advanced with Group Policy as you progress.