Group Policy. Jeremy Moskowitz

“Create a GPO in this domain, and Link it here” from the context menu to open the New GPO dialog box.

      4. In the New GPO dialog box, type the name of your new GPO, say “Hide Mouse Pointers Option / Restore Screen Saver Option.” This will create a GPO in the Group Policy Objects container and link it to the Human Resources Users OU.

      5. Right-click the Group Policy link and choose Edit from the context menu to open the Group Policy Management Editor.

      6. To hide the mouse pointers option in the Group Policy editor, drill down through User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization and double-click the Prevent changing mouse pointers policy setting. Change the setting from Not Configured to Enabled, and click OK.

      7. To restore the Screen Saver setting for Windows 10, double-click the Prevent Changing Screen Saver policy setting. Change the setting from Not Configured to Disabled, and click OK.

      8. Close the Group Policy Management Editor to return to the GPMC.

      By disabling the Hide Screen Saver Tab policy setting, you’re reversing the Enable setting set at a higher level. See the sidebar “The Three Possible Settings: Not Configured, Enabled, and Disabled” later in this chapter.

      Verifying Your Changes at the OU Level

      On your test WIN10 machine, log back on as Frank. Because Frank’s account is in the OU, Frank is destined to get the site, domain, and now the new OU GPOs with the policy settings.

      On WIN10, right-click the Desktop and choose Personalize from the context menu to open the Display Properties dialog box.

You can now (as Frank) click Themes, and when you then try to click on “Go to mouse pointer settings” you will see what’s in Figure 1-25.

      You should also now (as Frank) be able to click within Personalization upon the Lock Screen menu, and when you try to click on “Screen saver settings” you will be able to open it.

      In Figure 1-25, you can see the before (left) and after (right) when the policy is applied. Look closely, and note that the “Pointers” option in the Mouse Properties applet is removed and that the Screen Saver option is no longer grayed out and is now available.

Figure 1-25: On the top, we have Frank’s Personalization page where Frank can now get to his Screen Saver settings. On the bottom (left) you can see Frank’s Mouse Properties before the policy applies. On the bottom (right) you can see Frank’s Mouse Properties after the policy applies (and note the missing “Pointers” tabs).

      This test proves, once again, that even OU administrators are not automatically immune from policy settings. Chapter 2 explains how to change this behavior.

      Group Policy Strategy: Should I Create More or Fewer GPOs?

      At times, you’ll want to lock down additional functions for a collection of users or computers. For example, you might want to specify that no users in the Human Resources Users OU can use the Control Panel.

      At the Human Resources Users OU level, you’ve already set up a GPO that contained a policy setting to hide the mouse pointers option in the Windows 10 Personalization page. You can create a new GPO that affects the Human Resources Users OU, give it a descriptive name – say, No One Can Use Control Panel– and then drill down through User Configuration⇒ Policies ⇒ Administrative Templates ⇒ Control Panel and enable the policy setting Prohibit Access to Control Panel.

      Or you could simply modify your existing GPO, named Hide Mouse Pointers Option/Restore Screen Saver Option, so that it contains additional policy settings. You can then rename your GPO to something that makes sense and encompasses the qualities of all the policy changes – say “Our Human Resources Users’ Desktop Settings.”

      Here’s the quandary: the former method (one policy setting per GPO) is certainly more descriptive and definitely easier to debug should things go awry. If you have only one policy set inside the GPO, you have a better handle on what each one is affecting. If something goes wrong, you can dive right into the GPO, track down the policy setting, and make the necessary changes, or you can disable the ornery GPO (as discussed in Chapter 2 in the section “Stopping Group Policy Objects from Applying”).

      The second method (multiple policy settings per GPO) is a teeny-weeny bit faster for your computers and users at boot or logon time because each additional GPO takes some miniscule fraction of additional processing time. But if you stuff too many settings in an individual GPO, the time to debug should things go wrong goes up exponentially. Group Policy has so many nooks and crannies that it can be difficult to debug.

      So, in a nutshell, if you have multiple GPOs at a particular level, you can do the following:

      ● Name each of them more descriptively.

      ● Debug them easily if things go wrong.

      ● Disable individually misbehaving GPOs.

      ● Associate a specific GPO more easily to a WMI filter (explored in Chapter 6).

      ● More easily delegate permissions to any specific GPO (explored in Chapter 2).

      If you have fewer GPOs at a particular level, the following is the case:

      ● Logging on is slightly faster for the user (but only slightly).

      ● Debugging is somewhat more difficult if things go wrong.

      ● You can disable individually misbehaving GPOs or links to misbehaving GPOs. (But if they contain many settings, you might be disabling more than you desire.)

      So, how do you form a GPO strategy? There is no right or wrong answer; you need to decide what’s best for you. Several options, however, can help you decide.

      One middle-of-the-road strategy is to start with multiple GPOs and one lone policy setting in each. Once you are comfortable that they are individually working as expected, you can create another new GPO that contains the sum of the settings from, in this example, Prevent Changing Mouse Pointers and Prohibit Access to Control Panel, and then delete (or disable) the old individual GPO.

      Another middle-of-the-road strategy is to have a single GPO that contains only the policy settings required to perform a complete “wish.” This way, if the wish goes sour, you can easily address it or disable it (or whack it) as needed.

      Here’s yet another strategy. Some Microsoft documentation recommends that you create GPOs so that they affect only the User half or the Computer half. You can then disable the unused portion of the GPO (either the Computer half or the User half). This allows you to group together policy settings affecting one node for ease of naming and debugging and allows for flexible troubleshooting. However, be careful here because after you disable half the GPO, there’s no iconic notification (though there is a column labeled GPO Status that does show this). Troubleshooting can become harder if not performed perfectly and consistently. In all, I’m not a huge fan of disabling half the GPO.

      Creating a New Group Policy Object Affecting Computers in an OU

      For the sake of learning and working through the rest of the examples in this section, you’ll create another GPO and link it to the Human Resources Computers OU. This GPO will autolaunch a very important application for anyone who uses these machines: calc.exe.

      The setting we’re about to play with also exists under the User node, but we’ll experiment with the Computer node policy.

      First, you’ll need to create the new GPO and modify the settings. You’ll then need to move