Wrong Print driver being sent to clients

[Jaan]

Hi all,

 

I'm stumped with this one. I've just never seen it before.

 

We've had new printers over the holidays along with type 4 drivers. All deployed via GPO and print management. We also use Papercut to control printing.

 

The printers installed on the print server have the drivers "generic universal v4 PCL" as installed and setup by our print suppliers.

 

The printers are deploying/installing and working on our Clients, however it installs "Microsoft enhanced point and print driver" which has lots of missing options in the driver...... this mainly is affecting our repro department.

 

Anybody else seen this behaviour?

 

Our suppliers are looking into it but have never seen (or noticed it before)

 

Server 2019 and Win10 1809 LTSC.

 

Cheers all

[Jaan]

Just found this on Papercut's site.

 

Type 4 drivers on the print server are never downloaded to the clients

This is by design and expected. When the Type 4 driver used on the server does not exist on the client system, Windows will use the client’s preinstalled “Microsoft enhanced Point and Print compatibility driver” to build the connection to the shared printer.

 

This driver may not have the same feature set as the Type-4 driver that is on the queue on the server.

 

So i guess the next issue i've got is that as the type 4 drivers don't exist on the client and it can't get them from windows Update i have to get them there.....

 

 

We have PDQ and mainly use GPOs. NOt got much powershell experience.

 

How are you guys doing this?

 

Cheers (again)

[psydii]

This response won’t be of much help, probably:

 

By sticking with type 3 drivers.

 

Also if no immediate help, but to add to our headache:

 

https://www.theregister.com/2023/09/11/go_native_or_go_home/

[Jaan]

Just an update to this, i've managed to get it working on my Admin pc. I haven't started testing non admin client machines yet.

 

It still displays the Microsoft driver in print properties, however it does use all the advanced features.

 

Basically I had to add the print driver to the client driver store. To do this I had to "deploy" the driver from a network accessible location to the client. The Printer is still deployed via GPO.

 

I used the below command in powershell to manually get the driver to the client (sat at the machine logged in as admin)

 

pnputil /add-driver "\\network.net\Deployed Resources$\Print Drivers\2023\KOBxxKA_01.inf"

 

This worked great and ONE of the reprographics computer is up and running with all the adviced feature..........

 

......... but it only work on my Admin PC and the ONE client computer........ i get an error when trying to install on another two pcs (including another it admin machine and account.

 

the errors says unable to find the file specified........ not sure why this has started...... maybe i just need a coffee because the path is 100% right.....

[psydii]

does the admin account you used on the second/other machine(s) have rights to see the share/folders where the driver is? local admin accounts without rights to common sysadmin network shares catch members of my team out on a regular basis. Tripple check by mounting a drive to the share and browsing around from there.....

 

also another thing that I've seen produce those symptoms is trying to run a command from an invalid drive... e.g. the cmd prompt says your are at n:\ but the share backing that location is offline/gone/invalid permissions... then most/all commands run from the commandline fail. Solution is to change the current working drive to something that exists (typically c: )

Edited September 14, 2023 by psydii

[psydii]

TBH I'm slightly surprised nobody has said Papercut Print Deploy is the way to do this most effectively. I'd heard good things about it.

https://www.papercut.com/discover/easy-printing/network-printer-deployment/#why-is-printing-difficult

[alanmorris]

@Jaan, this is by Microsoft design. The driver used on the client system when you set up a shared printer using a Type 4 print driver will never be copied from the server.

 

We discuss this behavior in this article. https://www.papercut.com/kb/Main/WindowsType4PrintDrivers/

 

[h=3]Type 4 drivers on the print server are never downloaded to the clients[/h]This is by design and expected. When the Type 4 driver used on the server does not exist on the client system, Windows will use the client’s preinstalled “Microsoft enhanced Point and Print compatibility driver” to build the connection to the shared printer.

This driver may not have the same feature set as the Type-4 driver that is on the queue on the server.

[alanmorris]

@Jaan , to answer this specific question: Anybody else seen this behaviour?

 

Yes, I have seen this behavior since 2011 with the first Windows 8 / Server 2012 preview builds. It's been the design for the past 12 years.

 

With Type 4 print drivers, software is delivered to the client system using Windows Update and never the print server.

 

I have seen the WU path not working recently so I am guessing that Microsoft broke the behavior or "designed" the behavior so it's not longer working.

 

Thanks

 

 

 

[Jaan]

I understand this is by design now. The next task is to get the driver on the client so that i can use the advanced features of the driver.

 

I have got this working.......kind of. as per my post #4 i'm running pnputil /add-driver to add the driver to the clients driver store. IF this works i then get the advance features of the print driver.

 

I'm doing manual testing at the moment, manually running pnputil /add-driver "\\nsnet.net\Deployed Resources$\Print Drivers\2023\*.inf" (i've also tired without the *.inf wildcard and called the driver by name..... no difference.

 

Any ideas why i would get the two different responses below? This is being ran by myself on a classroom of computers, they have the same GPOs applied.

 

 

[Jaan]

Anybody got any thoughts?

 

I'm so close yet so far! i've got it working in some instances, but in others i'm getting "failed to add the driver package: the system cannot find the file specified"

 

EDIT:Running as a system admin from this location "Z:\Network Shares\Deployed Resources\Print Drivers\2023" also gives the same error if i run pnputil /add-driver "Z:\Network Shares\Deployed Resources\Print Drivers\2023\*.inf"

Edited September 20, 2023 by Jaan

[altecsole]

Anybody got any thoughts?

 

I'm so close yet so far! i've got it working in some instances, but in others i'm getting "failed to add the driver package: the system cannot find the file specified"

Sorry, I can't say whether this will work for you, but it may be worth a try, as this is how we add printer drivers to workstations. We then use a logon script to add printers.

 

We use a startup script that pulls the driver from the DriverStore\FileRepository on the server - we have a read-only share for the folder.

 

The script uses the built-in Printing_Admin_Scripts to add the driver.

 

Here is an example for one driver, the other drivers are the same, but obviously the printer name, and .inf file is different. The driver name must match the driver name on the print server.

 

@echo off

SLEEP 5

 

:INSTALL_DRIVERS

echo %time% on %date% > C:\PDrivers.txt

 

echo Install Kyocera ECOSYS P2135dn KX driver >> C:\PDrivers.txt

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Kyocera ECOSYS P2135dn KX" -i "\\PrintServer\pdrivers$\oemsetup.inf_amd64_540e610412cc6553\oemsetup.inf" >> C:\PDrivers.txt

IF %ERRORLEVEL% NEQ 0 (echo Error installing Kyocera ECOSYS P2135dn KX driver >> C:\PDrivers.txt)

[Jaan]

Sorry, I can't say whether this will work for you, but it may be worth a try, as this is how we add printer drivers to workstations. We then use a logon script to add printers..........)

 

Thanks for this. i've given this method a try using;

 

 

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Generic Universal V4 PCL" -i "\\nsnet.net\Deployed Resources$\Print Drivers\2023\KOBxxKA_01.inf"

 

and it worked on the computers that worked with what i used before pnputil /add-driver "\\nsnet.net\Deployed Resources$\Print Drivers\2023\*.inf"

 

 

However, on the computers that gave the "unable to find the file specified" before..... i get an "error2" message with the script i posted above.......

 

 

These must be related, but i can't seem to find any references in the event viewer. Arrrrrrgh

 

 

EDIT: apparently error 2 is File Not Found.

Edited September 20, 2023 by Jaan

[altecsole]

Are you using the correct .inf file? I used Print Management to get the Inf Path of the driver on the server. It's worth using explorer to copy and paste the path.

[Jaan]

Are you using the correct .inf file? I used Print Management to get the Inf Path of the driver on the server. It's worth using explorer to copy and paste the path.

 

I've already copied the .inf file to a accessible network location. and used copy and paste for the path. As you see in the screenshots..... it works on some but not others. i'm really baffled as these computers are in the same ou setting the same gpos and using the same user account to do the testing.

[altecsole]

My script runs as a startup script, so worth trying that to eliminate permission errors.

[robintech]

Does copying the driver to the local disk give the same error

[Jaan]

Does copying the driver to the local disk give the same error

 

yes same error

[Jaan]

I've sorted it!!!

 

I knew i wasn't going mad! in a nutshell, the driver in the deploy location was incomplete so it would never have worked as the file was missing... hence the errors. I just re-extracted the driver again and the below script worked!

 

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Generic Universal V4 PCL" -i "\\nsnet.net\Deployed Resources$\Print Drivers\2023\kobxxka_01.inf_amd64_c189b9e35b8454d2\KOBxxKA_01.inf"

 

Big thanks to altecsole for pointing me in the right direction!

 

the reason i had a handful of computers that worked...... well we tend to use the same computers before we go all out when testing things, a soft launch if you will..... seems we used these same computers to "test" the print driver before we deployed site wide! These computers had the full complete extracted drivers in their driver store!

 

What are the chances of that lol. out 100s of PC the three i tested were the same that were used last time.

 

Thanks for everyone's input

[alanmorris]

Please check the setupapi.dev.log file. For most driver installs, Windows adds additional logging.

C:\windows\inf\setupapi.dev.log

 

Thanks

[altecsole]

Great. As I mentioned, we run this as a Startup script, so it's easy to add another driver if reqd. If the driver is already installed, it doesn't force a re-install, so it doesn't really affect startup times.

 

Glad you got it working.

[Jaan]

I've used PDQ Deploy to push this out site wide, it will only run if the driver doesn't exist.

 

Thanks again