Group Policy

If you find yourself reading this book from front to back, indeed a good and not at all weird way to read a book, you already have a general idea of what Group Policy is and does (because we talked about it for a minute in Chapter 3, Active Directory). However, I've been around IT folks long enough to know that reading a book from cover to cover is fairly rare, and attention spans rarely accommodate such a quest. Therefore, any of you hitting up this chapter in a random fashion because the words "Group Policy" drew your attention or you have a specific need that you are hoping to be answered in this chapter, fear not! Let's again summarize the great and glorious power of Group Policy.

It's easy to understand the general use of the word "policy", meaning some kind of ruleset, structure, or standard to which you need something to adhere. In our case, we're talking about Microsoft Windows-based computers (and servers). Applying...

Group Policy Object

This is pretty straightforward. The overlying technology we are talking about here is called Group Policy, and an individual instance of a Group Policy is known as a Group Policy Object, commonly referred to as a GPO. A GPO is a single package that contains one or many policy settings and applies to a domain computer, a domain user, or sometimes many computers and users all at the same time.

GPOs are stored inside Active Directory and are replicated among your domain controller servers. Every time a domain user logs into a domain-joined computer that is connected to your network, the computer reaches out to Active Directory and asks, "Hey, got any GPO settings for me?" Then a whole slew of activity commences as a domain controller hands over all of the GPO settings that it contains, which apply to the computer and/or user logging in. This is a key piece of information. GPOs are scoped upon creation, giving you the power to define to whom each policy...

Building a GPO

There's nothing quite as good as jumping in and getting your hands dirty, so let's get down to business and build a new GPO. Don't worry, we will be careful not to apply this GPO to anything yet and save that for our next section. As with most Microsoft technologies, there is a special management console created just for interacting with Group Policy, appropriately named the Group Policy Management Console (GPMC). Logging into any of your domain controller servers, you can launch GPMC from inside Administrative Tools, inside the Tools menu of Server Manager, or by launching GPMC.MSC from Start | Run, Command Prompt, or PowerShell:

Figure 5.1: GPMC

You'll notice in Figure 5.1 that there are already some GPOs listed here. They are a combination of default GPOs that always exist when you install Active Directory (we'll talk about the Default Domain Policy a little later in this chapter) and the IPAM GPOs that the IPAM configuration...

Scoping a GPO

I briefly mentioned the ability to scope GPOs so that they only apply to machines or users that you desire. This is probably the single most important piece of the Group Policy puzzle to understand. You have already seen a couple of examples of plugging settings into GPOs, and information is abundant on the Internet with useful and exact policy settings and how to put those into place. If there is some particular task you are trying to accomplish on a large scale, turn to search engines and look for that item while including the search word "GPO," and you'll quickly find information about how to set up your new GPO to do that thing. What those articles, Microsoft documents, and blog posts are not going to define for you is to what extent you push those settings into your network, and how to ensure your new GPO is not too far-reaching. That decision is yours alone. In this section, we will discuss the different options available within every GPO that allow...

Computer settings and user settings

After poking around inside GPOs for a few minutes, you are likely to notice that the Group Policy Management Editor is split up into two different sections. When drilling down inside a GPO to find the particular setting that you are about to roll into place, the first choice you need to make is whether you are working on a Computer Configuration, or a User Configuration. Understanding the differences and always keeping these differences in mind is important not only for finding the setting you are searching for, but also for ensuring that your new GPO is linked to the correct place and applying to the proper type of object. You can see these two sections of any GPO in Figure 5.17:

Figure 5.17: Computer Configuration and User Configuration

Computer Configuration

All GPO settings listed beneath Computer Configuration are, of course, settings that can apply to your domain-joined computers. Duh! Aren't all GPO settings applied...

Policy vs preference

There is an important distinction that every Group Policy administrator needs to understand about GPO settings. There are two different types of policy settings, and they behave very differently. Now that we understand the differences between Computer Configuration and User Configuration, the next tier you'll notice inside Group Policy Management Editor are sub-folders titled Policies and Preferences.

Policies

Managed policies, the items listed under the Policies section of both computer and user configurations, generally behave like true gentlemen. These are settings that you put into place and expect results, forcing the setting into place, and nothing the user tries to do can change them. When reversing course and removing a GPO from a system, they happily comply. What do I mean by that? When you plug some policy settings into a GPO and then link that GPO to a location, you expect those settings to be put into place on the machines or users to...

Default Domain Policy

Throughout this chapter, we have bounced in and out of the Group Policy Management Console a number of times, and now that you know what a GPO looks like and how to identify GPO links, you have probably noticed a GPO linked to the root of the domain called Default Domain Policy. This GPO comes built-in with Group Policy, every environment has one unless an admin has taken steps to delete it, which I would not recommend.

The Default Domain Policy applies to every user and computer that is part of your domain directory. Since this GPO is completely enabled right off the bat and applies to everyone, it is commonplace for companies to enforce global password policies or security rules that need to apply to everyone. In fact, many who are unfamiliar with Group Policy and uncomfortable with creating, linking, and filtering their own GPOs will just continually throw more and more settings inside Default Domain Policy. All of these settings will apply successfully...

Administrative Templates

Go ahead and edit a GPO, any GPO, so that you have the Group Policy Management Editor open in front of you. Expand the Policies folder for either Computer Configuration, User Configuration, or both, and you will notice a folder inside each called Administrative Templates. Most of us generally think of Administrative Templates the same as any other GPO configuration setting, simply a collection of items with which you can manipulate users or computers, right? Sort of, but while Software Settings and Windows Settings are built into Group Policy and are basically the same for any domain environment, Administrative Templates are customizable.

Administrative Templates showcase the flexibility of Group Policy. Each setting within Administrative Templates is being pulled from template files that reside on your domain controller servers. These template files are ADMX files. All of the information needed to display the setting inside Group Policy Management Editor...

Central Store

When opening up the Group Policy Management Console and creating or editing a GPO, the settings available within your console session are settings pulled from ADMX/ADML files that are on the hard drive of the computer or server from which you are using GPMC. When implementing new settings via ADMX files, it would be a huge chore to have to copy those new files into place on every one of your domain controllers, in addition to all of the client computers where you might have the RSAT tools installed. Thankfully, there is a solution to automate this for you!

The Central Store is something that can be enabled in Active Directory that allows the replication of ADMX/ADML files. Once you enable the Central Store, all of your Group Policy management machines, such as domain controllers, will look to the store as its repository for these template files.

Enable the Central Store

All that it takes to enable the Central Store in Active Directory is the creation of two...

Summary

Group Policy is an incredibly powerful tool to have at your disposal when working within a domain environment. Many pre-built configurations and settings exist, and since we can manipulate the registry on client machines, the sky is pretty much the limit on what you can manage on your client computers via GPOs.

As is the case with many topics inside Windows Server, there is so much information related to Group Policy that it warrants a book of its own. Thankfully, I had the opportunity to do exactly that! If you are interested in discovering more about Group Policy and all of the ways that it can be used to secure your infrastructure, check out my title Mastering Windows Group Policy (https://www.packtpub.com/networking-and-servers/mastering-windows-group-policy).

Questions

1. Are screensaver settings computer or user configuration?
2. Do domain-level or OU-level links process first?
3. What is the special GPO setting that forces user settings to apply to any user on a given computer?
4. What type of GPO filtering do you configure inside the GPO itself, such as with a mapped network drives policy?
5. True or false – It is possible for a user to override a Group Policy preference.
6. What is the default timer between Group Policy background refresh cycles?