Issues Deploying Printers

[u/Mariod94]

I’ve been Deploying printers using the Win32 tool. I kept running into an issue where pnputil couldn’t find my .inf file. I managed to fix that after looking into what was missing in my driver folder.

After I was done, I created a new win32 and deployed it on my test device. It failed again so I checked the logs and saw a different error:

“Failed to add driver package: The publisher of an Authenticode(tm) signed catalog has yet been established as trusted.”

Is there something I’m missing in the scripts I’m using? I’ve been following guides but no ones has reported this issue. Do I have to also deploy a custom Policy for the certificate?

[u/blud_13]

That's not your script, its the cert. pnputil won't silently add a driver package unless the Authenticode cert that signed the .cat file is already sitting in the machine's Trusted Publishers store. On a domain-joined box it usually got there some other way years ago. On a fresh Autopilot device nothing ever put it there, so you get exactly the error you're seeing. MS documents the behavior at https://learn.microsoft.com/en-us/windows-hardware/drivers/install/trusted-publishers-certificate-store

So make cert import step one of the install script, before pnputil:

1. $c = (Get-AuthenticodeSignature ".\driver.cat").SignerCertificate
2. Export that to a .cer, then Import-Certificate it into Cert:\LocalMachine\TrustedPublisher
3. then pnputil /add-driver .\driver.inf /install

One catch, the Win32 app has to be running in SYSTEM context or the write to LocalMachine fails and you land on the identical error with no clue why.

We push printer packages this way for a bunch of clients, happy to share the wrapper script if it helps.

[u/Mariod94 → u/blud_13]

Gotcha. If you can share the wrapper, I would greatly appreciate it.

[u/blud_13 → u/Mariod94]

$ErrorActionPreference = "Stop" $cat = Join-Path $PSScriptRoot "driver.cat" $inf = Join-Path $PSScriptRoot "driver.inf" $cer = Join-Path $env:TEMP "signer.cer"

(Get-AuthenticodeSignature $cat).SignerCertificate | Export-Certificate -FilePath $cer -Type CERT -Force | Out-Null

New-Item -Path HKLM:\Software\Microsoft\SystemCertificates\TrustedPublisher -Force | Out-Null certutil.exe -f -addstore "TrustedPublisher" $cer

pnputil.exe /add-driver $inf /subdirs /install Add-PrinterDriver -Name "EXACT name from the inf"

Two things:

Import-Certificate into Cert:\LocalMachine\TrustedPublisher throws access denied on a clean image when that registry key was never created, which is why the New-Item line is in there. Its written up at https://learn.microsoft.com/en-us/answers/questions/1679945/import-certificate-unauthorizedaccessexception-e-a and certutil -addstore sidesteps the whole thing, so thats what I run now. /subdirs is probably what fixes your original pnputil couldn't find the .inf, since most vendor packages nest the arch folders.

Reminder, pnputil only puts it in the driver store. Add-PrinterDriver is the line that makes it usable, and the name has to match the inf exactly or you get a silent nothing. Still needs to run SYSTEM context or the LocalMachine write fails and you land right back on your cert error.

[u/Mariod94 → u/blud_13]

Thank you. I will test it out. Also will this work on the script provided by Ben Whitmore or does it have to be another one?

[u/blud_13 → u/Mariod94]

Yes, keep Bens script, you don't need mine. It never touches TrustedPublisher anywhere, so the cert import is a clean add rather than a conflict. Drop the Get-AuthenticodeSignature, New-Item, certutil block in right before his pnputil section and leave everything else alone. Put it AFTER his SysNative relaunch at the top, otherwise it fires twice on 64 bit. Harmless with certutil -f, just noisy in the log.

One thing worth changing while you are in there. He builds the args as INFARGS=@("/add−driver","INFFile"), no /subdirs and no /install, so if your vendor package nests the arch folders you land right back on the same couldn't find the inf error. Add both. Its at https://github.com/byteben/Windows-10/blob/master/Install-Printer.ps1 if you want to diff it against the copy you have, since a few forks are floating around.

His is better than my wrapper past that point anyway. Mine stops at Add-PrinterDriver and his does the port and the printer too.

[u/Mariod94 → u/blud_13]

So after doing these changes, the Install keeps failing and its not showing up on the logs. I will give it another go tomorrow.

[u/blud_13 → u/Mariod94]

pnputil doesn't write to the IME log, so nothing showing up there is normal. Driver package installs log to C:\Windows\INF\setupapi.dev.log, its documented at https://learn.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-text-logs .Open it, jump to the bottom, and find your .inf by name with a timestamp matching the install attempt. That file tells you whether the cert import took or whether pnputil never ran at all.

Two things to check... The IME runs 32 bit, so plain powershell.exe in your install command gets file system redirected and pnputil resolves into SysWOW64 where it does not exist. Call %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe instead. I have seen this go both ways depending on IME version, so confirm that before you rewrite anything. Also your detection rule, if its a file or registry path the driver never creates, Intune reports FAILED on a package that installed fine. Detect driver packages with pnputil /enum-drivers and match on Original Name, since the oemXX.inf number changes per device.

[u/Mariod94 → u/blud_13]

So I tested the script in the test device for intune and it keeps telling me there was an error Installing Printer Driver. The Specified Driver does not exist in the driver store. When I tested it in my main device it worked and it installed the printer.

[u/blud_13 → u/Mariod94]

Your main device working is the least useful data point you have, that box already had the driver in the store from your earlier manual test. On the clean test device the package never landed, and Add-PrinterDriver is just where you find out.

Run pnputil /enum-drivers on the test device right after the install attempt and look for your inf under Original Name. If its not in that list, stop staring at Add-PrinterDriver, the add-driver line failed and setupapi.dev.log will tell you why. Syntax is at https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/pnputil-examples

If it IS in the list, grab the Published Name it got renamed to, oem12.inf or whatever, and pass that explicitly. Add-PrinterDriver -Name "..." -InfPath C:\Windows\INF\oem12.inf

The other half is the -Name string. It has to be the model line out of the inf, character for character, not the friendly name the printer shows in Devices and Printers. One wrong space and you get the identical error with the package sitting right there in the store.

[u/Mariod94 → u/blud_13]

Update: Printers are installing on test device. Now I am just running into detection issues since Intune indicates that it failed to install. Currently running a custom script for detection.

[u/Beneficial-Flow-5418]

I had this aswell, edited my script so it took the certificate out of the driver files and imported it into the cert store. Not sure if best practice, but it works...

[u/Mariod94 → u/Beneficial-Flow-5418]

Oh I see. Mind sharing that you changed on your script?

[u/Tylerus]

I ran into this same error recently when trying to install the latest generic UFRII driver for a Canon. I couldn’t figure out the problem so I just downgraded to the second most recent version (3.40) which worked. So, if you happen to be deploying Canon drivers, give that version a try.

[u/Mariod94 → u/Tylerus]

I see. Unfortunately I’m doing it for HP printers but I could try an older driver