Group Policy I hear you mutter? It’s nothing new on the scene or ground breaking, it’s been around for years, everyone has heard of it and used the technology. It’s extremely powerful and efficient at what it does though – if designed, implemented and managed correctly, like all technology.
Anyway, having recently worked on Group Policy and AD for a VDI project, I thought it would be a good idea to consolidate some resources and information into one page to serve up as a ‘refresh’ if required. These resources have been out there for a while, and I’m sure many people have cast their eyes over these in the past. The primary point of the post though, is to pull information together from these resources in one place for future reference re Group Policy or Active Directory , in relation to design, best practice and optimisation.
Top of the charts in my opinion are two excellent sessions from MS TechED (North America) by Darren Mar-Elia
- Best Practices for Designing & Consolidating for Performance and Security
- Optimising Group Policy in VDI Environments
In terms of initial assessment and where to start overall, let’s begin from the top:-
**Information below has been consolidated from various external resources (links below)**
Active Directory Structure
Understand requirements of environment
- How is the company structured?
- Where are the physical sites?
- Who support the organisation?
- What are the support boundaries (e.g. Location and/or Workstations and/or Server/
- What are the computer types
- Highly Secured
- Standard SOE
- Process Control/Automation
- Server Roles (e.g. Exchange, SQL or File Server)
- Network Topology
- Bandwidth / Latency
- Who will be responsible for Group Policy changes?
- What are the security requirements (password policy, auditing etc.)?
- What is the change management process?
- What are the auditing requirements for Group Policy?
Considerations for choosing an OU structure design (in no particular order):
- Delegation of security
- Application of Group Policy
- Likeliness of divesting or acquiring other business
- Geographical Locations – Global Region, Country, Weather Region, Closest International Airport, State, City, Suburb, Building, Floor
- Risk Mitigation – You might not want to have 1 OU with 10,000 computers in it even if they are all configured the same as this makes it very easy to break all your computers with one easy mistake. In these extreme cases you might want to setup sub-OU’s only with duplicate polices applied to them but this would only be done in extreme situations.
Design Best Practices
- As a general rule you should only start creating another OU level if you are actually going to do something to that OU (e.g. delegate security or apply a group policy).
- Separate OUs for User and Computer objects
- You would be fairly pushed to require an OU structure more than 4 level deep so ask yourself this question if you start to contemplate a 5+ level structure
- Keep the GPO’s name consistent with the OU names
- Ensure each GPO is enabled\disabled for Computer\User settings (minimal gain though)
- Group similar settings into one GPO
- Monolithic and Functional GPOs – 80\20 rule
- Monolithic contains settings from many different areas. 80%, more static
- Functional are just specific for 1-2 things – 20%, more updates\dynamic
- Security polices for entire domain (easier to delegate)
- More frequent GPO updates, as this won’t impact other CSE
- Dynamic environments with lots of changes, functional (specific GPOs for 1-2) may make more sense than monolithic ones (many settings in one GPO)
- Normally you will find that it’s the number of settings you have applied that will cause performance issues, not GPOs.
- Avoid using Enforced & Block Inheritance where possible, correct design should resolve this, otherwise makes it difficult to troubleshoot why certain settings do or don’t apply
- Reuse GPOs where possible and link etc.
- Link the GPOs to the OU structure (or site), and then use Security Groups to selectively apply these GPO’s to particular users or computers.
- Avoid Group Policy software assignment and use better 3rd party tools
- Always try to link policies as high up as possible in the OU tree
- Predominantly Security Filtered Group Policy Objects is the most common way you can filter.
- You should be filtering a GPO only when you want to exclude or include exceptions to the scope of the policy
- Often have a security filtered policy that has pilot users computers as members, to selectively apply settings to their computers first for testing
- Majority of settings (80\20 rule) should be applied at the highest level, covering most use cases. Lower OU settings should be applied to specific departments or sites for examples
- Be sure that level one, 80% policies are configured with a default settings to cover more essential configurations
Optimal GPO Performance
- If making frequent changes to GPOs, keep in mind the effect where a change to one Client Side Extension (CSE) can impact the processing of all CSEs. If you plan to make frequent changes to, for example, registry policy, it makes more sense to put your registry policy into functional GPOs (GPOs that only do registry policy) as that will isolate other CSEs from processing when changes occur.
- When thinking about how many GPOs are too many, keep in mind that policy processing only occurs during changes, and “expensive” CSEs like Software Install, Folder Redirection, or a large number of registry policies or setting permissions on registry trees takes most time.
- 30 GPOs that apply to a given user but do minimal registry policy changes and don’t change frequently could take less time to process than 5 GPOs that are running expensive CSEs on a regular basis because those GPOs are changing frequently
Comparing monolithic and functional GPOs
|Issue||Monolithic GPOs||Functional GPOs|
|Delegation/Isolation||Difficult, since each GPO can contain settings from multiple areas, and you can only delegate at the GPO level, not the settings level.||Easy, since each GPO contains a single policy area, you can delegate, for example, the software installation GPO to the deployment administrator, the security GPO to the security officer, and so on.|
|Manageability & Complexity||Potentially simpler and easier to manage, because each GPO contains all settings in a single place.||Potentially more difficult because more GPOs mean more places to look to track down problems and more complexity determining the resultant set of policy for a given user or computer.|
|Performance||Potentially slower because, for a given client-side extension, if one GPO changes, all extensions would need to run against all GPOs in scope.||Depends upon how many GPOs are in use, and how often they change. Performance could be better in dynamic environments compared to monolithic GPOs.|
Above info and table from http://technet.microsoft.com/en-gb/magazine/2008.01.gpperf.aspx
Group Policy – Loopback Processing Explained
- This will allow user settings to apply to computer objects in that OU, while normally you can only configure user settings in GPOs and apply them to OUs where the user objects reside
- Allows user configuration to be applied via GPOs that are linked to the OU of the computer object, rather than the user object
- Merge mode
- Users will receive both settings from GPOs applied to their own OU (user objects) and from GPOs applied to the VDI (computers) OU
- User policy settings applied, are the combination of those included in both the machine and user GPOs. Where conflicts exist, the machine GPOs win
- Only GPOs applied in the VDI (computers) OU will be applied
- User policy is defined entirely from GPOs associated with the computer. Any GPOs associated with the user are ignored.
Reporting and Optimisation Tools – GPO Reporting Pak
*Note: – I haven’t been asked to review or reference the following software on my blog*
Having researched a few options, this is my personal recommendation, however you should analyse your requirements and pick the appropriate solution to fit your needs.
- Perform exports to Excel, allowing a full reporting of settings
- Filter export results and snapshot views to display only those settings that contain your keyword
- View a variety of pre-defined reports for precision group policy reporting with the Report Portal.
- Reports include Unlinked GPOs, GPO by CSE Area, Redundant/Conflicting Settings, GPO Links and new Slow Boot/Slow Logon Reports (see attached)
- Ability to quickly report on settings across all GPOs in your environment
- Ability to compare up to 4 GPOs or GPO backups, for comparing GPOs or backups against a baseline GPO
- Support for comparing GPO Exporter Snapshots, to quickly and easily find changed settings within GPOs
- Support for showing settings that are same as well as different
- Support for all settings in Windows 7/8 and Server 2008 R2/2012, including GP Preferences
- Ability to quickly compare settings between live and/or backup GPOs in the same or different domains/forest
- GPO Analysis\Optimisation
- Slow Boot\Logon
The tools will help ensure baselines are consolidated correctly against existing GPOs using the Compare tool. Also, the overall reports you can run against your domain and GPO is essential. You can yield all sorts of information using the tools, to help you ensure the Group Policy environment is optimised overall.
A whitepaper explaining the above Slow Boot\Slow Logon Reports can be found here