Group Policy. Jeremy Moskowitz

demonstration should prove how powerful Group Policy is, not only because everyone at the site is affected, but more specifically because administrators are not immune to Group Policy effects. Administrators are not immune because they are automatically members of the Authenticated Users security group. (You can modify this behavior with the techniques explored in Chapter 3.)

      Applying Group Policy Objects to the Domain Level

      At the domain level, we want to deliver an edict that says that the Sounds option in the Windows Personalization page should be removed.

      Active Directory domains allow only members of the Domain Administrators group the ability to create and link Group Policy directly on the domain level. Therefore, if you’re not a DA (or a member of the EA group), or you don’t get delegated the right, it’s likely that you’ll never get to practice this exercise outside the test lab. (A bit later we’ll talk more about how to give others besides Domain Admins rights to create and link GPOs.)

      To apply the edict, follow these steps:

      1. In the GPMC, drill down by clicking Group Policy Management ⇒ Forest ⇒ Corp.com.

2. Right-click the domain name to see the available options, as shown in Figure 1-18.

Figure 1-18: At the domain level, you can create the GPO in the Group Policy Objects container and then immediately link to the GPO from here.

      “Create a GPO in this domain, and Link it here” vs. “Link an Existing GPO”

      In the previous example, we forced the site level to embrace our “Hide Screen Saver Option” edict. First, we created the GPO in the Group Policy Objects folder, and then in another step we linked the GPO to the site level. However, at the domain level (and, as you’re about to see, the OU level), we can take care of both steps at once via the “Create a GPO in this domain, and Link it here” command. (Note, in previous versions of the GPMC, this was confusingly called “Create And Link A GPO Here.” Being a grammar snob, this was a personal wish of mine to have clarified, and I’m happy to see Microsoft agreed and corrected it.)

      This command tells the GPMC to create a new GPO in the Group Policy Objects folder and then automatically link the new GPO back to this focused level of Active Directory. This is a time-saving step so we don’t have to dive down into the Group Policy Objects folder first and then create the link back to the Active Directory level.

      So why is the “Create a GPO in this domain, and Link it here” option possible only at the domain and OU level and not the site level? Because Group Policy Objects linked to sites can often cause excessive bandwidth troubles when the old-school way of doing things is used. With that in mind, the GPMC interface makes sure that when you work with GPOs that affect sites, you’re consciously choosing from which domain the GPO is being linked.

      Don’t panic when you see all the possible options. We’ll hit them all in due time; right now we’re interested in the first two: “Create a GPO in this domain, and Link it here” and “Link an Existing GPO.”

      Since you’re focused at the domain level, you are prompted for the name of a new Group Policy Object when you right-click and choose “Create a GPO in this domain, and Link it here.” For this one, type a descriptive name, such as “Prohibit Changing Sounds.” Your new “Prohibit Changing Sounds” GPO is created in the Group Policy Objects container and, automatically, a link is created at the domain level from the GPO to the domain.

      Take a moment to look in the Group Policy “swimming pool” for your new GPO. Simply drill down through Group Policy Management ⇒ Forest ⇒ Domains ⇒ Corp.com and locate the Group Policy Objects node. Look for the new “Prohibit Changing Sounds” GPO.

      Right-click the link “Prohibit Changing Sounds” (or the GPO itself) and choose Edit to open the Group Policy Management Editor. To make your wish come true and affect the sounds applet Windows 10 Personalization page, drill down through User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization, and double-click Prevent changing sounds. Change the setting from Not Configured to Enabled, and click OK. Close the Group Policy Management Editor to return to the GPMC.

      Note that the policy setting will only affect Windows 7 and later, so any Windows XP machines (if you have any) will ignore the policy setting.

      Verifying Your Changes at the Domain Level

      Now, log on as any user in the domain. You can log onto any computer in the domain (say, WIN10) as any user you have defined – even the administrator of the domain.

      On WIN10, right-click the Desktop and click Personalize ⇒ Themes ⇒ Go to Advanced sound settings.

You’ll see in Figure 1-19 the before and after. On the left, you’ll see that before the policy applies, there are four tabs in the Sound applet. After the policy applies, there are three tabs in the Sounds applet.

      The actual policy name was called Prevent changing sounds. Note that it didn’t prevent access to the Sounds applet, but instead removed the most critical tab, the Sounds tab, in the Sound applet.

      Once again, administrators are not immune to Group Policy effects. You can change this behavior, as you’ll see in Chapter 2.

Figure 1-19: The Sounds applet goes from four tabs to three tabs because the user is affected by the domain-level policy

      Applying Group Policy Objects to the OU Level

      OUs are wonderful tools for delegating away unpleasant administrative duties, such as password resets or modifying group memberships. But that’s only half their purpose. The other half is to be able to apply Group Policy.

      You’ll likely find yourself making most Group Policy additions and changes at the OU level, because that’s where you have the most flexibility and the OU is the most refined instrument to affect users. Once OU administrators become comfortable in their surroundings, they want to harness the power of Group Policy.

      Preparing to Delegate Control

      To create a GPO at the OU level, you must first create the OU and a plan to delegate. For the examples in this book, we’ll create three OUs that look like this:

      ● Human Resources

      ● Human Resources Users

      ● Human Resources Computers

      Having separate OUs for your users and computers is a good idea – for both delegation of rights and GPO design. Microsoft considers this a best practice. In the Human Resources Users OU in our Corp.com domain, we’ll create and leverage an Active Directory security group to do our dirty work. We’ll name this group HR-OU-Admins and put our first users inside the HR-OU-Admins security group. We’ll then delegate the appropriate rights necessary for them to use the power of GPOs.

      To create the Human Resources Users OU using your WIN10MANAGEMENT machine, follow these steps:

      1. Earlier, you created a “unified console” where you housed both Active Directory Users and Computer and the GPMC. Simply use Active Directory Users and Computers, right-click the domain name, and choose New ⇒ Organizational Unit, which will allow you to enter a new OU name. Enter Human Resources as the name. (Note that newer versions of Active Directory Users and Computers will ask you if you want to “Protect container from accidental deletion.” It’s your choice. I typically deselect the check box.)

2. Inside the Human Resources OU, create two more OUs —Human Resources Computers and Human Resources Users,