MS fully supports V3 drivers in Windows 10 and always have, they just don't prefer them.
I run both drivers on multiple PC's with and without the App (Which is mandated by the V4 architecture, not Xerox or MS) without issue.
Joe,
Thanks for your feedback on the Win10 build vs the driver version.
I did more testing and found a solution that works: V4 PCL 6 driver + Xerox Desktop Print Experience Application 3.0.
Some pitfalls:
The version of the Xerox Print Experience in the Microsoft Store was old and didn't work.
V4 drivers by themselves do not have the accounting options. You must have the Xerox Print Experience to get those options.
Global drivers will not work since they are V3.
I have not tested this, but I suspect the V4 Postscript driver + Xerox Print Experience 3.0 will work.
I really think Xerox should put a warning on all the V3 drivers regarding domain users and accounting. Part of the blame probably belongs with Microsoft for changing low level interfaces in newer builds of Windows 10. The good news for me is that I have a working solution. The bad news is that I have to update a couple of hundred PCs with new drivers and install the Xerox Print Experience.
We are using the Windows 10 x64 PCL6 driver printing directly to the copier with LPR. Bi-directional communication on.
Version: 5.433.16.0N 2015.11.12
WorkCentre 7855i
LPR. Bi-directional communication on. = Disable both
Version: 5.433.16.0N 2015.11.12 = Not supported anymore, update to something at least semi current, that one is from 5 months after Windows 10 officially came out, so it certainly won't work properly for Windows 10 1607 or 1703
Once you have done those, if the issue still occurs, call Xerox, get to 2nd level and have them spar it, I tried to replicate it on the latest GPD (5.548.8.0) and latest PS (5.433.16.0) on Win10 build 1703 and failed, but that doesn't mean a whole lot since I can't exactly replicate your setup as I have no idea what it is. But Xerox 2nd level won't escalate an outdated setup, and if they did, Engineering would immediately reject it., they would also want the firmware on the printer updated.
The PCAP would be helpful at that point
Here is more specific info from pcap trace.
This is a snip from the decoded print test page job as local administrator:
@PJL XCPT <client-default-attributes-col syntax="collection">
@PJL XCPT <job-accounting-user-id syntax="name" xml:space="preserve">350999</job-accounting-user-id>
@PJL XCPT <media-col syntax="collection">
@PJL XCPT <input-tray syntax="keyword">automatic</input-tray>
This is a snip from the decoded print test page job as a domain user on the same computer:
@PJL XCPT <client-default-attributes-col syntax="collection">
@PJL XCPT <media-col syntax="collection">
@PJL XCPT <input-tray syntax="keyword">automatic</input-tray>
The difference is that the job-accounting-user-id field is missing completely from the domain user print job. It was entered into the dialog box prompt but it never makes it into the print job sent to the copier.
If it would be helpful, I can provide the pcap file.
We are medium sized municipal government organization and we are experiencing the EXACT same problem with Windows 10 roaming profiles.
We just switched from another copier vendor (about a 500k contract). The copiers all print, scan, fax great until Xerox Standard Accounting is turned on. With accounting on, our Windows 7 user (roaming profiles) can send the User ID and print color without problems. Windows 10 roaming profiles get prompted for the User ID, but get all color print jobs rejected. Local administrators on the same Windows 10 PCs can used the same User ID and print color fine. The issue is specific to domain users with roaming profiles trying to print color.
We are using the Windows 10 x64 PCL6 driver printing directly to the copier with LPR. Bi-directional communication on.
Version: 5.433.16.0N 2015.11.12
WorkCentre 7855i
My team and I have spent many hours troubleshooting this. Our vendor has not been able to find a solution so far.
I turned on network capture on the copier and ran test prints from Windows 10 as local admin and as a domain user. I then downloaded the pcap file and analyzed it using WireShark. Prints from the local admin sent the user ID in the XML print job header. Prints from the domain user DID NOT send the User ID despite the fact that the user was prompted.
This looks like a Xerox problem!!
I sent you a PM.
That should really be going through Xerox 2nd level. Have you called them? If so, please PM me your log number and or Serial number and a link to this post so I know what it references and I will see if they have looked into it yet.
I am writing for advice with a problem I am having with Windows 10 and Standard Accounting for Xerox copiers.
I have two Xerox printers, a Workcentre 7655 and a ColorCube 9302. We have Standard Accounting enabled on both, and have used them for years just fine with Windows 7. We print, we scan, we copy. Works great.
We have recently started working with Windows 10 and are experiencing very odd behavior when we try to print. All attempts at printing by a domain user, using a valid copier code, results in an Error Notice with the following text: “The print job was deleted because invalid accounting codes were entered or accounting codes were missing.” Printing by a local user on the PC works just fine.
We have tried v3 versions of the Global Print Driver, the PCL6 driver and the Postscript drivers; I have done the most work with UNIV_5.520.6.0_PS_x64.exe. I have tried using these drivers on fresh copies of Windows 10 Enterprise, both the LTSB and the CBB versions, on 1511, 1607 and 1703. Windows was fully patched.
The machines are on a Windows domain, but we print direct to the printers via a TCP/IP address. When installing the driver, I specify the IP address, I ensure it is set for TCP/IP not WDS, I don’t allow the driver installer to query the printer (I select from a list). And I have tried many, many permutations of the above. Nothing works. It works fine on Windows 7, not Windows 10.
Further oddities:
The above issues sound like “permissions”, but I have tried forcing the permissions on the c:\programdata\xerox hierarchy to full access for Everyone, but it doesn’t help.
I had a Xerox tech physically onsite for 3 hours and he was baffled.
Any ideas? The obvious conclusion is that surely this works fine elsewhere, so it must be something peculiar to my environment.
Thanks,
…Bruce