The Basics: Group Policy

The basics: Group Policy – best of best practice

One of the most common questions I receive from customers when on the road is regarding Group Policy and baseline templates for it. Managing group policy is something very personal to some, each and everyone have their own way of doing it – and different reasons why. And Group Policy also includes stuff like Active Directory design, OU-structure and of course ease of use for the end-user.

This will be my first of a series of post where I try to explain the “basics” and “best-practice/proven-practice” of different technologies. It will be based on the best of Internet (thx to Google and Bing), input from colleagues and vendors and of course from my own personal experience and believes. My hope is that all post will be alive and evolve over time, so please feel free (I encourage to do so) to comment and give me your input on the matter(s)!

First of all, OU design:

This is the design of my current environment. It’s based on a BP from Microsoft (a very old one) but I think it’s a good design that gives you lots of options. Also, as you can see, I have an identical OU for testing, not currently in use due to lack of HW for a second environment.

One downside of this design is that it could be necessary to overlap GPOs applied to “Computers” with GPOs applied to the different chassi-types. This could of course be avoid by linking GPOs to each individual OU. If so, it could be many GPOs or links to manage. This could lead to a higher management workload, but (as I’ll explain later) it won’t be a big difference (if any) in performance over a single monolithic “computer” GPO. Another good reason for separating GPOs is the ease of overview. If you have a specific GPO for tablets, it’s easy for a sysadmin or technician to look in the GPMC (or other tool of your choice) and see exactly what GPOs that apply and what settings they configure. It also improve performance to have setting configure only one time for a particular computer- or user-object.

Anyway, try to keep the OU-structure as flat and clean as possible. Try not to segregate everything to much. Use as few OUs as possible and at most 10 layers from the top down, some systems find it difficult to work and search when it’s more than that, and it could also risk a slower performance.

OU

Questions on that? No? Moving on!

Second, monolithic or functional GPOs?

Great link here, that I’ll try to make summarize below, and give my own input of course
http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx (yes its “old” but from what I know still valid)

What’s the difference?

Monolithic is where you have fewer, larger (more settings configured) GPOs with several different settings in several different parts of the GPO (Administrative Templates, Preferences, Windows Settings etc). The good thing about this design is that it easy to get an overview, fever GPOs, and in some ways easier to manage.

The bad things is that you could need to override more settings, if you have a deeper OU-structure. You could of course create several identical GPOs and link each to one single OU, but that would mean that you get more GPOs to change if a change in a setting need to be implemented domain wide for example.

Functional GPOs are GPOs where you only configure one setting (in extreme cases) or several settings in the same part of the GPO (like configure Administrative Templates in one and Windows Settings in another) or several settings for a function (like Offline Files). You then use GPO links (will have a short section about it later on) to implement the setting for one or several OUs where the setting is needed.

The reasons to use this are that you get good control over settings, and you don’t need to override settings, just link the settings you need to the specific OU where it should apply. This of course needs a bit of thought regarding the design. For example, you need to find the lowest possible OU for a setting to apply to, so that you don’t inherit a setting from a higher level that shouldn’t apply to a lower OU level. According to the article (read it to get the detailed description) this design is the best from a performance perspective. Biggest performance input is achieved in an environment that have lots of changes to the GPOs, due to the way GPOs are processed.

This of course is question of taste also, we are not talking about minutes in difference for most environments, more seconds. Therefore, a sysadmin used to monolithic design will probably use it and the once that are used to functional will use that. I prefer it, but I will try to move towards functional. The reason for that is simple, I believe that this approach are more suitable for more customers. It’s easier to understand for anyone working with it and the ease of handover to new IT-staff are easier.

I don’t say that monolithic are wrong or bad in any way, it’s suitable for many companies or in many different scenarios. It’s up to you to decide what’s best in each case, and what you prefer. Ease of management but risk a somewhat lower performance or somewhat better performance and a risk of more and more complex management.

Now, get a new cup of coffee and then get back here for the last part (it’s shorter so you can soon relax and think it over).

Third, how to apply and filter GPOs.

First and foremost, GPOs are applied using links to one or several OUs. It’s then inherited down if nothing prevents it. Like I said earlier on, the most important thing is to try to link GPOs as low in the OU-structure as possible. The less GPO you can use (in both monolithic and functional) the better. The fever inherited GPOs you can use the better, both performance and management vice. It’s also good if you can avoid to block inheritance on OU, this do impact performance – but in some cases it can’t be avoid.

When a link are established and linked to either a computer or user OU (don’t mix the settings and always disable the settings not used). It will then apply to the objects below. Also, you can use something called loopback processing in two ways. Loopback means that you can apply user-policies to computer-objects, and that the settings will apply to all users that log on to that computer. This is something that you should avoid if possible, due to some settings not being supported in loopback configurations and also from a performance perspective. But in some scenarios it may be necessary or a lot easier to work with, for example virtual environment and VDI solutions. Loopback can be used in two ways, merge or replace. Merge indicates that the policies that the user are targeted with are merged with the once applied to the computer-object using loopback and replace indicates that it’s only the loopback GPOs that apply. What’s most suitable depends on the situation, but in most cases replace are the one to choose if you really need loopback. I have been doing some work at customers with the user and computer-objects in different domains, and in those cases it could come in handy with merge.

Replace

So, when the GPOs are applied, you could need to filter them a bit more. This is done by using either security groups and/or WMI-filters. On some individual settings you could also use something called Item Level Targeting, explained further down. Security groups are basic, add one or more groups and/or users that the GPO should apply to and only the members will be affected by the settings in the GPO. This is something you always should do, and by default it affects “Authenticated Users” – in other words all users or computers that have successfully been authenticated against Active Directory.

WMI-filters uses Windows Management Instrumentation (WMI) to use things like operating system, architecture, installed applications, chassi-type etc to filter GPOs even more. This is something that could be used during a change of operating system for example. Perhaps if a user should have two different sets of GPOs when logged on to either a Windows XP or Windows 8.1 PC. WMI filters lowers the performance of GPOs, but I tend to use them quite a lot, mostly in the scenario I just described. Just try to remove them then the project are over.

Filtering

Item Level Targeting are for individual settings inside a GPO. It works a bit like a WMI-filter, but for one single setting (a preference). I see more and more use of this, and believes that it will be used more often in the future. It of course also impact performance, but gives you great opportunities to fine-grain policies to suit every user or device perfectly. I have used this for instance in scenarios where you have one OU, with say 50-60 OU below. Each and every OU should have one setting that are different, the rest should be the same. Instead of making 50-60 different GPOs, you could use ILT to have one big GPO with 60 different settings. I don’t know if it’s the best way to do it, but in my case it worked great.

ILT

That’s it for now, lots of information – think I have included the most important stuff anyway. In short:

Try to avoid:
Loopback, WMI, ILT, overriding previous GPOs and also try to avoid blocking inheritance. But of course, don’t be afraid of using them, in some scenarios its the best way (or only) way to do it.

Decide what’s best for your IT-environment:
Monolithic or Functional GPOs?

Think over your OU and GPO design:
Not once, not twice at least three times. And try to keep it flat.

If you have any input on this, please comment and discuss it. The post will be alive, and will be improved.

Regards,

Simon

Tagged with: , , , , ,
Posted in Group Policy, Microsoft, The Basics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: