Printing has always brought some challenges to a virtual environment. In my experience, printing issues have accounted for a substantial portion of the problems we have faced over the years with Citrix XenApp 5.0.
A stable printing environment in XenApp 5.0 was achieved by implementing a third party printing solution, Cortado’s ThinPrint .Print Engine 8.0. Prior to that, the print spooler on Windows Server 2008 would crash unexpectedly several times a day on several servers in the XenApp farm.
Cortado’s ThinPrint .Print Engine 8.0 VLayer allowed us to virtualize all printers on our Windows Server 2008 Print Server. Basically, .Print Engine 8.0 VLayer creates a (virtual) printer that carries over the settings from the original shared printer but utilizing the ThinPrint Output Gateway driver. Thus, you end up with two printers on the Print Server. One is the virtual ThinPrint printer with the TPOG driver and the other is the original printer that uses the native printer driver. The VLayer printer becomes the shared printer and sends print jobs over to the original printer which then sends them over to the physical networked printer. It solved many of our problems because, as many have noted, the majority of printer issues in Citrix XenApp are caused by printer drivers. Our XenApp 5.0 servers no longer used the native drivers; instead, the TPOG driver is installed once on each of the XenApp servers. Then, in XenApp Advanced Configuration Tool, you add the Print Server that hosts all VLayer shared printers. Lastly, you create a Citrix Policy that assigns shared printers to Active Directory users as session printers. The printers are created when a user logs in using the TPOG driver.
Upgrading to XenApp 7.6 from a XenApp 5.0 farm did not bring about as many headaches because of all the leg work done previously in planning and testing prior to deploying the product. Once the XenApp 7.6 site was operational we encountered our first obstacle and unsurprisingly, the problem involved printing.
On our newly created XenApp 7.6 site we assign session printers to users via a Citrix Policy. As done previously on the XenApp 5.0 farm, we installed the TPOG driver on the Virtual Delivery Agent servers. Initially, session printers were auto creating without issue and users were able to print. However, some of the printouts had partially garbled text. It was assumed that it might be a corrupt font as this had happened previously in XenApp 5.0. Replacing the suspected bad fonts ruled out that assumption. Oddly, the problem was affecting applications that used previously created forms; typing up something new in Word, for example, did not reproduce the problem.
Reasoning that we were now on Server 2012 R2 and XenApp 7.6 as opposed to Server 2008 and XenApp 5.0, we asserted that perhaps we needed to update the ThinPrint .Print Engine to a newer version. And we did. And it worked. The garbled text issue was gone and our users were able to print normally, at least for the remainder of the day. It so happened that after updating ThinPrint .Print Engine from 8.0 to 9.0 we had to also update the TPOG driver on each of the XenApp servers. Our XenApp 5.0 servers updated without problems but session printers on the XenApp 7.6 VDA servers stopped working the next day. And despair set in.
The issue was possibly due to attempting to install the updated TPOG driver on the VDA servers. We did so by connecting to the shared printer on the print server. When that failed we tried installing it from the ThinPrint installation media. We stopped and restarted the print spooler a gazillion time over.
As I recall, the error in Server 2012 R2 running Citrix XenApp 7.6 was “Windows can not connect to the printer 0x00000057”.
Luckily, after some googleing around I found the following article that proved to be the right solution to the problem.
It’s actually the print driver failing to install, not the connection to the print server. An initial attempt to install the driver failed, so the driver directory is present on the workstation, but missing the files.
1) On a machine with the same driver installed (and working properly), open Regedit, and browse to:
HKLM\System\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\
2) Locate the subkey for the printer driver you are dealing with and click the key for the printer driver.
3) Look for the “InfPath” on the right. Note the path.
5) Now browse to C:\Windows\System32\DriverStore\FileRepository and locate the folder indicated in the InfPath reg value.
6) Go to the users computer exhibiting this behavior, and browse to C:\Windows\System32\DriverStore\FileRepository and see if the folder is present. In my case, the folder was present, but empty. If it is here and it is empty, you will have to modify security on the folder, first taking over ownership, then granting yourself full control.
7) Once security is granted, copy the contents of this folder from a good machine to the machine presenting the 0x00000057.
Now try connecting to the print queue on the print server. The driver should now download and install properly.
Good luck. This isn’t the first time I’ve seen this happen, but this is the first time I decided a reimage was more than I wanted to take on, and I wanted to solve this so that I can correct it the next time it happens. And I have yet to find a real solution to the 0x00000057 error code.
If memory serves me correctly, we were missing a file in that one folder, I think….perhaps the whole folder was missing…Okay! To be honest, I just don’t remember as it happened a couple of months ago. But I do know were were missing something from that folder as I wrote myself a note and it specifically reads “TPOG driver folder files missing” “ThinPrint Engine upgrade to 9.0”. Give me a break, it was a very busy week and I keep getting old. 🙂
Computer sysadmin unexpected error icon sweatshirts by systemadmin
Make unique customizable tee shirts online at Zazzle.