Group Policy. Jeremy Moskowitz

that runs on ARM-based devices. Microsoft is not permitting Windows RT machines to join Active Directory. Therefore, there is no way to get Active Directory–based Group Policy on Windows RT. However, Windows RT will support Local Group Policy.

      In this book we’re not going to be spending much time on Windows RT, because most of what we’ll do, we’ll do within the domain – and Windows RT machines are left out of the fun.

      Windows RT has some non–Group Policy management capability so that administrators can control basic security settings. For more information about this feature, visit

      http://tinyurl.com/6ufn565

      Sadly, Windows RT has been out a few years (with the birth of Windows 8) and there still isn’t any way to manage these devices using Group Policy. If there ever comes a time that Windows RT machines can join the domain and get Active Directory Group Policy, I’ll write about it at www.GPanswers.com. But don’t hold your breath, as all indications suggest Windows RT will likely be depreciated and Microsoft will only be updating Windows RT to keep the lights on.

      Group Policy and Active Directory

      As you saw, when Group Policy is created at the local level, everyone who uses that machine is affected by those wishes. But once you step up and use Active Directory, you can have nearly limitless Group Policy Objects (GPOs) – with the ability to selectively decide which users and which computers will get which wishes (try saying that five times quickly). The GPO is the vessel that stores these wishes for delivery.

      Actually, you can have only 999 GPOs applied and affecting a user or a computer before the system “gives up” and won’t apply any more.

      You’ll create GPOs using the Group Policy Management Console, or GPMC for short. The GPMC can be added to a Windows Server 2016 computer or Domain Controller (see the section “Using a Windows Server 2016 Machine as Your Management Station”). The GPMC can also be added to a Windows 7, Windows 8, Windows 8.1, or Windows 10 machine via an extra download and install called RSAT. RSAT stands for Remote Server Administration Tools, and after installing it, you’ll find tools like Active Directory Users and Computers as well as the GPMC, which we’ll use right around the bend.

      When we create a GPO that can be used in Active Directory, two things happen: we create some brand-new entries within Active Directory, and we automatically create some brand-new files within our Domain Controllers. Collectively, these items make one GPO.

      You can think of Active Directory as having three major levels:

      ● Site

      ● Domain

      ● OU

      Additionally, since OUs can be nested within each other, Active Directory has a nearly limitless capacity for where we can tuck stuff away.

      In fact, it’s best to think of this design as a three-tier hierarchy: site, domain, and each nested OU. When wishes, er, policy settings, are set at a higher level in Active Directory, they automatically flow down throughout the remaining levels.

      So, to be precise:

      ● If a GPO is set at the site level, the policy settings contained within affect those accounts within the geography of the site. Sure, their user account could be in one domain and their computer account could be in another domain. And of course, it’s likely that those accounts are in an OU. But the account is affected only by the policy settings here because the account is in a specific site. And logically, when a computer starts up in a new site, the User object will also get its site-based Group Policy from the same place. This is based on the IP subnet the user is a part of and is configured using Active Directory Sites and Services.

      ● If a GPO is set at the domain level, it affects those users and computers within the domain and all OUs and all other OUs beneath it.

      ● If a GPO is set at the OU level, it affects those users or computers within the OU and all other OUs beneath it (usually just called child or sub-OUs).

      By default, when a policy is set at one level, the levels below inherit the settings from the levels above it. You can have “cumulative” wishes that keep piling on.

      You might wonder what happens if two policy settings conflict. Perhaps one policy is set at the domain level and another policy is set at the OU level, which reverses the edict in the domain. The result is simple: policy settings further down the food chain take precedence. For instance, if a policy setting conflicts at the domain and OU levels, the OU level “wins.” Likewise, domain-level settings override any policy settings that conflict with previously set site-specific policy settings. This might seem counterintuitive at first, so bear with me for a minute.

      Take a look at the following illustration to get a view of the order of precedence.

      The golden rule with Group Policy is truly, “Last writer wins.” Another way to say it is, “If any GPOs conflict, the settings contained in the last-written GPO win.”

      However, don’t forget about any Local Group Policy that might have been set on a specific workstation. Regardless, once that local policy is determined, only then do policy settings within Active Directory (the site, domain, and OU) apply. So, sometimes people refer to the four levels of Group Policy: local workstation, site, domain, and OU. Nonetheless, GPOs set within Active Directory always trump the Local Group Policy should there be any conflict.

      If this behavior is undesirable for lower Active Directory levels, all the settings from higher Active Directory levels can be blocked with the “Block Inheritance” attribute on a given OU. Additionally, if a higher-level administrator wants to guarantee that a setting is inherited down the food chain, they can apply the “Enforced” attribute via the GPMC interface. (Panic not! Chapter 2 explores both “Block Inheritance” and “Enforced” attributes in detail.)

      Note that you cannot “Block Inheritance” between Local GPOs and Active Directory GPOs. But it is true that anything you set within Active Directory to inverse a Local GPO setting is always honored. Said another way, Active Directory edicts trump local edicts. You can, however, literally “turn off” Local Group Policy Objects from processing. In Windows Vista and later, there is a policy setting found in Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy entitled Turn off Local Group Policy Object processing, which, when set to Enabled, will prevent Local Group Policy Objects from affecting the machine.

      Don’t sweat it if your head is spinning a little now from the Group Policy application theory. I’ll go through specific hands-on examples to illustrate each of these behaviors so that you understand exactly how this works.

      Linking Group Policy Objects

      Another technical concept that needs a bit of description here is the “linking” of GPOs. When a GPO “appears” to be “created” at the site, domain, or OU level via the GUI (which we’ll do in a moment), what’s really happening is quite different. It’s created in one set “place,” then merely “linked” there. (Yes, I know there are a lot of “quotes” in the last sentence, but sometimes that’s how I “write.”)

      Anyway, when you tell the system, “I want to affect an OU with this new GPO,” the system automatically creates the GPO in the fixed location and then associates that GPO with the level at which you want to affect. That association is called linking.

      Linking is an important concept for several reasons. First, it’s generally a good idea to understand what’s going on under the hood. However, more practically, the Group Policy Management Console (GPMC), as we’ll explore in just a bit, displays GPOs from their linked perspective.

      Let’s