Optimising Group Policy Login Performance

I was discussing this yesterday with a colleague of mine, essentially we had differing opinions on how to structure group policies and how it affected the log on speed of the users. My personal preference is always to leave the default policy untouched for fallback and testing, then to create new policies each dedicated to a set task such as:

• Standardised Desktop

• Password Policy

• IE Settings

• IPv6

• Bitlocker

• etc

My colleague was offering a different viewpoint saying that many policies would increase the login time for users and was less efficient. He recommended consolidating my multiple policies into a small number of policies directed to specific target groups such as:

• Servers

• Workstations

• Laptops

• etc

Naturally a discussion ensued and while I can see the logic of both, in my mind the separated policies being able to linked to multiple OUs (allowing a change to be made in a single location) and the simpler administrative view with separated policies was preferable. On the other hand, what was this doing to our logon times and how would it scale to a large scale corporate environment?

The answer is simple; it really doesn’t make that much of a difference. There are the obvious gotcha’s and tweaks to help GPO processing, but at the end of the day the primary factor is what you are doing, not how many policies you are using. Let me explain:

Make sure Login/File/Application Servers can cope: You can spend all the time you want optimizing GPO to run with maximum efficiency, but if the Global Catalog servers processing the login are overloaded and can’t cope with the requests then its pointless. In the same way, if you are using GPO to pull a file/application from a server which is under heavy load then your efforts will again be wasted. The vast majority of slow logins are because of slow access times to network resources during the login – not the optimisation of your policies. To help this make sure that servers needed in the login process are able to cope with requests quickly (using methods such as multiple GC servers and DFS to split the load on Fileservers)…. then worry about GPO optimisation.

Disable What you don’t need: There are always two parts to the GPO – User and Computer configuration. Each policy will check both parts for settings and apply the contents, if you are only using User based settings in a policy and the Computer section is empty, then disable the Computer section so the client doesn’t waste time checking it.

To do this, go to the details page on the policy properties:

ACL Filtering Vs Good AD Structure:  One of the most important things you can do for efficient GPO processing and troubleshooting is make sure you have a good AD structure and getting it wrong is the road to ruin. Keep it simple and separate things out so appropriate policies can be applied without having to resort to WMI/ACL filtering. While you can use these methods to filter policies to only apply for specific account groups, it will generally have a negative impact on performance. It is great in theory, but the actual processing of ACL/WMI filters, expanding groups, checking permissions, etc all takes time and can create quite a delay if used in multiple locations. That’s not to say don’t ever use it – in the right place it can be very useful, but it should not be used to try and compensate poor AD design. If using it make sure the servers set to expand those security groups can cope with the task otherwise be prepared to wait!

CSE Processing: Once you have ensured that your AD has good structure, your login servers (and referenced file/application servers) can cope with the request volume and you are not using excessive filtering on policies the next most important thing is CSE processing.

As a very brief summary, every client has a number of agents to process different areas of policy settings. These are called Client Side Extensions (CSE):

• Gptext.dll (Scripts, IP Security, QoS, Wireless Network Policies)
• Fdeploy.dll (Folder Redirection)
• Scecli.dll (Security Settings)
• dskquota.dll (Disk Quotas)
• Ledkcs32.dll (IE Maintenance)
• appmgmts.dll (Software Installation)
• Userenv.dll (Administrative Templates, Software Restriction Policies, Public Key Policies)

For every CSE registered with WinLogon, each is checked to see if it should be running (ie – Slow Link Detection, background processing, etc) and then in turn, each CSE deemed active for the current policy application looks at every GPO in the list presented to it (the list is provided by processing the AD LSDOU structure and ACL/WMI filtering for the computer/user) in turn checking each policy’s enabled Computer/User containers for CSE GUIDs indicating it should be applied.

Summary

Less time worrying about the number of policies and more time thinking about correct AD structure, avoiding unnecessary use of ACL/WMI filtering, making sure response times of login/file/application servers are fast and how many policies have active CSE settings in them.

If you really do want to worry about the CSE processing, from what I have read 20 policies each focused on an individual CSE will give better performance than 20 policies each referencing multiple CSEs. So instead of focusing on tasks such as “Standardised Desktop” or categories such as “Workstation” – it is likely better off focusing on CSE categories such as “Folder Redirection”, “Software Installation”, etc. However that may well be the most efficient, but in my mind that would be even harder to administer…. so I’ll be sticking with my original way of doing things and focusing on optimising everything else.

Microsoft took an interesting take on GPO best practice in a Jan2010 entry on the GPO team blog (http://blogs.technet.com/b/grouppolicy/archive/2010/01/25/gp-editorial-group-policy-best-practices.aspx) saying:

“The real best practice is to ‘go do work.’ “ 

That kind of says it all really – I think I’ll stop worrying about it

 

If you want to read more about how Group Policy works, microsoft have a nice explanation at: http://technet.microsoft.com/en-us/library/cc784268(WS.10).aspx