I thought it might be useful to outline the approach that I take to designing group policy infrastructure in environments that I manage. Architecting group policy can be a daunting and time consuming task, so it’s good to know how it works before you start. All of what you’re about to read was gathered from Microsoft documentation, and should be accurate to the date of this writing. Everything you’re about to read has been compiled over the last 10 years from a combination of Microsoft best practices and real world experiences tweaking GPOs in production environments.
I use the terms functional and monolithic to describe the two possible approaches:
- Functional GPOs Contain one or more settings from a single policy area and often target a single function (e.g., Browser Security, Workstation Lock)
- Monolithic GPOs Contain a variety of settings from multiple policy areas (e.g., Administrative Templates, security, Group Policy preferences)
The majority of the corporate environments I’ve managed contain Functional GPOs when I start. Most environments should have a mix of both Monolithic and Functional GPOs. This is driven by factors such as the need for delegating certain GPOs to a particular business unit administrator, the desire to manage …