Since the issue doesn't happen to the server itself, I would assume that the clients won't have the issue either with any driver that is locally installed. Because it very much appears so far that the issue only occurs when printing through the server (This is pretty common actually)
The issue has always been, in my experience, something in the Bi-Directional setup. So in MS Word for instance. You click File > Print and Word consults the driver locally, which reaches out to the server, which then reaches out to the printer, to get the tray settings, supplies and finishing options. The time to do this takes too long (45 seconds is the norm) and the application tries to resolve the communication issue and crashes. This does not occur if the driver is local because the communication is just app>driver>printer, instead of App>driver>Server>printer.
So we simply remove the enable advanced printing features and usually the SNMP on the port itself (because SNMP is being used by the Bi-Di on the port as well as the Configuration tab and causes conflicts).
My suggestion at this point, is a complete removal of all the drivers and ports from the clients (if possible) as well as the server for the 78XX devices.
Then install with either the Native PS driver (preferred) or latest PS GPD (If you must) using an LPR port, and disable the Advanced Printing features before deploying to a client.
Apologies for taking so long to get back to you about this. Unfortunately disabling Bi-Directional communication does not seem to have made any difference with this issue.
Just so I can clarify before trying your other few suggestions (LPR Port, GPD Driver), are you saying that I should try them on the server or on the client?
You've given me quite a bit of testing to do! I'll try your suggestions and get back to you, but I can answer one of your questions now - yes, the slowdowns only happen on the clients, not the server.
My recommendations I listed have in every case that I have seen this issue resolved them, so I am not sure why your location is different. (Thanks a lot, now I have to think ;-) )
The only thing left is to kill the Bi-Di (just to see if that is the issue and tell us where to go next)
And for clarity's sake.
Does the issue happen only on the client and not the server? (This is nearly always the case with all the options I have listed)
Does a true LPR port make any difference?
How about installing a new instance of the printer, but choosing the GPD with version number as the driver, any change?
And last I can think of, what happens with Native drivers?
Thanks for the suggestions. Unfortunately, all of these options were already correct on our server and have been set that way since the devices were deployed. If it helps, in addition to those options, the other change that got made to settings while deploying these devices was to set the Print Processor to WinPrint instead of the default XeroxV5Print. This change was made per the recommendation of our printer service company (ComDoc).
Any other suggestions?
Uncheck the highlighted boxes
And while I am certain the font thing is unrelated to a Xerox print driver being installed, most other font issues are resolved in the driver by setting it to Download as Softfont in Printing Preferences.
I've been encountering an issue with several users who have recently been upgraded to Windows 10 where they are unable to print to our Xerox printers.
We have a mix of WorkCentre 5335, WorkCentre 7845, and WorkCentre 7855 machines, which are all installed and shared on a Windows Server 2008 R2 machine on our network. For all printers, I am using the Global Print Driver. I have the latest version available installed on the server for both x64 and x86.
The issue I'm running into is that whenever a user attempts to print a document, their computer hangs for several seconds while it connects to the printer. In Microsoft Word, we sometimes receive a warning message saying that there is insufficient memory to display a font.
After doing some testing, it seems that this problem is limited to the Xerox printers that are installed through network shares. If I remove all of our Xerox devies, the remaining printers don't have this issue. If I install the Xerox devices locally, I don't have the issue. But if I install the printers from the server's through our group policy login script like I've been doing for all computers on the network, the problem comes back.
I would appreciate any assistance that you can provide in order to help me solve this issue. Thanks in advance!