Expert Reference Series of White Papers

Implementing Device
Restrictions in Vista
and Server 2008

1-800-COURSES www.globalknowledge.com
Implementing Device Restrictions in
Vista and Server 2008
Glenn Weadock, Global Knowledge Instructor, MCITP, MCSE, MCSA, A+

Introduction
Limiting the devices that users can install and use has been on the wish-list for IT staff for many years. However,
until Longhorn (the code project that gave birth to both Windows Vista and Windows Server 2008), one had to
turn to vendors other than Microsoft – or implement partially successful Registry hacks. (Of course, you could
always use a hot-glue gun to fill in those USB ports, cheerfully violating your hardware warranty.)

Now, however, with Vista clients and Server 2008 systems, we have a number of new Group Policy settings that
allow us to exert some level of control over which devices users can install and use. The presence of multiple
potentially conflicting policies, and the absence of a friendly wizard to walk us through the various options, sug-
gests that it’s time for another white paper.

First, we’ll take a quick look at the basics of Plug and Play: how its security model works, and the methods it
uses to identify devices. You’ll need to understand those pieces in order to use the specific Group Policy settings.
We’ll look at the device installation policies first, followed by the device usage policies; then wrap things up
with some suggestions on how to target your settings by using Group Policy Object links.

A Plug and Play Security Primer

The way device driver installations work in the Plug and Play worldview makes eminent sense and is worth a
quick review before we look at individual policy settings.

The basic idea is that the installation of device drivers is an act that can be dangerous and, therefore, should
only be undertaken if at least one of two criteria are satisfied.
• T he installer is an administrator and, therefore, has been judged by the organization to have some
degree of responsibility and good sense.
• T he device driver to be installed resides in a preconfigured repository known as the “driver store” (loca-
tion: c:\windows\system32\driverstore on a 32-bit system), which has been configured by Microsoft
and/or system administrators with known-safe drivers.

So, if you’re an administrator, you can install any driver you like, whether it’s in the driver store or not; and if
you’re a standard user, you can install drivers that are in the preconfigured driver store. Imagers and cloners,
take note: you can load drivers into the driver store with the PNPUTIL.EXE command, on a system that you are
preparing for imaging and cloning.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 2

As you will soon see, Group Policy allows us to bend these rules, but you have to understand them before you
can bend them.

Setup Classes and Device IDs

The Plug and Play architecture uses two methods to identify hardware.
• S
 etup classes are in the form of Globally Unique IDs, or GUIDs, such as {4d36e96f-e325-11ce-fvc1-
08002be10318}.
• Device IDs are in the form of English-like identifiers, such as HID_DEVICE_SYSTEM_MOUSE.

You can view setup classes and device IDs through the Windows Device Manager. Right-click a device of inter-
est, choose Properties, and click the Details tab. Under Property, you can choose from the drop-down menu to
see the device ID and/or the setup class IDs.


 Figure 1. Finding hardware identifiers in Device Manager.

Group Policy device restrictions let you specify setup classes, device IDs, or both, when you are blacklisting or
whitelisting devices or device classes.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 3

One benefit of the device ID over the setup class is that often there will be multiple device IDs you can use,
some more specific than others. For example, here’s a list of device IDs for the new wireless optical mouse I just
purchased for my road-warrior laptop; the list shows the most specific ID at the top and the most general one at
the bottom Note: “HID” = Human Interface Device).
• HID\VID_045E&PID_00E1&REV_007&Col02
• HID\VID_045E&PID_00E1&Col02
• HID_DEVICE_SYSTEM_MOUSE
• HID_DEVICE_UP:0001_U:0002
• HID_DEVICE

Depending on how precisely you wish to prohibit the installation of a particular device driver or class of device
drivers, you can use this feature to your advantage. Of course, it can also work against you. I wrote a Vista lab
a couple of years ago that used an overly specific device ID to restrict the installation of flash drive storage
devices. As soon as we switched brands of flash drive, the lab didn’t work reliably anymore! We had to go back
and make the device IDs a bit more generic. So, as with all things Windows, testing is the order of the day.

Using Versus Installing

Another important distinction has to do with a user’s ability to install a device driver versus that same user’s
ability to use an already-installed driver. These are two entirely different things, and the Group Policy settings
that govern them are also entirely different.

The ability to restrict who can install a particular device driver – or, alternatively, who cannot install a particu-
lar driver – is only relevant when the user in question has a machine onto which the driver has not yet been
installed. To put it differently, it doesn’t do you any good to lock users out from installing a specific driver (or
driver class) if that driver already exists on the system they use because the device (or a device from the same
class) has already been successfully connected at some prior time.

Device Installation Control

Location: Computer Configuration > Administrative Templates > System > Device Installation > Device Instal-
lation Restrictions
Setting: Several (see text)

This set of Group Policy settings allows you to control the installation of device drivers based on setup class, de-
vice ID, or both. For example, administrators could define a set of known good, safe drivers that any user, regard-
less of account type, will be permitted to install and use. Taking the opposite approach – a blacklist rather than a
whitelist – administrators could permit users to install all drivers except a known set of problematic drivers.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 4

 

Figure 2. The bulk of the Longhorn device restriction policies live here.

Let’s look at a blacklist methodology first and see which policy settings you might need to implement it. All you
would need to do in this case is prohibit the blacklisted devices. You could do this with either device IDs or setup
class GUIDs, using either of the following policies.
• Prevent installation of devices that match any of these device IDs
• Prevent installation of devices using drivers that match these device setup classes

You could optionally modify the text that a user might see in a taskbar balloon when a device installation has
been prevented. The relevant policies are listed below.
• Display a custom message when installation is prevented by policy (balloon title)
• Display a custom message when installation is prevented by policy (balloon text)

The whitelist methodology is a bit more complicated and involves two steps. First, you explicitly allow the per-
mitted devices, using either of the following policies.
• Allow installation of devices that match any of these device IDs
• Allow installation of devices using drivers that match these device setup classes

Second, explicitly deny all other devices, using the following policy.
• Prevent installation of devices not described by other policy settings

You can exempt administrators from these potentially irritating device installation restrictions with the policy
“Allow administrators to override device installation -restriction policies,” which is probably a good idea, de-
pending on your confidence level in the good sense of your administrators. Of course, if everyone is an adminis-
trator in your network, then enabling this policy would make all the other settings fairly pointless.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 5

Another setting in this grouping is named “Prevent installation of removable devices.” Microsoft is trying to
save us some time here. Instead of going through the drill of identifying all possible removable device classes
and creating explicit policy restrictions for those classes, we can use this setting and block the installation of all
removable device drivers in one fell swoop. Now remember, in this section, we’re talking about device installa-
tion restrictions, not device usage restrictions. You can manage those, too, as we’ll see in a minute.

Restricting Windows Update searches

Location: Computer Configuration > Administrative Templates > System > Internet Communication Manage-
ment > Internet Communication Settings
Setting: Turn off Windows Update device driver searching

Now, there’s another sort of restriction that we should mention: preventing users from getting driver updates
directly from Microsoft. Many organizations have run into issues when users perform a driver update search,
which by default includes Microsoft’s Windows Update site, and get a new driver from that site – without the
organization ever having tested that driver. A Group Policy setting exists to prevent Windows from looking to
the Windows Update site, but the setting is buried so that no normal person would ever find it.

Giving Users More Power

Location: Computer Configuration > Administrative Templates > System > Driver Installation
Setting: Allow non-administrators to install drivers for these device setup classes

Despite the typical use of Group Policy as a restrictive mechanism, you may decide to use Group Policy as a
liberating force, giving users more power than they would have otherwise. Using Group Policy this way has a
special appeal when it means that users won’t have to call Tier 1 support as often when they need to install a
device driver.

So, with this setting, you can explicitly allow non-administrators (i.e., members of the Users group) to install
drivers for specified device setup classes (the GUID kind), which, as we discussed above is not the default
behavior for drivers that live outside the driver store. A common application of this policy setting is to permit the
installation of particular printer drivers, but it is not limited to printers by any means. This Group Policy setting is,
in effect, a way to delegate certain device installation rights to members of the standard Users group.

Why on earth Microsoft chose to put this setting in a separate node named “Driver Installation” when all the
other settings are under the node named (synonymously) “Device Installation” is beyond my ken. The only other
setting here has to do with whether administrators should be prompted to look for device drivers on the Win-
dows Update site. Both could easily have been co-located with the other driver-related settings in the “Device
Installation” node.

One caveat is that this policy only works for signed device drivers. Unsigned drivers will still generally need to
be installed by administrators.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 6

Removable Storage Usage Restrictions


 Figure 3. Securing removable device usage rights.

Location: Computer Configuration > Administrative Templates > System > Removable Storage Access
Setting: Several

Remember that in the Device Installation Restrictions section a bit earlier in this white paper, you could perform
a blanket restriction on the installation of removable devices? This section, by contrast, deals with usage rather
than installation. With the policies in this section, you can deny read access, write access, or both, to the follow-
ing device types.
• CD and DVD
• Floppy drives
• Removable disks
• Tape drives
• WPD devices (media players, cell phones, PDAs, etc.)
• Custom classes (which you can define by device GUID)
• All of the above

Again, you can use Device Manager to discover the GUIDs for the specific devices you may wish to restrict using
the “custom classes” option. Note also that if you disable all removable storage devices, you can come back and
permit access to removable storage devices in remote sessions.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 7

Scope of Device Restriction Settings
As you have been reading through this paper, you may have been thinking to yourself that some of the settings
we have mentioned might be appropriate for some subsets of your user population, but not for others. That, of
course, is the beauty of Group Policy: you can create Group Policy Objects and link them to particular sites, do-
mains, or organizational units (OUs). For example, if you have an OU named ITAdmins, you may not want to link
any restrictive GPOs to that OU; but if you have an OU named ClericalStaff, you may want to link one or more
restrictive GPOs to it.

The tool you will typically use to create, manage, and maintain GPO links is the Group Policy Management
Console, or GPMC. Note that although it shipped with the original release of Windows Vista, Microsoft excised
it as of Vista SP1. You can still get it, but you need to download the Remote Server Administration Tools (RSAT)
for Vista. (Careful, there’s a different version for x86 and x64 systems.)

Although this next technique is not quite as harmonious with the spirit of the Group Policy architecture as using
links, you can also exempt specific Windows security groups from GPO processing using a technique known as
security group filtering. This method could be useful, for example, if your OU layout does not map well to the
intended scopes of device restriction settings.

Conclusion
Group Policy has never been a rock-solid method for securing a Windows network – it’s too complicated, and
has too many “gotchas,” for that – not to mention the fact that anyone with local administrative rights and
some RegEdit savvy can usually circumvent most Group Policy restrictions.

That being said, and within the universe of Longhorn clients and servers, we now have some reasonably powerful
settings that enable us to exert more control than ever before on who does what with which hardware devices.
Depending on the mix of Help Desk calls in your organization, these settings may be worth the time and effort it
takes to understand, test, and implement them. This is especially true if you consider the savings in hot glue.

Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.
Check out the following Global Knowledge courses:
Managing and Maintaining Server 2008
Migrating to Server 2008
Configuring Windows Server 2008 Active Directory Domain Services
Designing a Windows Server 2008 Active Directory Infrastructure and Service

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a
sales representative.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 8

Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our
expert instructors draw upon their experiences to help you understand key concepts and how to apply them to
your specific work situation. Choose from our more than 700 courses, delivered through Classrooms, e-Learning,
and On-site sessions, to meet your IT and management training needs.

About the Author

Glenn Weadock is a longtime instructor for Global Knowledge and co-author of two new Microsoft Official Cur-
riculum classes on Server 2008. He consults through Independent Software, Inc. and does software development
for MarketCoach Investment Education Software, LLC. Glenn is the author of 18 computer books and lives in
Golden, Colorado.

Copyright ©2009 Global Knowledge Training LLC All rights reserved. 9