Section 6.5. Deployment Considerations

6.5. Deployment Considerations

You've learned a lot in this chapter about GP and how it works. Along with the exact mechanisms behind GP's magic, there is also an art to properly deploying it. You must account for several issues when using GP. In this section, I'll take a look at some common issues, and I'll offer suggestions about how best to deploy (in general terms) GPs in your organization.

First, you should keep the Default Domain Policy GPO clear of special exceptions. Remember that this policy is meant only for domain-wide, all-computer settings, and is not meant as a launching point for myriad policies of your own. Don't apply different settings to this policy and expect to use the inheritance blocking and security group filtering capabilities to limit the scope of a setting located here. It's a recipe for a troubleshooting nightmare. Instead, create individual GPOs applied to different containers, where your changes, even if blocked by certain properties of the GPOs, aren't as widespread and sweeping.

Also, try to favor creating several smaller GPOs rather than fewer large GPOs. Although the processing time will suffer, it won't suffer much; the benefit is that a GPO's scope is much easier to identify on certain computers when you have smaller GPOs affecting only a few objects.

Construct a naming structure for your GPOs that is clear and descriptive. Hardly anything is worse, especially during GP troubleshooting, than seeing a GPO called "Office" and not knowing whether it defines who receives Microsoft Office through IntelliMirror, who doesn't get Office, or whether the GPO contains security settings for the office worker computers and not for the factory floor. Of course, you want to document this in a safe place, too. Memories tend to fail us at the most inopportune times.

Design your directory structure intelligently. Make separate OUs to contain objects performing similar roles, and make different OUs for different types of users on your network. Separate client workstations from server computers, and differentiate normal users from power users and administrators through a logical, flowing directory. This makes it much easier to deploy GPOs effectively without a lot of inheritance "black magic." By the same token, however, make sure you have room for exceptions to this schemesome clients might be servers and some servers might be clients, so it's best to have a plan for these oddballs. And along the same lines, try to create a shallow Active Directory structure to eliminate many levels of policies being applied to nested OUs.

Also, when looking at your directory, assess how you can use groups placed in different OUs to further define GPO scope through the security group filtering function. Placing groups in certain OUs can more clearly identify their function and members and can cut down on processing and application time because policy scope is more refined and less all-inclusive. At the same time, look at how WMI filtering can be used within the existing group and OU structure, and make modifications to streamline the effectiveness of RSoP and policy application functions.

Oh, and don't forget to document your GPOs and their links. What more needs to be said about that?