- Creating the Group Policy Central Store – Updated for Windows 8.1/2012R2 and Windows 10/Server 2016
- Automating Hardware Driver Installation on Windows 7 and Above
- Get-Needle: Searching for Scripts in All the Right Places
Automation is the key to our success. By using Group Policy, we can automate the deployment of software, settings, printers, drive mappings and pretty much anything else for our users and computers. For me, hardware has always been the item that didn’t want to cooperautomate*
Anytime users get new printers or scanners, we have to install the drivers. Most of these drivers come with bloatware and applications that simply are not needed. Windows Vista marked a change in hardware management. This management continues to get easier with Windows 7 and Windows 8. We can now automate driver deployment, driver updates, and hardware management. We can use these methods to automate hardware which makes our users happier and our jobs easier.
In this guide, we will walk through setting a central storage area for drivers, populating that store, getting our clients to use that store, and allowing standard users to load specific drivers. As a real-world example, we will go through the driver installation, extraction, and deployment of a desktop scanner.
Setting Up and Organizing the Driver Store
Most IT departments have shares or drives where we keep our software, virtual machines, or downloaded drivers. We even have a central store for ADMX files in Group Policy. It is time to create our Central Store for Drivers. If you currently have MDT, most of the hard work is done. You can simply use your Out of Box Drivers folder. If you don’t have MDT, you will need to create a network share for driver storage.
With either method, all computers and users should able to read/execute drivers from this share. You can either give “Everyone” or “Authenticated Users” the Read permission on the share and Read/Execute on the folder. No other permissions should be required. For this article, I will be using my Out-of-Box Drivers folder within my MDT DeploymentShare.
In the picture above, you will notice that drivers are organized into sub-folder based on the driver type. If you are using MDT, these drivers are automatically organized for you. If you are having to go the manual route, you will want to spend a few minutes create a folder structure for common devices classes (Printers, Scanners, Video, etc)
Getting Our Hardware into the Central Driver Store
In Windows XP and below, extracting drivers was a nightmare to do by hand. Drivers could be stored in Program File, Application Data, Windows INF, System32, Temp folders … basically anywhere the driver manufacture wanted to put them.
Windows Vista changed all of this.** All drivers, when installed, are loaded into the local DriverStore. The entire packages of any drivers that are installed can be found at C:\Windows\System32\DriverStore\FileRepository\. This makes populating our driver store pretty quick and easy! On your local machine, head to that folder now and sort by date modified. You should now see any recently installed drivers. Sorting this way makes driver extraction simple.
Let’s say that you want to automate a desktop scanner install for your users. To automate the scanner install, we must first put this scanner driver in the Central Driver Store. After installing the scanner driver once, we can open up the locate driver store and sort by date modified. In the picture below, notice the two latest drivers installed.
If you have a manually made Driver store, drag the entire contents of that driver folder over to a sub-folder in your network share. If you are using MDT, import the Driver using the Deployment Workbench. Because we use Selection Profiles, our personal device drivers are stored in a separate Other folder. This folder only exists in the MDT Deployment Workbench.
Getting Our Clients to See the Central Driver Store
We have created a Central Driver Store. Our Central Driver Store now has at least one driver package in it. But as a co-worker of mine always says, “how does it know?” More specifically, how do our clients know where to find these drivers? By looking in the registry!
Open up regedit and navigate to HKLM\Software\Microsoft\Windows\CurrentVersion. Check out the devicepath value. By default, it will contain just %SystemRoot%\Inf. We can extend the search scope by adding in other values.
To make management easier, we will use Group Policy Registry Preferences to do this. Edit a GPO and create a new registry preference. Specify the following:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path: Software\Microsoft\Windows\CurrentVersion
- Value Name: DevicePath
- Value Type: REG_SZ
- Value Data: %SystemRoot%\inf;\\SERVER\SHARE\
First, note the semicolon that separates our entries. Second, be sure to specify your exact central driver share on the value data line. If you have a large driver store (or if you want to speed up driver installations), you can list specific folders. Here is an example:
%SystemRoot%\inf;\\SERVER\SHARE\Out-of-Box Drivers\MultiFunction;\\SERVER\SHARE\Out-of-Box Drivers\Printer;\\SERVER\SHARE\Out-of-Box Drivers\Image;\\SERVER\SHARE\Out-of-Box Drivers\USB
Allowing Standard Users to Install Hardware and Drivers
To completely automate driver installation, standard users should never be prompted for elevated credentials when approved hardware is connected. To do this, the following three criterea must be met:
- The driver must be in a central driver store.
- The driver setup class must be allowed
- The driver publisher must be trusted
We have already tackled the first item by importing our driver. To meet item 2, we must first find out our driver setup class. Do to this, go to the location of the driver in the central driver store. Right click on any .INF files for this driver and click OPEN. At the top of the file, you will see a line named ClassGUID. It should look something like the GUID below. Copy everything to the right of the equals sign (including the brackets). Here is an example:
In a GPO linked to the computers needing the driver, navigate to Computer Config\Admin Templates\System\Driver Installation. Enable “Allow non-administrators to install drivers for these device setup classes.” Paste the GUID that you copied from the .INF. If you wish to prepopulate this list, MSDN contains GUIDs for different hardware types.
The last thing that we have to do is to make sure that whoever signed the driver is a trusted publisher on our machines. You will only need to do this if you are presented with a Windows Security popup like the one below when installing the driver manually for extraction.
If you are presented with this popup, select “Always trust software from …” and press install. After installation, run certmgr.msc. Navigate to “Trusted Published” and then select “Certificates”. Right click on the certificate and click export. This certificate will need to be distributed to all of your computers that will install this hardware. This can easily be done by opening a GPO, going to Computer Config\Windows Settings\Security Settings\Public Key Polices and importing the certificate under the Trusted Publishers Certificates. After importing, you should see the certificate listed (as seen below).
Occasionally, you might have to deploy a driver that isn’t signed. To make this work, you will need to manually sign the drivers (no small feat). Bookmark this page for when you have sign an unsigned driver.
You now have the framework to completely automate all of your hardware installations across your entire organization. Gone are the days of having to individually install drivers, enter in Administrator Credentials for your users (or worse: making users admins so that they can install hardware). If you have any questions (or thoughts), let me know in the comments section below!
*I probably should stick to real words but cooperate + automate makes such a good combination!
**Did anyone else like Vista as much as I did? From a management perspective – it was amazing!