ThinPrint disabled by following vSphere best practices

The simple things often take the most time to resolve

I was recently working with a customer on Horizon RDSH published desktops using Instant Clones where, for some reason, we could not get the local endpoint default printer to pass through to the Horizon session. I downloaded the latest ThinPrint diagnostic tool which gave some good advice on any patches that I may have missed that were required for ThinPrint functionality. After applying the patches, I was still no further forward. It then occurred to me that ThinPrint functionality was dependent on the use of a serial port (COM1).

As a VMware security best practice, we advise the removal of unused or unneeded hardware devices as stated below:

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-600D24C8-0F77-4D96-B273-A30F256B29D4.html

Whilst this holds true in a pure vSphere environment, it unfortunately does not take virtual printing into account in a Horizon environment.

When I checked the customer’s RDSH gold image, I did indeed find that the serial, parallel and floppy devices were disabled in the virtual BIOS. By enabling the serial port and reinstalling the Horizon agent with virtual printing enabled, our elusive default printer appeared as expected. I don’t do much administration these days but it is the little things like this that tend to eat up a lot of time. I hope this post helps you.

Author: John Wilkinson

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *