To all,
I have an Horizon 6.2 deployment on one of our environments, and lately have seen issues due to change in ThinPrint redirection behavior. Prior to 6.2, printers that were redirected from the local client via ThinPrint were appended with :1, :2, and so forth to prevent conflicts with the printers that are installed on the virtual desktop. However, starting from version 6.2, ThinPrint will redirect the local client's printers to the virtual desktop with the exact name specified in the printer object. This has caused numerous issues on our end, mainly related to PDF printer driver (Bullzip PDF, ABS PDF printer from QuickBooks, XPS Document Writer):
1. For QuickBooks print to pdf function to work, both ABS PDF printer object and XPS Document Writer object must be installed for it to work. However, when a user connects to the virtual desktop with a client that has QuickBooks installed locally on their client desktop, ThinPrint will overwrite those printer objects with the redirected one, which will cause those printers to cease to function correctly since ThinPrint redirection does not support file-based printers. When user logs off, ThinPrint will delete those printer objects permanently, which will require a reinstall of those printer objects on the virtual desktop, even for non-persistent desktops if user data is persisted (e.g. Writable Volumes UIA+Profile from App Volumes).
2. Similarly, if the user has PDF printer (e.g. Bullzip) installed, or XPS Document Writer installed (which is installed by default on every Windows 7/8/8.1/10 desktop), on their client machine, and attempts to connect to the virtual desktop that has the same Bullzip/XPS Document Writer installed, ThinPrint redirection component will delete the Bullzip/XPS object, requiring a re-install of those printer objects. Since QuickBooks PDF printer requires XPS Document Writer to function, this also breaks the QuickBooks PDF printing functionality.
This has caused a fair amount of headache from us, and I would like to know if we can revert the ThinPrint redirection behavior back to the prior release. I really don't want to disable ThinPrint altogether as certain users want the ability to print from their home printer. Plus, the KB article on disabling ThinPrint (https://kb.vmware.com/kb/1031688, https://kb.vmware.com/kb/2012770, https://kb.vmware.com/kb/2003626) from the client side does not work at all.
Hi SolgaeDK,
To revert back to old printer name solution, please follow the steps below,
1. In agent desktop, change the value of registry key TPACScheme in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\ThinPrint Print Port Monitor For VMware\Ports\TPVM: from %N to %N#:%I (lager i).
2. Restarting TP AutoConnect Service and Print Spooler.
Then printers will be re-generated with name like "#:1" appended as before.
-Victoria
Anyone? There ought to be someone else who's experiencing this...
Have you removed virtual printing from VMware tools and then reinstalled the view agent with thinprint installed? I know there were some changes that deprecated thinprint at the VMware tools level.
VMware tools doesn't have the option to install ThinPrint components anymore - Only the View agent. And that component is precisely what's causing the problem stated in the thread due to the change in behavior on View 6.2. But I can't just remove the virtual printing component since some users require it for printing to home printer, and is also a required component for location-based printing to work.
I made a single comment about this awhile back I believe: Delayed Refresh on Logoff in 6.2
"Have you heard about the printer bug in 6.2 that VMware calls a feature?
Physical computer with View Client that has Adobe Acrobat installed will have an Adobe PDF printer, and if your VM has the Adobe PDF printer installed as well then upon log off or disconnect that Adobe PDF printer is now deleted from the VM!"
I apologize, I was not insisting that you remove thin print. I was suggesting that perhaps the vmware tools thin print was still installed and causing issues with thin print in your view agent.
We are experiencing the same issue. We have an Adobe PDF Printer installed onto the Virtual Desktops as a local printer. Whenever a user that has the Adobe PDF Printer installed onto their client machine, connects to the virtual desktop, whenever they disconnect or logoff, the Adobe PDF Printer object on the Virtual Desktop disappears. We have noticed that this only happens when a client has the same printer name as the virtual machine.
As stated in the original posting, It seems that the implementation of the ThinPrint has changed the way it redirects the printer mappings and instead of naming them using the convention of "PrinterName #:1" like it used to, it is using the convention of just "PrinterName". This causes the issue when ThinPrint goes to create the Adobe PDF thinprint printer object that is being passed through from the Local Machine to the Virtual Machine. It is unable to create the printer object because it already exists, however, when it goes to tear down the ThinPrint printer objects, it thinks that the Adobe PDF printer is one of it's own printers and removes it as well. This has caused quite an issue in our environment when someone who needs the Adobe PDF Printer in the Virtual Desktop logs into a Virtual Desktop and it is no longer there because ThinPrint decided to remove it.
We are currently looking into alternative solutions to this problem.
Precisely what's happening. The only alternative I've found is to change the name of the printer (you can change the name of the printer object without affecting the functionality) on the client side. However, VMware should have thought of this before they implemented this change (or ThinPrint since VMware is licensing this function thru ThinPrint).
Hi SolgaeDK,
To revert back to old printer name solution, please follow the steps below,
1. In agent desktop, change the value of registry key TPACScheme in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\ThinPrint Print Port Monitor For VMware\Ports\TPVM: from %N to %N#:%I (lager i).
2. Restarting TP AutoConnect Service and Print Spooler.
Then printers will be re-generated with name like "#:1" appended as before.
-Victoria
That has indeed done the trick - Thank you! VMware, PLEASE consider these implications before making such a change!!!
FYI - for linked clone desktops, just update the registry entry on the parent image and recompose with the new snapshot.
BUMP!!
VMware View Are you guys seeing this??
We are having the same issue with our accounting department not able to save to PDF or email PDF directly from Quickbooks since the update to 6.2.3 and then 6.2.4.
The workaround that I did after many hours of troubleshooting is by telling the user to use BLAST or any available Zero Client so there's no thin print involved and no printer being forwarded from local "physical" PC. And now they can save to PDF or email as PDF directly from Quickbooks.
Hopefully, that'll be helpful for someone here.
I'll try the registry that's being suggested here and will give you an update.
Cheers.
UPDATES:
This registry hack did the trick. Thank you guys.