Group Policy. Jeremy Moskowitz

er, Bing-ing will Bing it, er, bring it right up.

      Because Group Policy can be so all-encompassing, I highly recommend that you try the examples in a test lab environment first before making changes for real in your production environment.

      Bringing Up a Windows Server as a Domain Controller

      The DCPROMO.EXE you knew and loved is dead as of Windows Server 2012.

      Before continuing, ensure that your server is already named DC01. If it isn’t, rename it and reboot before continuing. Additionally, ensure that DC01 has a static IP address and is configured to use itself as the DNS server.

      Now, you’ll need to use the Server Manager’s “Add Roles and Features Wizard” to add the roles required to make your server a DC. It’s not hard. Here’s a sketch of the steps.

      First, fire up Server Manager, which is the leftmost icon when you’re on the server. Next, click Dashboard and select “Add roles and features,” as seen here.

      Then you’ll be at the “Add Roles and Features Wizard,” as seen here.

      Click Next to visit the Installation Type screen and select “Role-based or feature-based installation.” Then click Next.

      At Server Selection, click “Select a server from the server pool” and select your only machine: DC01.

      At Server Roles, select Active Directory Domain Services, as seen here, and say yes when prompted to load the additional items, which must come along for the ride.

      At the Features screen, click Next.

      At the AD DS screen, click Next.

      At the Confirmation screen, select “Restart the destination server automatically if required” and then click Install.

      Next, Active Directory components will be installed on DC01 along with the GPMC. When done, you’ll be able to select “Promote this server to a domain controller,” as seen here.

      At this point it should be pretty familiar. At the Deployment Configuration page, select “Add a new forest” and type Corp.com as the root domain name. Click Next.

      At the Domain Controller Options page, leave the defaults as is. Provide a Directory Services Restore Mode (DSRM) password. I recommend p@ssw0rd. (My suggested password in all my books is p@ssw0rd. That’s a lowercase p, the at sign, an s, an s, a w, a zero, then r, and d.) Click Next to continue.

      At the DNS Options page, you might get a warning; click Next.

      At the Additional Options page, leave the defaults and click Next.

      At the Paths page, leave the defaults as is and click Next.

      At the Review Options page, click Next.

      At the Prerequisites Check page, make sure there are no showstoppers. Finally, click Install on that same page.

      The computer should restart automatically and reboot.

      Congrats! You have your first Domain Controller!

      Getting Started with Group Policy

      Group Policy is a big, big place. And you need a road map. Let’s try to get a firm understanding of what we’re about to be looking at for the next several hundred pages.

      Group Policy Entities and Policy Settings

      Every Group Policy Object contains two halves: a User half and a Computer half. These two halves are properly called nodes, though sometimes they’re just referred to as either the User half and the Computer half or the User branch and the Computer branch.

A sample Group Policy Object with both the Computer Configuration and User Configuration nodes can be seen in Figure 1-2 (in the upcoming section, “Local Group Policy Editor”). Don’t worry; I’ll show you how to get there in just a second.

      Just to make things a little more complicated, if you’re deploying settings using Active Directory (the most usual case) as opposed to walking up and creating a “local GPO” as we do later in Figure 1-2, the interface is a wee bit different and shows the Group Policy Preferences node. Hang tight for more on that.

      The first level under both the User and the Computer nodes contains Software Settings, Windows Settings, and Administrative Templates. If we dive down into the Administrative Templates of the Computer node, underneath we discover additional levels of Windows Components, System, Network, and Printers. Likewise, if we dive down into the Administrative Templates of the User node, we see some of the same folders plus some additional ones, such as Shared Folders, Desktop, Start Menu, and Taskbar.

      In both the User and Computer halves, you’ll see that policy settings are hierarchical, like a directory structure. Similar policy settings are grouped together for easy location. That’s the idea anyway – though, admittedly, sometimes locating the specific policy or configuration you want can prove to be a challenge.

      When manipulating policy settings, you can choose to set either computer policy settings or user policy settings (or both!). You’ll see examples of this shortly. (See the section “Searching and Commenting Group Policy Objects and Policy Settings” in Chapter 2, “Managing Group Policy with the GPMC and via Powershell,” for tricks on how to minimize the effort of finding the policy setting you want.)

      Most policy settings are not found in both nodes. However, there are a few that overlap. In that case, if the computer policy setting is different from the user policy setting, the computer policy setting generally overrides the user policy setting. But, to be sure, check the Explain text associated with the policy setting.

      Wait… I Don’t Get It. What Do the User and Computer Nodes Do?

      One of the key issues that new Group Policy administrators ask themselves is, “What the heck is the difference between the Computer and User nodes?”

      Imagine that you had a combination store: Dog Treats (for dogs) and Candy Treats (for kids). That’s right; it’s a strange little store with seemingly two types of incompatible foods under the same roof. You wouldn’t feed the kids dog treats (they’d spit them out and ignore the treat), and you wouldn’t feed the kids’ candy to a dog (because the dogs would spit out the sour candy and ignore the treat).

      That’s the same thing that happens here. Sure, it looks tempting. There are lots of treats on both sides of the store, but only one type of customer will accept each type of treat.

      So, in practical terms, the Computer node (the first part of the policy) contains policy settings that are relevant only for computers. That is, if there’s a GPO that contains Computer-side settings and it “hits” a computer, these settings will take effect. These Computer-side settings could be items like startup scripts, shutdown scripts, and how the local firewall should be configured. Think of this as every setting relevant to the computer itself– no matter who is logged on at that moment.

      The User node (the second part of the policy) contains policy settings that are relevant only for users. Again, if there’s a GPO that contains User-side settings and it “hits” a user, these settings will take effect for that user. These User-side items make sense only on a per-user basis, like logon scripts, logoff scripts, availability of the Control Panel, and lots more. Think of this as every setting relevant to the currently logged-on user – and these settings will follow the user to every machine they