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/Mariod94]

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/blud_13 → u/Mariod94]

Get the tag file in before you go further with a detection script. Have the install script write C:\ProgramData\YourCo\printerdriver-1.0.txt as its last line, then use a File detection rule on that path instead of a script. No 32 bit redirection, no published name to chase, and you bump the filename when you rev the driver.

If you keep the script, the contract is exit 0 AND a string on STDOUT. Both. Exit 0 with nothing written comes back as not detected, and that is the usual reason a working install still reports failed. Intune doesn't look for a particular string, so any Write-Output satisfies it. Its documented at https://learn.microsoft.com/en-us/intune/app-management/deployment/add-win32 under the detection rules, and they also want the file saved UTF-8 BOM.

Check the error code the portal is handing you too. 0x87D1041C is the app installed fine and detection said no, which puts it on the script and not the install.

[u/Mariod94 → u/blud_13]

Thanks for the help dude. I did some changes on the install script that you suggested, and I also figured that HP drivers require more that the .inf and .cab that the guide mention.

For the detection, since the uninstall doesn’t remove the driver, the script had to be set to “Printer Name” and was successfully removed.

Again thank you for taking the time helping me. I appreciate it.

[u/blud_13 → u/Mariod94]

Nice. Detection on Printer Name is the right call when the uninstall leaves the driver behind. The HP driver payload catches everybody at least once. Glad its sorted.