Group Policy. Jeremy Moskowitz

feeding computers User-side settings. When a GPO hits user objects with Computer policy settings or computer objects with User policy settings, it simply will not do anything. You’ll just sit there and scratch your head and wonder why it doesn’t work. But it’s not that it’s not working; this is how it’s designed.

      Computer settings are for computer objects, and User settings are for user objects. If this is bad news for you, there are two ways to get out of the problem. One way is an in-the-box advanced technique called loopback processing that can help you out. Look for more information on loopback processing in Chapter 4. The other way is via a third-party tool called PolicyPak, which (among other things) can permit computers to embrace User-side settings. More on this in Chapter 6, “Managing Applications and Settings Using Group Policy.

      Active Directory and Local Group Policy

      Group Policy is a twofold idea. First, without an Active Directory, there’s one and only one Group Policy available.

      Officially, this policy directly on the workstation is called a local policy, but it still resides under the umbrella of the concept of Group Policy. Later, once Active Directory is available, the nonlocal (or, as they’re sometimes called, domain-based or Active Directory–based) Group Policy Objects come into play, as you’ll see later. Let’s get started and explore both options.

      Then, here’s the weird thing: after I’ve fully described Active Directory’s Group Policy, we’re going to take a second visit back to Local Group Policy. That’s because with Windows Vista and later, there’s a special superpower I want to show you, but I only want to explain it after we’ve explored the first two concepts. So, in summary, here’s the short-term road map:

      ● Local Group Policy for Windows XP and later

      ● Active Directory Group Policy for all operating systems

      ● Multiple Local Group Policy (MLGPO) for Windows Vista and later

      Trust me; it’s easier to learn it this way, even though we’re taking two passes at one concept.

      While you’re plunking around inside the Group Policy editor (also known as the Group Policy Management Editor, or Group Policy Object Editor), you’ll see lots of policy settings that are geared toward a particular operating system. Some are only for specific operating systems, and others are more general. If you happen to apply a policy setting to a system that isn’t listed, the policy setting is simply ignored. For instance, policy settings described as working “Only for Windows 8” machines will not typically work on Windows XP machines. All policy settings have a “Supported on” field that should be consulted to know which operating systems can embrace which policy setting. Many of them will say something like “At least Windows XP” to let you know they’re valid for, say, XP and on.

      Understanding Local Group Policy

      Before we officially dive into what is specifically contained inside this magic of Group Policy or how Group Policy is applied when Active Directory is involved, you might be curious to see exactly what your interaction with Local Group Policy might look like.

      Local Group Policy is best used when Active Directory isn’t available, say either in a Novell NetWare environment or when you have a gaggle of machines that simply aren’t connected to a domain.

      Local Group Policy Editor

      The most expeditious way to edit the Local Group Policy on a machine is to click Start ⇒ Run and type in GPEDIT.MSC. This pops up the Local Computer Policy Editor.

      You are now exploring the Local Group Policy of this workstation. Local Group Policy is unique to each specific machine. To see how a Local Group Policy applies, drill down through the User Configuration ⇒ Administrative Templates ⇒ System ⇒ Ctrl+Alt+Del options and select Remove Lock Computer, as shown in Figure 1-2. As seen in the figure, the default for all policy settings is Not Configured. To make this policy setting perform its magic, choose the Enabled radio button and click OK.

      When you do, within a few seconds you should see that if you press Ctrl+Alt+Del, the Lock Computer option is unavailable.

      To revert the change, simply reselect Remove Lock Computer and select Not Configured. This reverts the change.

      You can think of Local Group Policy as a way to perform decentralized administration. A bit later, when we explore Group Policy with Active Directory, we’ll saunter into centralized administration.

      This Local Group Policy affects everyone who logs onto this machine – including normal users and administrators. Be careful when making settings here; you can temporarily lock yourself out of some useful functions.

      If you’re thinking to yourself, “Yep, I’ve done that,” then stay tuned. After the next section is complete, we’ll return to Local Group Policy and discuss the idea of Multiple Local Group Policy Objects, which can help ensure that you escape from this very jam.

      Before we leave Local Group Policy (for now), remember something that I stated in the introduction. That is, many of the settings we’ll explore in this book are available to workstations or servers that aren’t joined to an Active Directory domain. Just poke around here in Local Group Policy to get a feel for what you can and cannot do without Active Directory. However, many functions, like Folder Redirection settings (discussed in Chapter 10, “Implementing a Managed Desktop, Part 1: Redirected Folders, Offline Files, and the Synchronization Manager”), the Software Distribution settings (discussed in Chapter 11, “The Managed Desktop, Part 2: Software Deployment via Group Policy”), and others require Active Directory present to embrace these Group Policy directives.

      You can point to other computers’ local policies by using the syntax gpedit.msc /gpcomputer:"targetmachine" or gpedit.msc /gpcomputer:"targetmachine.domain.com"; the machine name must be in quotes.

Figure 1-2: You can edit the Local Group Policy using the Local Group Policy Editor (GPEDIT.MSC).

      Active Directory–Based Group Policy

      To use Group Policy in the most meaningful way, you’ll need an Active Directory environment. An Active Directory environment needn’t be anything particularly fancy; indeed, it could consist of a single Domain Controller and perhaps just one Windows 10 workstation joined to the domain.

      But Active Directory can also grow extensively from that original solitary server. You can think of an Active Directory network as having four constituent and distinct levels that relate to Group Policy:

      ● The local computer

      ● The site

      ● The domain

      ● The organizational unit (OU)

      The rules of Active Directory state the following:

      ● Every server and workstation must be a member of one (and only one) domain and be located in one (and only one) site.

      ● Every user must be a member of one (and only one) domain and may also be located within one OU (and only one OU).

      One of the most baffling questions people have when they start to dig into Group Policy is, “If a user can only be a member of one OU, how do I apply multiple Group Policy Object directives to one user?” I know it seems almost impossible based on the constraints listed, but I promise I’ll explain exactly how to do that in Chapter 2 in the section “Filtering the Scope of Group Policy Objects with Security.”

      Full Windows vs. Windows RT and What It Means for Group Policy

      Windows