So far in this series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, I’ve looked at forest and domain design and organizational unit (OU) structure. This post discusses some practices for the application of group policy objects (GPOs).

Group policy is a powerful feature of Active Directory but it’s important to consider management at the design stage as GPO management can become problematic if not carefully controlled.

At present, Microsoft Consulting Services is advising the use of:

• Separate OUs for user and computer settings – this makes GPO application easier to troubleshoot, especially if complex features such as loopback (see Microsoft knowledge base article 231287) are in use.
• Small GPOs with fewer settings where possible – whilst this will increase the overall number of GPOs to process, it aids management (easy to keep track of which GPO is doing what) and if a policy change is detected by a client at startup or during a scheduled refresh downloading a smaller GPO will assist with performance.

Advanced Group Policy Management (AGPM) (formerly DesktopStandard GPOVault) is a feature of the Microsoft Desktop Optimisation Pack (MDOP) – a software assurance benefit for Microsoft customers with particular licensing agreements. It allows the creation of a change control and reporting workflow so that GPOs are not created at will by administrators but are implemented in a controlled manner (i.e. check out policy, offline edit, check in policy, gain approval, release new policy). AGPM v3.0 (which is due for imminent release) will provide new features including increased granularity, a role-based administration model and improved reporting.

Windows Server 2008 also implements a new feature called Group Policy Preferences (formerly DesktopStandard PolicyMaker Standard Edition and PolicyMaker Share Manager). Group Policy Preferences is included within the Group Policy Management Console in Windows Server 2008 but requires client side extensions to be installed on downlevel clients (see Microsoft knowledge base article 943729. The technology allows the configuration of items that are not normally possible in Group Policy (e.g. granular targeting of printer assignment) to avoid the use of login scripts (which increase login times and create additional management overhead).

In the next post in this series, I’ll take a look at the design considerations for creation and use of security groups within AD.