We’ve come a long way so far in this book.

We’ve got Group Policy handled. We’ve set up Roaming Profiles, Redirected Folders, and Offline Files. We’ve deployed software using Group Policy Software Installation.

We’ve made a pretty big cake—but no frosting. Now it’s time for the finishing touches.

In this chapter, we’ll cover five big topics to round out your desktop experience:

1. Using Scripts You can deploy startup, shutdown, logon, and logoff scripts. And there are three ways to do it.
2. Configuring Internet Explorer You can deploy settings to your favorite (er, maybe not-so-favorite) application. We’ll review the in-the-box ways to manage Internet Explorer. And one “out-of-the box” way, too.
3. Restricting Access to Hardware Want a way to ensure that only the hardware you sanction gets onto your network? Well, giddyup!
4. Setting Up Printers The Group Policy Preferences have some special ability to help with printer management. I’ll show you the ropes.
5. Managing Local Administrator Passwords Well, you cannot manage local administrator passwords anymore using Group Policy Preferences because it’s a security risk. So, what’s the right way to do it? Find out in this section.

So, let’s get started with the finishing…touches, that is!

Scripts: Logon, Logoff, Startup, and Shutdown

Users have always been able to process logon scripts. Active Directory Users has a “holdover” way to deploy login scripts from the old Windows NT days.

However, you can step up to the next level using Group Policy and get more than just logon scripts:

• Users can process logon and logoff scripts.
• Computers can process startup and/or shutdown scripts.

And, the best part is, you’re not limited to old DOS-style batch files. Scripts deployed via Group Policy can use DOS-style .BAT or .CMD scripts, VBScript (.VBS files), JavaScript (.JS files), or even executables.

Also, you can also use PowerShell (.PS1) scripts when your target machine is Windows 7 or later. As you’ll see, however, there are some caveats to delivering PowerShell scripts via Group Policy.

Non-PowerShell-Based Scripts

In the following sections, we’re going to explore all the non-PowerShell ways to deploy scripts. Look at the list in the previous section; most people use .VBS or DOS-style batch files.

In these examples, I’ll use basic DOS-style .BAT commands to explain the concept. First is an example of a script that displays “Hello World” and then pauses for a key press before removing the files from the %temp% folder.

In Notepad, create the following file:

Echo "Hello World."
Pause
Del /Q /S %temp%
Pause

Okay, my example is kind of lame. In the real world, you can do all sorts of things, like automatically fire up Excel at logon or kick off a full-drive sweep of your virus scanner at shutdown. We’re going to keep it simple for these examples.

To use scripts with Group Policy, users must be in the Site, Domain, or OU linked to a GPO that contains a logon or logoff script. As the name of the script implies, users execute the script only at logon or logoff. Computers must also be in the Site, Domain, or OU linked to a GPO that contains a startup or shutdown script, which they run only at startup or shutdown.

User and computer scripts delivered via Group Policy do not run “visibly” to the user, which prevents users from canceling them. Scripts run silently in the background unless there is a problem. At that point, you have to wait until the script times out (10 minutes by default). I’ll show you a bit later how to expose the scripts to run visibly.

Startup and Shutdown Scripts (Non-PowerShell)

The startup and shutdown script settings are found under the Computer Configuration ⇒ Policies node in the Windows Settings ⇒ Scripts (Startup/Shutdown) branch. You can get your proposed script into the proper GPO in many ways; however, I think I have found the ideal way, as follows:

1. Once you’re in the Group Policy Management Editor, drill down to the Scripts (Startup/Shutdown) node and double-click Startup. The Startup Properties dialog box will appear.
2. Click the Add button to open the “Add a Script” dialog box.
3. In the Script Name field, you can enter a filename or click Browse to open the Browse dialog box, shown in Figure 12-1.

4. To create a new file, right-click in the Browse dialog box, and choose New ⇒ Text Document, for example.
5. Enter a name for the file, such as myscript.bat.
6. When asked if you want to change the file extension, click Yes, right-click the file, and choose Edit from the context menu to open Notepad.
7. Type your script, and save the file.
8. Select the new file as the proposed script.

Again, the computer account must be in an OU with a linked GPO that contains a script. However, don’t reboot yet. By default, you won’t see the script run. And, since our script contains a Pause statement, your users will wait a really long time before the script times out. To allow the script to be visible (and enable you to press any key at the pause), enable a policy setting that also affects the machine. Traverse to Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts, and select either Run startup scripts visible or Run shutdown scripts visible, or enable both options. Note that, oddly, in Windows Vista and later, neither of these policy settings will do anything unless you also force the scripts to run synchronously.

Next, it’s important to understand the context in which startup and shutdown scripts run. Specifically, they run in the LocalSystem context. If you want to connect to resources across the network, you’ll need to ensure that those resources allow for computer access across the network (not just user access), because the script will run in the context of the computer account when it accesses network resources (such as the Domain Computers group).

Last, be careful in granting users the ability to see logon or startup scripts. This is because, when the script is running, it is running with administrative credentials. So, if there is anything the user might be able to do that would halt the script from processing and then remain in the command prompt, they will continue to have access. And that access is local system access, god-like access, which is not a good thing. So, only show the startup or login scripts during testing, and rescind during your real rollout.

Logon and Logoff Scripts (Non-PowerShell)

The Logon and Logoff script settings are under the User Configuration ⇒ Policies node in the Windows Settings ⇒ Scripts (Logon/Logoff) branch. If you’re implementing new logon scripts, I suggest you follow the steps in the previous section. Again, the user must be in an OU with a linked GPO with a script. However, don’t log off and log back on yet. By default, you won’t see the script run. To allow the script to be visible (and enable you to press any key at the pause), you need to enable a Group Policy. Traverse to User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts, and select either Run logon scripts visible or Run logoff scripts visible, or enable both options.

Logon and logoff scripts run in the user’s context. Remember that a user is just a mere mortal and might not be able to manipulate Registry keys that you might want to run in a logon or logoff script.

Script Processing Defaults (and Changing Them)

One final note about scripts before we move on: different scripting types run either synchronously or asynchronously. Here’s the deal:

1. Logon scripts run asynchronously by default. By default, logon scripts run asynchronously. That is, all scripts at a certain level will fire off at the same time. There is no precedence order for scripts at the same level, and there is no knowing which script will finish before another. If you want to change this behavior to help “link” one script after another, you have to tell the client computer to run the scripts synchronously. If you want to change this (and many times you’ll want to), then find Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts, and enable Run logon scripts synchronously.
2. Bizarrely enough, there is also a setting that does exactly the same thing located on User Settings ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts ⇒ Run logon scripts synchronously. Again, recall that if there’s a conflict between these settings, the ones that affect the computer will “win.”
3. Startup scripts run synchronously by default. By default, startup scripts run synchronously: all scripts are processed from lowest to highest priority order. Then, each script is run—consecutively—until they’re finished. This usually makes the most sense, so I tend to leave it as is. However, if you want to change it, locate Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts, and enable Run startup scripts asynchronously.
4. Group Policy scripts time out in 10 minutes. As stated, if a script just hangs there, you’ll have to wait a whopping 10 minutes for it to time out. You can change this with the policy setting found at Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Scripts called Specify maximum wait time for Group Policy scripts.

Also, before we move on, let’s take a second to talk about “perceived slow” performance when scripts are used with Group Policy. In previous chapters, I suggested you might want to make your Windows machines act like Windows 2000. That is, use the Always wait for the network at Startup and Logon policy setting, which throws Windows into “synchronous” processing mode. There can be a problem with this approach: It can affect you if you have laptops that are not always on the network at bootup. This can cause slower performance. Imagine you have traveling users on laptops with startup and login scripts. By default, the scripts are stored on the Domain Controller. So, during bootup or login time, the laptop tries to connect to the Domain Controller for the script. You may want to dictate to the client to use a local path (like C:scriptslah.vbs) instead of the default, which will go to the server. Ensure that the script is contained within a path that clients cannot write to or they could do nefarious things to the system by replacing the script (which runs as System).

Deploying PowerShell Scripts to Windows 7 and Later Clients

Windows 7 and later machines can accept PowerShell as scripts via Group Policy.

In Figure 12-2, we can see the properties of the Logon script dialog box found under User Configuration ⇒ Policies ⇒ Windows Settings ⇒ Scripts (Logon/Logoff). Similar settings for the computer are found in Computer Configuration ⇒ Policies ⇒ Windows Settings ⇒ Scripts (Startup/Shutdown).

You can add in the script here. PowerShell scripts must have the extension .PS1 or they will fail to execute on the client.

You can decide if you want this PowerShell script to run before or after regular (non-PowerShell) scripts. This setting can be performed on a per-GPO basis (seen here). Or, you can have an overarching policy setting for logon, logoff, startup, and/or shutdown scripts with policy settings located at User Configuration ⇒ Policies ⇒ Windows Settings ⇒ Administrative Templates ⇒ System ⇒ Scripts ⇒ Run Windows PowerShell scripts first at user logon, logoff. And, on the Computer side, there’s Run Windows PowerShell scripts first at user startup, shutdown. Again, the idea is that you might set one of these overarching policies first as a general case but then make an exception right in the script, as seen in Figure 12-2.

Managing Internet Explorer with Group Policy

In the previous edition of the book, I explored four ideas:

1. The death of Internet Explorer Maintenance policy settings
2. Managing IE using Group Policy Preferences
3. Managing IE using Group Policy settings
4. Managing IE using the Internet Explorer Admin Toolkit.

I’m going to drop items #1 and #4 on the list and add in something new for you. In the following sections, we’ll talk about managing Internet Explorer 11’s Enterprise Mode and also managing Internet Explorer using PolicyPak Application Manager.

Let’s get started!

Managing Internet Explorer with Group Policy Preferences

You can set some Internet Explorer preferences settings for users by traversing down to User Configuration ⇒ Preferences ⇒ Control Panel Settings ⇒ Internet Settings and selecting a new Group Policy Preferences item for Internet Explorer 5 and 6, 7, 8 and 9, or 10. It’s a little weird how they’re grouped together that way, but that’s how they are.

But isn’t there Internet Explorer 11? If yes, why don’t we see it in the Group Policy Preferences possibilities in Figure 12-3?

It turns out that when you see Internet Explorer 10, you should really think “Internet Explorer 10 and later,” which of course includes Internet Explorer 11.

Underneath the hood, some Group Policy Preferences have what’s called “hidden filters.” By revealing the under-the-hood XML of a Group Policy Preferences item, you can see the hidden filter, as seen in Figure 12-4.

You can see in Figure 12-5 where I’m using Group Policy Preferences to set the home page to www.GPanswers.com.

We’ve already covered Group Policy Preferences Internet Explorer settings in Chapter 5, but since we’re here anyway, I want to remind you of something.

As you learned in Chapter 5, all Group Policy Preferences items automatically reapply if users try to change them—provided the computer is online and can reconnect to a domain controller to request a refresh of the Group Policy Preferences items.

To change the behavior, and to make it a “one time delivery only” inside the Group Policy Preferences item, select the Common tab and then select “Apply once and do not reapply,” as seen in Figure 12-6.

Again, for more information on this procedure, and also the Group Policy Preferences Internet Settings node, check out Chapter 5.

Internet Explorer’s Group Policy Settings

The Group Policy settings for Internet Explorer are found in (User and Computer Configuration) ⇒ Policies ⇒ Administrative Templates ⇒ Windows Components ⇒ Internet Explorer. Remember, only Group Policy settings are something that users cannot work around.

In contrast, preferences (what we just breezed by again) simply “suggest” a setting and users can work around it. Be sure to read both the Explain text for each Group Policy setting and the requirements. Not every setting is valid for every version of Internet Explorer. So be sure to read and test.

Understanding Internet Explorer 11’s Enterprise Mode

To help organizations walk away from Internet Explorer 8, Internet Explorer 11 has a special compatibility mode called Enterprise Mode.

Enterprise Mode’s job is to accept a list of websites that should be handled differently and then try to format them to be more like what they would look like in IE 8 as opposed to IE 11.

The way this works is a little roundabout, so stick with me. Here’s the basic steps:

• You download the Enterprise Mode Site List Manager tool.
• Using the tool, you specify the sites you want to render differently.
• You specify any special modes.
• This list becomes an XML file.
• This XML file lives on a web server or can be copied locally to the client machine.
• You then use a Group Policy setting to point to where this file lives.

Why the roundabout method? Why not just have a policy setting that could accept a simple list of URLs? Well, Group Policy (in the box) has no way to handle the manipulation of XML files. So there was no way to do this except to first pre-create the file, then use Group Policy to point to that file.

The Enterprise Mode Site List Manager can be found at:

https://www.microsoft.com/en-us/download/details.aspx?id=42501

When it runs, it looks like what’s seen in Figure 12-7.

Once your rules are established, save the file. The usual next step would be to store this on a website somewhere, say http://corp.com/your-old-sites.xml.

You could also copy it to a file share, like \DCshareyour-old-sites.xml, or copy it locally to each machine, say, using Group Policy Preferences, and deliver it to, say, C:sitesyour-old-sites.xml.

Then use Group Policy on either the User or Computer side: navigate to Administrative Templates ⇒ Windows Components ⇒ Internet Explorer and use the Enterprise Mode IE website list policy setting and point to the file, as seen in Figure 12-8.

You can read more about this from Microsoft at https://msdn.microsoft.com/en-us/library/dn640699.aspx.

Three little sidenotes: First, when the target machine picks up the Group Policy Object that points to the list and then processes the list, an unusual thing happens. Internet Explorer takes upward of 65 seconds after Internet Explorer launches. Sixty-Five seconds? Yep, 65 seconds. I read it at the Microsoft link I just mentioned, and then I also confirmed with someone who wrote parts of the code for this within IE 11. So don’t freak out when you don’t see Enterprise Mode for IE 11 work right away as expected.

Second, it should be noted that the Enterprise Mode Site List Manager (and IE 11 itself) gets updated from time to time to handle new modes. Therefore, I would recommend checking out the IE blog and signing up for an RSS feed subscription to any changes. The blog with archived posts is at http://blogs.msdn.com/b/ie/, and the newer one is at http://blogs.windows.com/msedgedev/feed/.

Third, the Windows 10 “modern browser” Microsoft Edge is also supposed to utilize the Enterprise Mode site list and try also to render sites in compatible mode.

Managing Internet Explorer 11 Using PolicyPak Application Manager

When I took a hard look at how fragmented the management experience is between Group Policy, Group Policy Preferences, and now Enterprise Mode, I decided we needed to do something.

So, without going into insane detail, we made a huge effort to “Conquer Mount IE.” We tried to figure out how to manage every aspect of Internet Explorer—versions 8 and later, including IE 11.

Instead of having some preferences items that users can work around and some policy settings that don’t work with different versions of each browser, we have a “Unified Pak for IE” available that handles the ability to manage darn near everything in Internet Explorer and lock it down.

I wanted to especially point out the ability to manage IE 11 Enterprise Mode. We eliminate the need to pre-create the XML site list and give you the ability to dictate the list, on the fly, to either users or computers, directly inside a Group Policy Object.

You can see a demo of that here:

http://www.policypak.com/video/policypak-internet-explorer-11-enterprise-mode.html

A lot of people have told me it was “a real game changer” for them.

The PolicyPak Pak for IE can do a lot, including dictating favorites, certificates, and LAN settings; delivering and removing add-ons; managing pop-ups; and a whole lot more. Again, it will do darn near everything you would want to do with IE.

You can see all the stuff that’s possible in one place here:

www.policypak.com/products/manage-internet-explorer-using-group-policy-policypak.html

Restricting Access to Hardware via Group Policy

You know it’s true: those USB thumb-disk keys and removable media doodads make your personal life easier but your professional life harder. You want a way to control which hardware devices can be installed by users and which can’t.

Thank you, Group Policy, for coming to the rescue.

Imagine this scenario: You allow users to have USB mice but disallow USB thumb drives. You could allow CD-ROM readers but not DVD writers. You could allow Bluetooth but disallow PC Card devices.

You’re in control, letting Group Policy do the work for you.

There are two ways to make this magic happen: one way disables the device, which is nice, but the other way restricts the driver itself from even loading.

The first way uses the Group Policy Preferences Devices extension. The second way is via Group Policy’s Administrative Templates.

Table 12-1 will be the basis of our discussions. Here, we’ll be able to see how the two Group Policy technologies compare and contrast. And when you’re done reading this big section, come back to this table to make your final decision about which one to use. (Or, heck, maybe you’ll decide to use ’em both!)

Group Policy Preferences Devices Extension

In Chapter 5, you learned about the Group Policy preference extensions (and how to install them). One of those extensions is the Devices extension. The Devices extension works for Windows XP and higher, provided the GPPref CSE is already loaded.

The Devices GPPref disables the device or port but doesn’t prevent the driver from loading. The new Devices extension node is found by navigating to Computer Configuration ⇒ Preferences ⇒ Control Panel Settings ⇒ Devices or User Configuration ⇒ Preferences ⇒ Control Panel Settings ⇒ Devices. You can see the Devices extension in Figure 12-9.

Why is it on both sides?

You’ll use the Computer side when you want all users on the same machine to be affected by your edict. Use the User side when you want a specific person to be affected by your edict.

Most organizations will choose the Computer side. That way, everyone on the machine can be restricted from using, say, USB flash disks or CD-ROMs.

Deciding to Disable the Device Class or Device Type

In Figure 12-9, we can see the “Select a Device Class or a Device” dialog. Here you can select a root class, like Ports (COM & LPT), or a specific device, like Communications Port (COM1).

If you choose just the device class, only the “Device class” block gets filled in. If you choose the actual device, then both “Device class” and “Device type” are populated, as seen in Figure 12-10.

What Happens When a Device Is Restricted?

When a specific device is restricted, it is simply disabled, indicated by the little down-arrow icon in Figure 12-11.

However, if you went the extra mile and disabled the class, then, usually, all devices within that class are restricted, as seen in Figure 12-12.

The issue is that, with proper rights, any user could right-click and re-enable the device (also seen in Figure 12-11). Now, by default, regular users (on Windows XP and later) cannot re-enable devices that are disabled like this. But because many organizations run their users as local admins, this could be easy for any admin-user to do. However, because Group Policy preference extensions leverage the Group Policy infrastructure, they take effect during the background refresh (about every 90 minutes or so). At that time, the device will once again be restricted (provided the DC can be reached and the Group Policy Preferences settings redownloaded).

Dealing with Devices That Aren’t Listed

This is kind of a problem with the Devices extension: you cannot specify a piece of hardware that you don’t already have on your management station.

So, while it’s a snap to disable USB ports altogether, it’s a lot harder to eliminate just thumb drives, or something specific like a 30GB color video iPod. In short, the easiest way to disable a device is to track one down and get it hooked into your management station. Then, you’ll be able to just point to it and you’re done.

Now, if you can’t get a hold of the device but you know someone who has one, you might still be in luck. That’s right! Just the very act of knowing someone with the device might be able to help you get out of a jam. Instead of having to schlep that device over to your management station (or make the machine with the device a temporary management station), you can simply ask your pal to tell you what the device properties are and jam them into the XML code of the preference you created. (We covered how to edit the underlying XML code of a preference in Chapter 5.)

Table 12-2 shows what you need from the device property details and how to set them within the XML attribute.

The CSE has to have the deviceClassGUID and the deviceTypeID exactly as they are displayed in the device properties to correctly enable or disable the device.

Why Is There an Option to Disable and Enable?

A keen eye will spot that the Devices extension has both Disable and Enable.

The idea is simple: you can use GPO filtering or Group Policy preference extensions item-level targeting to decide, perhaps, who should get which hardware enabled or disabled. For instance, everyone who gets the GPO will have their USB ports disabled, except for lab technicians, who need USB ports enabled.

To do something like this, you might set the GPO at a high level (maybe a high-level OU or at the domain level) and then set it to Disabled. Then, lower down, say, at the Lab Technicians OU, set the USB ports as Enabled.

Restricting Driver Access with Policy Settings

In the previous section, we talked about the Group Policy preference extensions and how, in using that technology, you can disable devices. That’s great. But you can take it to the next level with two areas of Group Policy. There are two sections of Group Policy that we’re going to talk about now to help you secure your hardware even further:

• Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Removable Storage Access (seen in Figure 12-13)
• Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Device Installation ⇒ Device Installation Restrictions (seen in Figure 12-14)

  

  

The first set (Removable Storage Access) is fairly self-explanatory. If you enable a policy setting for that kind of removable storage (CD/DVD, floppy, and so on), you can make it so that the whole device type cannot be read or written to. But it doesn’t have the “superpower” the second set (Device Installation Restrictions) has.

In the first set, there is a policy setting named Custom Classes: Deny read access and another one named Custom Classes: Deny write access.

There is a difference between the sets.

The Removable Storage Access policy set doesn’t prevent the drivers from being installed. So, the driver for the class will be installed when the hardware is detected, but this policy prevents it from being read or written to.

So we’re about to explore the Device Installation Restrictions policy settings, where we’ll put the real smackdown on the driver itself.

Getting a Handle on Classes and IDs

First, you need to know what you want to restrict. You can think big or you can think small. As with the Devices extension, you can restrict a specific “class” of devices or get super-specific and restrict a single hardware type. Or you can allow only specific device classes, like USB mice.

Here’s the trick: to really be effective, you’re, once again, going to need to track down the hardware you’ll want to restrict.

So, if you want to say, “No joystick drivers can be installed on my Windows 7 machines,” and “Only USB mice can be installed on my Windows 10 machines,” you’ll likely need to get hold of a joystick and a USB mouse. Now, this isn’t always true. You can try to use the Internet to track down one of the following pieces of information:

• Hardware ID
• Compatible ID
• Device class

But, again, it’s much easier if you just have one of these devices in front of you. That way, you can introduce it to a Windows Vista or later machine and see for yourself what the hardware ID, compatible ID, or device class is. Once you know that, you’ll know how to squash it (or leave it available).

In this example, we’ll squash a specific sound card family: a Creative AudioPCI ES1371/ES1373. If you want to squash something else (like specific USB devices or even USB ports), just follow along and substitute the device you want.

To do this, fire up Device Manager on a machine that already has the hardware items installed. Then, when you find the device, right-click it and select Properties and click the Details tab. By default, you’ll see a “Device description.” While interesting, it’s not that useful. Select the Property dropdown and select “Hardware Ids,” as shown in Figure 12-15.

The “Hardware Ids” page shows you, from top to bottom, the most specific to least specific device ID. If you look closely at the topmost item in the “Hardware Ids” value list, you’ll see that this sound card is specifically a Rev 2 of the ES1371 soundboard. That’s pretty darned specific. As you go down the list, the description becomes less specific to encompass the whole family.

Additionally, you can change the Property setting to “Compatible Ids.” These IDs also describe the hardware and are considered less specific than what you’ll find in “Hardware Ids.” You might choose to use the information found in “Compatible Ids” to try to corral more hardware that’s similar into the “don’t use” list—because it’s less specific and might net you more results. The trade-off is that you might restrict something you didn’t want to as you get less specific.

And, finally, the least specific category can be found by selecting Device Class from the Property dropdown. In my case, the sound card shows up as simply Media. But lots of things could be considered Media, so, again, caution should be used the less specific you go.

Once you’ve decided which value you want to leverage, right-click it, select Copy, and paste it into Notepad for safekeeping. Copying it directly as it’s presented is important because, in the next steps, the value must be entered exactly. If there are upper- and lowercase characters in the value, they must be transferred precisely.

Restricting or Allowing Your Hardware via Group Policy

Although we’ll explore all the policy settings located in Computer Configuration ⇒ Administrative Templates ⇒ System ⇒ Device Installation ⇒ Device Installation Restrictions (seen in Figure 12-14), there is really only one policy setting we’ll need to complete this initial example.

Create a GPO and link it to an OU (or domain, and so on) that contains the Windows Vista and later machines you want to control. Then, edit the GPO and drive down into Computer Configuration ⇒ Administrative Templates ⇒ System ⇒ Device Installation ⇒ Device Installation Restrictions ⇒ Prevent installation of devices that match any of these device IDs. Select Enabled in the policy setting, click Show (also in the policy setting), which opens up the Show Contents dialog, then paste in the information from the device you got before. All this can be seen in Figure 12-16.

There’s also a switch inside this policy setting, “Also apply to matching devices that are already installed.” Enabling this switch is a good idea if you want uniform restrictions. As soon as the next Group Policy update occurs, blammo! The hardware is locked out.

When you turn on a machine that has never seen the hardware device, you’ll see the machine try to install the hardware device and provide pop-up balloon status information as to its progress. When it’s completed, the goal is that the hardware is restricted, as you can see in Figure 12-17.

Understanding the Remaining Policy Settings for Hardware Restrictions

In the example we just went through, we squashed the use of just one device. You could, if you wanted, go the opposite route, which is to restrict all hardware by default and allow only some. This can be done using the policy settings described next. Again, you can see a list of these policy settings in Figure 12-14, which shows the Computer Configuration ⇒ Administrative Templates ⇒ Device Installation ⇒ Device Installation Restrictions branch of Group Policy.

Allow Administrators to Override Device Installation Restrictions

By default, local administrators on Windows Vista and later machines must honor the restrictions that are put in place. If you enable the Allow administrators to override device installation restrictions setting, local administrators can install whatever hardware they want.

Allow Installation of Devices Using Drivers That Match These Setup Classes

By entering device descriptions in this policy setting, you’re expressly allowing these hardware devices as “allowed” into the system. Note that the Allow installation of devices using drivers that match these setup classes policy setting honors only setup classes and not device IDs (like those we used in the working example). You can learn more about setup classes at:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx

Prevent Installation of Devices Using Drivers That Match These Device Setup Classes

In our earlier example, we used the device ID to describe our hardware and enabled another policy setting, Prevent Installation of devices that match any of these device IDs. Note that the setting we used does not honor class ID descriptions. To use class ID descriptions, you need to use the Prevent installation of devices using drivers that match these device setup classes policy setting.

There’s also a switch inside this policy setting, “Also apply to matching devices that are already installed.” This is a good idea if you want uniform restrictions.

Display a Custom Message When Installation Is Prevented by Policy (Balloon Text) and Display a Custom Message When Installation Is Prevented by Policy (Balloon Title)

These are two policy settings that help you customize the message, as shown in Figure 12-17. It’s super fun to scare the pants off people with these messages. On second thought, don’t do that.

Allow Installation of Devices That Match Any of These Device IDs

In our earlier example, we used the device ID to describe our hardware. However, I also stated that the least specific way to describe our hardware is based on hardware class. It should be noted that the Allow installation of devices that match any of these device IDs policy setting does not honor class ID descriptions. To use class ID descriptions, use the policy settings Allow installation of devices using drivers that match these device setup classes or Prevent installation of devices using drivers that match these device setup classes.

This setting is best used with another setting, Prevent installation of devices not described by other policy settings. By preventing everything (by default), then using this setting, you can specify precisely which devices you want to allow to be installed.

Prevent Installation of Devices that Match Any of These Device IDs

In our example, Prevent installation of devices that match any of these device IDs is the policy setting we used to restrict a specific type of hardware based on device IDs. If we wanted to restrict using device classes, we would have to leverage other specific policy settings, such as Allow installation of devices using drivers that match these device setup classes or Prevent installation of devices using drivers that match these device setup classes.

Prevent Installation of Removable Devices

The Prevent installation of removable devices setting is a generic and quick way to restrict any hardware device that describes itself as “removable,” including USB devices. I wouldn’t count on this particular policy setting that often. Use the techniques described earlier to get moderately restrictive device IDs and lock them down specifically. This setting is vague enough and there’s no telling what the hardware is telling Windows about itself to be sure it’s locking down what you think it is.

Prevent Installation of Devices Not Described by Other Policy Settings

The setting Prevent installation of devices not described by other policy settings is the catchall policy setting that basically restricts all hardware, unless you’ve specifically dictated that something can install. This policy, in conjunction with the various “Allow” policies (such as Allow installation of devices that match any of these device IDs), can make a powerful combination you can use to allow only the hardware you want in your environment.

Time (in Seconds) to Force Reboot When Required for Policy Changes to Take Effect

The Time (in seconds) to force reboot when required for policy changes to take effect setting appears to be used when removing a driver would require a reboot to take effect. I didn’t have a specific way of testing this, but it seems like a good idea to turn on this setting if you’re about to restrict a lot of various hardware. Note that this policy affects Windows 7 and later machines.

Assigning Printers via Group Policy

Let me guess what another of your biggest headaches is printers, right? Wouldn’t it be great if we could just zap printers down to our Windows machines? Or, whenever Sally roams from Desktop to Desktop, she had access to the same printers?

Those are two different goals, and we’re about to approach both of them here.

Ideally, you’ll use the Group Policy preference extensions to zap printers to your users and computers. With that in mind, let’s explore how to zap printers down to your users.

Zapping Down Printers to Users and Computers (a Refresher)

We explored this subject briefly in Chapter 5, but here’s a quick review.

The Printers Group Policy preference extension exists on both the Computer and User sides. On the Computer side, however, you can’t map shared printers, but only TCP/IP and local printers, as you can see in Figure 12-18. On the User side, you can map all three kinds of printers, as Figure 12-19 shows.

Setting up a shared printer on the User side is easy, as seen in Figure 12-20. Just set the share path to the printer share, and voilà—instant printer for the user. The bonus is that the user doesn’t need to be an administrator to install the drivers that will come down from the server when this connection happens. The Group Policy engine does it on the user’s behalf, so it’s just done, lickety-split.

Trickier: Zapping Down Specific Printers to Users on Specific Machines

Oh, sure, you can use the Printers extension to map a specific printer to a specific user. But that means that no matter which computer a user travels to, he gets exactly the same printers.

But maybe that’s not what you want. I talk with lots of people who have the same problem: how to map printers based on the computer the user is on at that moment.

Take Figure 12-21, for example. Here, you can see four zones:

• Zone 1 with Printer 1: IT computers
• Zone 2 with Printer 2: Human Resources
• Zone 3 with Printer 3: Sales
• Zone 4 with Printer 4: Marketing

And, just for fun, I’m adding an additional challenge: a special circumstance where I have a shared computer in each zone that should not only print to the normal printer in that zone but also map to an additional shared printer specific to the shared computers.

In Figure 12-21, our shared computers are shaded and have the word “shared” in their names. This will be helpful later, as we craft our printing experience.

So the goal is that whenever anyone logs onto any computer in the zone, they get mapped to the printer for that zone.

To achieve the goal, we’ll break this out into two steps:

1. Deploy the specific zone printer to all computers in the same zone.
2. Deploy the shared printer to only the shared computers in all zones.

Deploying the Same Printer to All Computers in the Zone

To accomplish our first goal, we want to make sure all computers in Human Resources get the same printer, Printer 2. You’ll repeat the same procedure for other areas of your universe, but we’ll just show Human Resources as an example.

We’ve already seen how you can’t deploy Shared Printers to computers. That’s a bummer, because our goal is that whenever anyone logs onto a Human Resources computer, he or she gets Printer 2.

And, natively, you can’t do that. (You could do it with Group Policy Loopback in Merge mode, but you may end up getting unintended Group Policy Objects this way.)

But with a little one-two Group Policy preference extensions punch, we can do it without any Loopback hassle.

1. Punch 1: Put an environment variable on all computers in the zone. What we need is a way to tag the specific computers with a little marker, so that once we can see this marker, we can take action on it. We can use environment variables to make this little tag on specific computers, which will indicate that specific computers should use specific printers. We’ll use the Group Policy Preferences Environment extension to do this for us.
2. Punch 2: Map shared printers only to users whose computers have the environment variable. Once we have the little tag on each computer, we’ll use the GPPref Printers extension. We’ll map shared printers to users, but only if the tag is present on the machine that specifies a printer.

Before we get started, make sure your Human Resources OU looks like mine does in Figure 12-22. You can see I’ve got Human Resources Computers and Human Resources Users within the Human Resources OU.

Next, we’ll create a GPO and link it over to the Human Resources Computers OU. We’ll use the GPPref Environment extension to put a System variable on the computer called PRINTER2, and give it a value of 1 (which means true).

The idea is that if a computer in Zone 2 sees a variable with Printer2, that computer should get that printer. You can see this in Figure 12-23.

Then, create a GPO and link it to the domain level (or any higher level such that all the zones you want are covered). I’m calling my GPO “Universal Printer Map for Users.” This GPO will affect all user accounts. It will use the GPPref Printers extension on the User side to map a shared printer, as seen in Figure 12-24.

Now, if we stopped here, we’d have a problem. That’s because, right now, we’re saying, “Everyone should get \dc01printer2,” and that’s not right. What we want to say is, “Everyone should get \dc01printer2—if they’re using a computer that’s tagged with the environment variable PRINTER2=1.”

So, now, click the Common tab in the Printer extension properties. Then, click “Item-level targeting,” as seen in Figure 12-25, and select the Targeting button to open the Targeting Editor.

Add a new item, select the environment variable, and specify that the PRINTER2 environment variable must be set to 1, as seen in Figure 12-25.

If all goes well, two things happen on the client system: the system gets the message that produces the environment variable (and sets its value), and, because of that environment variable’s value, anyone who logs onto that computer with the variable set with the value gets the printer.

Magic!

You can see this magic in Figure 12-26. The command prompt shows the environment variable PRINTER2=1, and the Devices and Printers dialog box shows the newly mapped printer based on the environment variable.

Because this “Universal Printer Map for Users” GPO is linked to the domain, it already affects every user account. And inside this GPO, you’ll want to create a new Group Policy Preferences item for every printer. The goal, again, is to make it such that the mapping of the printer only happens when computers have the environment variable present.

Deploying a Shared Printer to Only the Shared Computers in All Zones

In the previous example, we got everyone to use the specific printer for the computers in their zone.

However, remember that we have one special requirement: we want all the shared computers (in our examples, they’re named Shared1, Shared2, Shared3, and Shared4) to use the same printer: Printer 5. So, this time, we’ll use a trick in the ILT feature to specify that all computers with “shared” in the name will map to the same printer.

To do this, we’ll create a GPO at the domain level called “Special Map for Public Computers” and use the Printers extension on the Users side to map \dc01printer5, but only when the computer name is SHARED-something.

We accomplish this by using the * indicator, as in SHARED*. You can see this in Figure 12-27.

The star will evaluate to true for any computer named SHARED1, SHARED2, and so on.

Now, you’ve done it! You’ve got a universal way to ensure that people get a specific printer based on the specific computer they’re logging onto. Indeed, if you were to log onto SHARED2, which is in the Human Resources Computers OU, you would now get two printers: you’d get Printer2 because you were in Zone 2 (from the first example), and Printer5 because you were on a shared computer, as seen in Figure 12-28.

Implementing Rotating Local Passwords with LAPS

It’s not a great idea to have the same local administrator account’s password on all your machines. Think about it: If I get the password to one of these machines, I own all of your machines with the same local password. This is one of the problems with the so-called Pass-the-Hash security attack.

Remember back in Chapter 5 when we talked about Group Policy Preferences having the ability to manage passwords in local accounts? Well, also remember that functionality is gone, because there was an easy way to reverse and reveal any passwords created with Group Policy Preferences and stored within a Group Policy Object.

So now what do we do?

We don’t want to bake the same local admin password into our build.

We don’t want to (really, can’t set) the local admin password via Group Policy Preferences.

Well there’s a third option and it’s called LAPS: Local Administrator Password Solution.

LAPS is a free add-on from Microsoft that installs (wait for it!) as a Group Policy extension! So it’s very easy to set up and easy to manage.

The general idea of LAPS is that it takes a series of rules (stored in a Group Policy Object) and then based upon those rules, rotates the password and stores them in Active Directory in a special, protected place. And then only the people with security clearance can read those passwords! So even though the passwords are stored in cleartext, only authorized people can view them.

To get started with this walk-through, download LAPS at www.microsoft.com/en-us/download/details.aspx?id=46899.

What to Install from LAPS

There are different pieces you must install to make LAPS operate.

You need to install LAPS (same installer) twice: Once on your machine to manage LAPS and once on the target machines you want to manage. Let’s do these both now.

You’ll want to use the Windows Installer packages that LAPS contains. There’s one for 32-bit machines and one for 64-bit machines.

Installing LAPS on Your Machine to Manage LAPS

Once you click to run the LAPS installer on your management station, you will need to change the defaults so you are only installing the management pieces and not the CSE.

See Figure 12-29 for the ideal configuration.

Installing LAPS on Target Machines to Install the CSE

Then on one endpoint, say Win10, install the LAPS MSI installer, which will install the CSE. In Figure 12-30, see the configuration for installing only the CSE on the target machine.

Extending the Schema and Setting LAPS Permissions

Remember that LAPS has no database. Passwords are delivered from the client computers to a special place in Active Directory. That special place, however, requires a schema extension to Active Directory.

To perform the work, you’ll need to be logged in as the Enterprise Administrator of your organization and then use PowerShell. Start out by importing the LAPS cmdlets as seen in Figure 12-31.

Use the PowerShell command:

Import-Module AdmPws.PS –verbose

and you’ll see all the cmdlets that are imported.

Then run the cmdlet Update-AdmPwdADSchema, as seen in Figure 12-32. When you do, the Active Directory schema is updated to hold the fields. After you do this, the Computer attributes in Active Directory will have these new fields in which to store passwords. The permission on the password field is set as “Confidential.”

Computers need the rights to update this password when it changes. To configure the rights, run the cmdlet Set-AdmPwdComputerSelfPermission against each container and OU, which contains computer accounts. In Figure 12-33, I delegated the rights against the Computers folder (not an OU) and also the Human Resources Computers OU within Human Resources OU.

The last step is delegating Read access. You need to delegate twice here: once for the computers that need access to this field and once for admins who should be allowed to read this field.

So in Figure 12-34 we delegated Write access for the Computers folder (not OU) and also the Human Resources Computers OU. We should now delegate Read access for these same locations. Additionally, delegate Read access for the Active Directory security group you want to have access to read these passwords. In my examples, I’ve pre-created a group called PasswordReaders, but you can call it anything you like.

The syntax would be something like:

Set-AdmPwdReadPasswordPermission –Identity:<DN> -AllowedPrincipals:<GroupName>

So, in Figure 12-34, you can see the two commands:

Set-AdmPwdReadPasswordPermission –Identity:”CN=Computers,DC=corp,dc=com” -AllowedPrincipals:PasswordReaders

and:

Set-AdmPwdReadPasswordPermission –Identity:”OU=Human Resources Computers, OU=Human Resources, DC=corp,  DC=com” -AllowedPrincipals:PasswordReaders 

Using a Group Policy Object to Manage LAPS

If you have no ADMX Central Store set up and are using only local storage, then when you install the LAPS management station pieces, the ADMX files are already in the right place.

If you are using an ADMX Central Store, you’ll need to copy the files named AdmPwd.Admx and AdmPwd.Adml to their proper location. For more information on how to utilize a Central Store, see Chapter 6.

The Group Policy settings appear in Figure 12-35.

Here is a rundown of each Group Policy setting for LAPS.

Password Settings

Inside this policy setting you can set Password Complexity (there are four options), described here from weakest to strongest:

• Large letters
• Large letters + small letters
• Large letters + small letters + numbers
• Large letters + small letters + numbers + specials

Also present are Password Length, and Password Age (Days).

If this is not configured, the default is the strongest type with 14-character passwords and a password age maximum of 30 days.

Name of Administrator Account to Manage

LAPS can only set and manage one local account password. By default, when this value is un-set, it will hit the default local administrator account, even if it’s been renamed. This is because the local administrator account’s SID never changes, even if the account is renamed.

That being said, if you want to dictate another account name to rotate, you can do that in this policy setting.

Do Not Allow Password Expiration Time Longer than Required by Policy

If your actual domain-wide password policy is configured differently than what is set in the LAPS Password Settings policy setting, you can configure LAPS to honor that setting should the two conflict.

Enable Local Admin Password Management

This is the “Master Switch.”

This must be set to Enabled for LAPS to actually do something. This is basically “Turn LAPS on,” and it must be set to Enabled.

The Group Policy Object you create with these settings needs to be linked to a place that contains computer accounts. There’s nearly no downside in linking it to the whole domain, since this process will only work (again) when the CSE is installed on the client machine and proper permissions are granted to the computers you want to perform writes.

Once the Group Policy Object’s settings are set and the Group Policy Object is linked, simply wait for Group Policy to apply on target machines, or run gpupdate manually on your test client.

Using LAPS Management’s Tools: Fat Client and PowerShell

So how do you know if it’s working or not?

LAPS ships with two ways to query the password, which is stored in Active Directory. One is called the Fat LAPS UI (nice name) and the other is a PowerShell cmdlet, Get-AdmPwdPassword.

The Fat LAPS UI is (wait for it…) named “LAPS UI” and can be found right on the Start Menu of your management station. When you run it, it’s a simple dialog box where you enter in the computer name and click Search.

If the computer account is found in Active Directory, and the password value has been set by the computer, you’ll see something like what’s seen in Figure 12-36. You can also use the Fat LAPS client to immediately force a password change request, by leaving the “New expiration time” field blank and clicking Set. Alternatively, you can set a new date/time here for the password to expire if you so desire.

You can also see in Figure 12-36 the PowerShell cmdlet that does the same thing. Use Get-AdmPwdPassword <computername> and, if desired, some optional parameters for formatting the output.

LAPS is a great idea and easy to set up and use. Everyone should be using it to dictate strong local admin passwords. The only hitch I can see is that it does require an Active Directory schema update, but that shouldn’t be a big barrier as it’s nothing to be afraid of.

For more information on LAPS, here are some links:

1. Security advisory

https://technet.microsoft.com/en-us/library/security/3062591

1. LAPS blog

http://blogs.msdn.com/b/laps/

1. For a great walk-through of Pass the Hash and how using LAPS can prevent you from being hacked, check out “Barbarians Inside the Gates: Protecting against Credential Theft and Pass the Hash Today” by Aaron Margosis and Mark Simos from the Ignite 2015 conference. It’s found at:

https://channel9.msdn.com/Events/Ignite/2015/BRK2334

1. And, again, the actual download of LAPS is at:

www.microsoft.com/en-us/download/details.aspx?id=46899

Final Thoughts for This Chapter and for the Book

The cake might be yummy, but we appreciate the frosting first.

In this chapter, we added some frosting to our already hearty, secure, and managed desktop cake. We leveraged login and startup scripts to automate user tasks. We managed Internet Explorer settings using some new techniques. We used hardware control to keep the bad devices off our network and ensured that users had printers exactly when they needed them. And we used LAPS to manage the local admin passwords and store their values in Active Directory in a secure manner.

I hope you enjoyed this book. It was fun to share with you some of my favorite tips, tricks, and insights into Group Policy and Desktop nirvana.

If you’re looking for more stuff from me, here’s the breakdown at both www.GPanswers.com and www.PolicyPak.com.

At www.GPanswers.com, explore the resources like:

• A killer newsletter with Group Policy updates.
• Constantly updated FAQ and “Tips and Tricks.”
• A video series.
• A community room to help get your most pressing questions answered.
• And, of course, my hands-on training to take your game to the next level. You can do this with me or online using my Group Policy Online University (where I’m still available one-on-one to help you through your toughest challenges!). Both classes are hands-on to take your skills even further.

As for PolicyPak, explore the software I’ve helped to create to make you “more awesome” as an administrator:

• PolicyPak On-Premise Suite enhances your ability to manage your applications and maintain your important IT settings on premise.
• PolicyPak Cloud helps manage applications plus extend Group Policy to the cloud.
• PolicyPak Group Policy Compliance Reporter (which we didn’t get a chance to talk about in the book) can help finally answer the question “Did my GPOs and my settings actually make it to my endpoints?”

All PolicyPak Policy enhancements have videos at www.PolicyPak.com and free trials.

Thanks for making it to the end of the book. I hope to meet you in person at a conference or when you take one of my live training classes.

For sure, I’ll see you at GPanswers.com—where smart Group Policy admins come to get smarter!