. Automating Hardware Driver Installation on Windows 7 and Above. 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. 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. 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: HKEYLOCALMACHINE.
Key Path: Software Microsoft Windows CurrentVersion. Value Name: DevicePath. Value Type: REGSZ. 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).
Hp Printer Drivers Download
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, 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).
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! 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”. 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. Pre-populating the necessary registry keys does not work either, driver fails to install completely. 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. What does your Out-Of-Box drivers folder look like? In MDT, I create subfolders for OS and then architecture (ex: OOBWindows7x64). 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.
Epson Printer Drivers
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 🙂.