A fair bit of what we do here at SDM Software is helping folks get a handle on their Group Policy environments. Using products such as our GPO Reporting Pak, we’ve had lots of customers clean up and reduce the clutter (not to mention improve desktop performance) of their Windows desktop environments. To that end, we’ve developed a number of high-level guidelines and best practices that we like to recommend, and I want to share some of these best practices here. To be sure, I’ve written and spoken extensively over the years about this topic, but my thinking changes and evolves as I work with more customers and as Group Policy changes and evolves (ever so slightly!).
Here are some of my big ones:
1. Linking vs. Filtering: My advice to folks is always to link your GPOs as close to their intended targets as possible. This usually translates into linking to OUs rather than at the domain level. It also translates to not relying too heavily on the various filtering mechanisms (e.g. security groups, WMI filters or GP Preferences Item-Level Targeting) as your default design. This doesn’t mean, “don’t use these filtering mechanisms”, because sometimes you simply have to. But it does mean, don’t base your design on them. Don’t rely on them. Why? Two main reasons–discoverability and change control. Discoverability means that if you are working in GPMC and you look at an OU, you can see, at-a-glance, which GPOs apply to that OU. If those GPOs are not using any filtering, you can fairly make the assumption that all users and computers in those OUs will receive those settings. Once you throw filtering into the mix, all bets are off. For example, if you’re using security group filtering, you might look at the list of security groups being used by a given GPO, but not really know which users or computers are in those groups until you start digging. Certainly it’s do-able, but it complicates and elongates things like troubleshooting. The second reason–change control–is also pretty simple. The more you rely on filtering, the more likely a filtering mistake will impact users or computers you didn’t intend it to. I’ve seen this far too often. An admin has a GPO linked to the domain (or a high-level OU). They are making a change to the GPO and accidentally pick the wrong security group, or they forget to include the security group the GPO is intended for before they commit the change. Blammo! Instant pandemonium. Sometimes those changes can be reversed quickly but sometimes, it’s not so easy. If you are just linking a GPO, you know that, as soon as that GPO is linked, it’s live and it’s much easier to control than otherwise. Again, I’m not saying, “Don’t use filtering.” I’m saying, filtering should not be your main strategy, unless you are absolutely forced to. For example–you have an OU with 10, 000 user accounts in it and the only way you can distinguish those users is via security groups.
2. How Many is Too Many?: It’s a constant question I get–“Do I have too many GPOs?” There is definitely such a thing as too many GPOs. Some of our biggest customers’ GPO counts range in the 1000s! But, that said, the better question to ask is not so much, “Do I have too many” as, “am I organizing my GP settings effectively?”. The key is to organize your GPOs so that they make sense for management and delegation in your environment. Do you really need those 10 GPOs each with 1 setting in them? If they are all targeting the same group of users or computers, then combine them. If you have a small team of one or two people managing Group Policy, all the more the reason to consolidate GPOs, because the need to break out GPOs for delegation becomes much less. In addition, being smart about grouping your GPO settings can help desktop performance. As I’ve blogged about before, it’s important to group synchronous policy areas like software installation and folder redirection together, and keep them separate from asynchronous extensions. This prevents forcing unwanted synchronous foreground cycles when you are updating GPOs. At the end of the day, the ‘right’ number of GPOs depends upon your environment, your administrative model and your needs. But just remember, having the most GPOs of any of your friends is NOT a bragging right :-).
3. Stay Away From Synchronous: For many years, and especially during the XP days (hey, some of us are still in those days!) I would recommend that folks enable the policy at “Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon”. That policy would force all foreground Group Policy processing to run synchronously–all the time. This helped with issues around Software Installation and Folder Redirection policy not processing the first time the user logged on (or the computer booted). But what it also did is slowed down every single boot and logon, waiting for Group Policy to finish processing. That seemed like a good idea at the time. It doesn’t so much anymore (and if I think back on it, it probably never did). Those couple of extensions that required it (GP Preferences Drive Mappings is another one but that is going asynchronous starting in Windows 8.1) weren’t worth the penalty of having synchronous processing on all the time. So, if you’re still using that setting, I would recommend turning it off. Your users will thank you.
4. Scripts: Scripts — Logon or Startup — are a tricky business. With the introduction of GP Preferences back when 2008/Vista shipped, a lot of the reasons for using scripts went away. But still, they persist. Many shops have scripts in place that have been there for years–doing drive mappings or registry punches that people are afraid to remove. But for sure, scripts are one of the biggest black boxes when it comes to troubleshooting GP problems and desktop performance issues. Most scripts don’t have any error logging written into them (something I highly recommend if you are using scripts). Often they also don’t check to see if they’ve run before. So you might be doing the same registry punch at logon, for the last 5 years. What a waste! My general recommendation is that if you are still using scripts for thing that GP Preferences could be doing (i.e. drive mappings, printer mappings, registry punches, etc.) then convert off those scripts as soon as you can. Really the only remaining reason to use scripts in GP is for more complex logic than what you can get with GP Preferences and it’s Item-Level Targeting. Even then, you would be well served to add some logging and conditional testing to your scripts to ensure that they can be more easily troubleshot when things go wrong.
This isn’t an exhaustive list of best practices. But these are some big ticket items that we often come across when working with customers. There’s lots of scenario specific things you can do–for things like kiosks, VDI implementations and servers–that add to this list. But these 4 items are places to start as you are examining your GP environments. And if you find that you need help with the process, we’re here for you! Just contact us at services@sdmsoftware.com and we can talk to you about what we can do.
Darren
Trackbacks/Pingbacks