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!
Hi Joseph,
I have set everything up per your instructions but i am running into an issue where when i connect my device which is a camera,windows 7 installs a default driver (Hp basic camera) instead of the driver stored in my repository (Motic Driver). When i go to device manager and update the driver manually i see that the driver is listed but i was wondering why it does not install the motic driver as soon as the device is connected.
I’m not sure – could you remove the default driver from your machines?
Hi,
I have tried that but for some reason it still installs the default driver even after removing it.
Hey Joseph,
I’m working on getting MDT setup and adding all of our driver packs to deployment workbench. We are both a Dell and a Panasonic shop here, so far I have only been working on the Dell side and I have been getting some of the CAB files from Dell to popup saying can’t divide by zero. Have you seen this and have a solution for this?
Matt
I haven’t seen that issue yet. Did you get it resolved? If so, what was the problem?
I did get them all installed finally. I had noticed that when I started installing the drivers on my production server I was getting the error on ones I had successfully installed in my test environment. So I just kept re-downloading and adding them till I finally got them all in without the error. Perhaps they were getting corrupt when downloading? Not sure just glad I finally got them all in.
Thanks!
Very cool Matt! Glad you got it sorted out!
Yes I confirmed that the drivers installed to the Driver FileRepository. It updated 2 folders, I copied them both to the depository on the network. That did not work, I also tried doing a complete install of Logitech QuickCam and copying all drivers created and that did not work either. Still get prompted for admin credentials.
PS Not sure why there is no option to reply to your last comment so I had to start a new thread.
I am at a loss Kel – you meet all of the requirements. Do let me know what you find out though – I am very interested.
Well from what I can see the issue is with the Logitech drivers. They have a “Finish Install Action”. This launches some type of check for updates. This is what is causing the credentials prompt. If the user doesn’t enter admin credentials the driver reports back as a failed install.
I have found information on disabling the “Finish Install Action”. http://iboyd.net/index.php/2010/06/29/ati-radeon-causes-a-uac-prompt-at-user-logon/
But this can only be done if the registry keys are already created. For the webcams the keys don’t get created until the cam is plugged in and by then the user already receives the prompt and the error is returned. So unless I can find a way to disable the “Finish Install Action” I’m kind of stuck.
FYI. Pre-populating the necessary registry keys does not work either, driver fails to install completely.
We are trying to implement these settings in our corporation. The share has been created and has the correct permissions, the registry of the workstations has been updated to point to the share for drivers, the drivers are on the share and the GPO is set to allow non-admins to install for this device class.
But users still get the UAC prompt when plugging in a device.
We are currently testing with a Logitech Webcam
Ensure that the drivers are signed as well.
Yes, the driver is signed
If you log on as admin, will the driver self install?
Yes, If I login as administrator and connect the device the drivers install without any interaction.
Hmmm….
Can you confirm that the device is not calling any other drivers that the ones that you have approved? You can let the driver install as an admin and check C:\windows\System32\DriverStore\FileRepository
Great post.
I followed your instructions but run into a problem.
My testdriver is a Samsung ML 371x Series Driver.
I took the files from C:\Windows\System32\DriverStore\FileRepository\, placed it in my new central driverstore (without MDT). After that I set the GPO settings to allow nonadmins to install the ClassGuid Drivers and set the DevicePath to “%SystemRoot%\inf;\\SERVER\SHARE\Printers” (my sharename of cause 😉 ).
I started my test PC (Win7), checked the GPO and Registry and everything is fine so far. Than I pluged in the Printer to a random USB port and nearly imediately the driver window pops up and says “Driver not found”. When I go to the printer and say, search automaticly for a new driver, it looks at my DevicePath location and installs the driver like a charm. Have you any idea where I’ve got the mistake at my plug&play installation?
I had a similar configuration at Win XP, except it was scripted and the DevicePath where a local folder and the printer works fine with plug&play.
If someone is interessted in my problem solution.
I had problems with the share permissions. I set the NTFS-rights on the folder but forgot about the share-permissions of our netapp.
Now everything works fine.
Thanks again for the post.
Thanks for the update (and resolution) Chris! Sorry I wasn’t able to get back to your first comment earlier.
Hey, glad to see this post updated to include your MDT structure! Now, just curious, if we are using MDT, I would think we probably want to stick to importing the driver using the workbench right? Instead of dragging the folder from the local store to the network share?
You are completely right about using the workbench for automatic sorting! I added that step in for people using MDT. Thank you for highlighting that.
Wow, this sounds like an awesome idea. Question though: will Windows still look for drivers in the store on the client computer or do I need to make sure to copy all of the default drivers in the local FileRepository from a default Windows installation to my new central repository? I’m just thinking in the case where maybe I don’t have the drive in the central repository, but its already included in Windows in the local repository. Thanks!
This idea saves us some serious time! Windows will still look locally first.
Do you still inject drivers via MDT? I was going to follow your 4Sysops guide on creating an Other selection profile to inject drivers for printers/scanners/etc during the task sequence. I’m just wondering where this central repository fits into the picture. I’m trying not to be redundant and repeat tasks I don’t need to repeat. Thanks for your help!
I do. We now use the Out of Box drivers folder as our central driver store. It makes deployment very easy!
What does your Out-Of-Box drivers folder look like? In MDT, I create subfolders for OS and then architecture (ex: OOB>Windows7>x64). I then import my drivers into the architecture specific folder.
But looking at what the Out-Of-Box drivers folder really looks like in the deployment share, it doesn’t follow the structure in the MDT workbench. Instead it is broken into folders based on categories it looks like (Display, hdc, Media, USB, net, etc). I don’t see anything about Operating System or architecture. So, I guess I am wondering should I point my clients to the root of the OOB drivers folder? If so, how does it know to use a driver for Windows 7 x64 for example vs. a driver for Windows 8? Thanks again for your help. I just finished setting up my BIOS repository and my task sequences to update the BIOS 🙂
My folder structure is the same. With MDT, sorting by architecture or OS first doesn’t matter. MDT does the real sorting in the background. When you point your clients at the OOB folder, the clients will read the driver description to see what matches. This is how it knows to use a Windows 7 X64 driver instead of a Windows 8 X86 driver.
Setting up automatic BIOS updates is awesome! Keep on automating!
Seriously, this is awesome!
This has helped so much!