Installing unsigned drivers

(imported topic written by mleeser91)

I have several tasks to install print drivers. Some of these have to use unsigned drivers. In the past these tasks would pop-up a window on the client and the user was able to select “Continue Anyway" to install the drivers. I’m not sure if it was updating to the latest version of Tivoli or possibly a windows update but these tasks no longer prompt the user so the drivers do not get installed.

Below is an example of the task:

wait “{pathname of system folder}\rundll32” printui.dll,PrintUIEntry /if /b “STOFCC KM-C451” /f “C:\drivers\printer\KM-C451\KOAZJK__.inf” /q /r “IP_192.168.58.10” /m “KONICA MINOLTA C650 Series PCL” /z

Running the above command from Bigfix does not pop-up any windows, it says it completes but does not install the printer.

Running the same command from a command prompt pops up a window that says “The software you are installing has not passes windows logo testing …" and you must select “Continue Anyway" to complete the installation.

Bigfix used to pop-up this same window when the task was run but it no longer does.

Running the same task from Bigfix using a signed driver works fine because no user input is required.

Does anyone have any ideas how to get this working again or what broke it?

(imported comment written by SystemAdmin)

Your options include pushing back on the vendor to sign their code, paying M$ to sign the driver (if you can twist their arm), or signing it with an internal trusted enterprise CA that your clients would trust.

(imported comment written by mleeser91)

Thanks for the info. It looks like I’ll have to sign them all myself.

Any ideas why this would stop working? I used to just tell my users to click on “Continue Anyway” and the drivers and print queue would install fine.

I was hoping there was an easier fix. Even if I set the client to Ignore driver signing the BigFix action still fails if it is an unsigned driver.

(imported comment written by MattBoyd)

Is the latest version of that print driver ( not signed?

(imported comment written by mleeser91)

Yes that one may have a new version that is signed. I picked a bad example, we have several differential makes and models that I’ve made fixlets for. I will need to go through each of them to see which ones are still unsigned.

(imported comment written by MattBoyd)

So go figure, I had to handle a similar situation today. I went with the self-signed driver approach. I followed the general instructions here (except for 32-bit): If you run into errors, read them closely and/or Google them. More details are here:

The most annoying part of the above process is rounding up the utilities (inf2cat, makecert, and signtool). I believe they’re in the WDK. Fortunately, I already had it installed on my workstation, but I recall it being a large install. Also note that this will not work on 64-bit Windows 7 since it requires all drivers to be signed by a valid authority (not self-signed).

Once I had the drivers signed, I used BigFix to add the fake certificate to the trusted root authority and trusted publisher stores. Here’s what my action script looked like:

// Since these are self-signed drivers, we need to add the certificate to the root and trustedpublisher store
waithidden certutil -addstore root __Download\FakeCert.cer
waithidden certutil -addstore trustedpublisher __Download\
waithidden certutil -addstore trustedpublisher __Download\

//Installs silently (no warnings!)
waithidden pnputil -i -a __Download*.inf

Hope that helps…

Edit: It should be mentioned that using a self-signed certificate and adding it to the root and trusted publisher stores on your workstation is NOT considered best practice and could technically be considered a security issue. I suggest reading up on driver signing and the root certificate store before performing this procedure. I only had to do it on a handful of workstations as a temporary solution.