pnputil not working
-
Thursday, January 24, 2013 3:15 PM
I am having problems getting the pnputil command to work on my system. Maybe I misunderstand how it is to work.
Here is what I am doing. I am booting a Windows Server 2012 environment from and iSCSI LAN. During installation, because my NIC driver is not part of the Windows distribution, I load the driver so I can recognize the iSCSI LUN. Works fine. I complete the install and all is well. However, I have other NICs on my system that all use the same driver. If I go into Device Manager I can manually update each NIC that shows a problem by simply updating each NIC with the driver that is already on the system. So I am sure the driver is being properly recognized by Windows and the NICs work fine after updating their driver.
But, I don't want to manually go through an update each NIC. I would rather issue the command:
pnputil -i -a driver.inf
Here is what happens on my system.
Is there something special required in the .inf file that is required for it to work properly with pnp? Part of my curiousity on this is that I seem to recall that I tried injecting the an earlier version of this driver into a .wim image, and when I installed from that image, it did not get installed automatically, i.e. I still had to manually update the NIC drivers.
Any pointers greatly appreciated.
.:|:.:|:. tim
All Replies
-
Monday, January 28, 2013 8:07 AMModerator
Hi Tim,
What's the result if you perform "pnputil /a enic6x64.inf"? Will it list a published name? If so try pnputil /i <published_name> instead.
- Edited by Shaon ShanMicrosoft Contingent Staff, Moderator Monday, January 28, 2013 8:07 AM
-
Monday, January 28, 2013 3:23 PM
When I do a pnputil -a enic6x64.inf I get this back.
Microsoft PnP Utility Processing inf : enic6x64.inf Driver package added successfully. Published name : oem1.inf Total attempted: 1 Number successfully imported: 1
I can't find any combination of entries that will allow me to enter anything but a valid file name for the pnputil -i portion of the command, i.e. it does not accept oem1.inf. According to the help file, the only valid combination with the -i switch is in conjunction with the -a switch.
If I do a pnputil -e, I get this back.
Microsoft PnP Utility Published name : oem1.inf Driver package provider : Cisco Systems, Inc. Class : Network adapters Driver data and version : 10/31/2012 2.2.0.13 Signer name : Microsoft Windows Hardware Compatibility Publisher Published name : oem0.inf Driver package provider : Microsoft Class : Printers Driver data and version : 05/21/2006 6.2.9200.16384 Signer name : Microsoft Windows
Does the -i option only work if the driver is not already installed? Since I installed a copy during the boot process, the driver is installed on the system, but for whatever reason, the Windows PnP is not picking it up when it is detecting all the other NICs that use the exact same driver. I was hoping that this command could force PnP to reuse it. Maybe it's beyond the scope of this command and something needs to be changed in our inf file so that it operates correctly PnP?.:|:.:|:. tim
-
Thursday, January 31, 2013 11:16 PM
Well, it is getting stranger. I built another system that booted locally instead of booting from iSCSI. Issued the pnputil command and it properly updated all the NIC drivers. The difference was that instead of using the .inf file that was on the system, I read it in from my distribution CD.
So, I figured, let's try it on one of the iSCSI booted systems by using the file directly from the CD (yeah, I know, the files are the same, but I'm grasping). Same results as before - failed to install the driver on any of the devices in the system. Well that sort of struck me because I had already manually updated all the drivers, so of course none would be installed. Therefore, I added another NIC to the iSCSI booted system, used the file from the CD, and still ended up with the same results.
What appears to be happening is that pnputil works fine if the driver being reference has NOT been installed on the system for any device. If it does not find the device on the system, it works just hunky-dory.
Bug? As designed? Curious minds would like to know.
.:|:.:|:. tim

