I was never able to get the V4 drivers to function as I'd hoped and abandonded pursuing them further when we began to hit other snags, so I went back to using V3 drivers. Not sure if the V4 drivers had been successful if they would have helped prevent the headaches with PrintNightmare or not, but that's been no fun, takes all the automation out of deploying printers via GPO.
Sorry you're having the same V4 issues.
We have the same problem. Did you find a solution other than roll back to v3 Drivers?
The settings on the device would not have an impact on the inability for the computers to do a secure print.
My feeling is in the compatibility between the OS and the type 4 driver, and how the command gets interpreted by the spooler. ( Not proven!)
Type 3 is old school, but very reliable.
I happy to hear it was a good workaround.
Have a great day!!
EKC - Coach,
I used the Xerox SmartStart driver like you said and setup a couple new V3 driver based print queues for an AltaLink B8155 and C8145. I was able to send both print qeueus a test text page via Secure Print and release the job from the device Jobs queue without issue. Seems this is definitely something up with the V4 drivers or some feature at the devices that is not allowing the Job to process correctly when using that driver type.
Are you familiar with any required services or features that would be needed for V4 to work properly?
Thanks for your help!
Oh OK great, I will give that a try today and see if it will make any difference. Thanks so much for your reply @EKC-Coach.
Run the Xerox Smart Start – Driver Installer from the driver downloads section, and when it finds you printer, select more options and you will have a selection to install new drivers.
Type 3 is listed there. It has the true and tested GUI we all are used to.
Type 4 needs the Print Experience app to give the GUI and print control. It is very pretty.
That would at least eliminate or confirm an issue with the Type 4 driver on your system if the issue disappears.
If you run LPR Protocol on your port, call the Queue Name lp
LPR Byte Counting should be unchecked.
I have a problem that is driving me mad. I used to support Xerox printers a couple years ago but mainly used V3 drivers. Well I recently took delivery of some new AltaLink B8155's and learned that only V4 or Global drivers were available for them, so this is my first real experience utilizing V4 drivers and the Xerox Desktop Print Experience app on clients.
Print Server: Server 2019 x64
Client PC: Windows 10 x64 - 1909 (Build 18363.1316)
Printer / Drivers / Port: AltaLink B8155 using V4 PCL driver on server & RAW 9100 port
Job Type: Secure Print with Passcode
All "Normal Print" jobs are succeeding, but any time I send a "Secure Print" job it fails to show up in the server or device job queue for release. When I check device status on the Xerox Desktop Print Experience app (XDE) it shows "Unknown Unknown Job Cancelled" everytime. I found an article that mentioned changing port types from RAW to LPR, but when I did that and gave it a queue name of "print" it hung up the XDE app altogether.
I exported a Device Audit Log and it shows this msg any time a Secure Print job was sent:
Print Job Unknown Unknown comp-terminated
I've reviewed the Admin guide doc and am not seeing anything related that I missed configuring that I can tell, but I was wondering since it states that it ties the Secure Print job to the username if that might be the source of this problem. One mention back to the port type change was a user saying that RAW hides the source and that LPR allowed source data to be displayed. I'm pretty sure when I used V3 drivers that I used RAW then as well and didn't have all these troubles, but things may have changed in how the jobs are processed.
I need to get these new devices deployed soon and really need the Secure Print feature to work. Any help or tips you can provide are very much appreciated.
Solved! Go to Solution.