Horizon View 5.2 - Serial Port In Use

[voelk01]

We are rolling out a new VDI environment using Horizon View 5.2.  All VDI OS's are Windows 7 Pro. We have a USB receipt printer that plugs into the thin client and redirects the USB port to use COM2 on the Windows OS.  Our software is telling us that COM1 and COM2 are already in use by the OS.  Any idea what could be using these ports, and if there is any way to free up COM2 so it is available?

Thanks!

[peterbrown05]

Hi

I don't fully understand your environment.

I'm presuming the USB printer is actually a Serial printer with a USB interface? and, the printer appears as if it is connected on COM2?

Can you use the printer locally on the thin client from "com2" ?

The software that is telling you com1 and com2 are already in use - where is this software installed (on the thin client?) - maybe the thin client hardware actually has 2 on board serial ports. If so, the USB device would need to instantiate at COM3 (or later). Are you able to change that manually?

What OS is the thin client running?

cheers

peterB

[voelk01]

Thanks peterB

Yes, you are correct

Our end users are using a physical zero client (Wyse P25) that has the View Client built in. The USB receipt printer is physically plugged into the zero client. The software for the printer configures it to use COM2.  We are using Windows 7 Pro and the software is install on the VDI client OS.

I have call into the printer support group to see if their configuration can use another COM port, but I am thinking the answer is no.

[peterbrown05]

hmmm- if it's a zero client though, you won't be installing any software on the local client device. Nor will the USB device be being "interpreted" locally. ie, the usb device should be forwarded as is to the guest VM.

on the guest VM, i presume you have;

  1. installed the device driver

  2. installed your printer software

when the device is redirected to the guest machine, is it at that point that the printer software reports the com port is in use?

does your guest vm have any "virtual" com ports created in its hw spec? (if so, can you remove them from the virtual machine spec).

It is probably worth noting at this time though, that Serial Ports do not remote particularly well via USB. Their performance is dependent on the network quality between your client and agent. If you are running on a reliable LAN network, then it should be OK. But, if the clients are remote connected via an unreliable network (eg wifi across a WAN) then you may find the printer has communication issues.

Are we sure that it's not communication issues that are being reported (incorrectly) as "com2 in use" ?  If possible, please test initially on a fast, low latency reliable network.

cheers

peterB

[voelk01]

Thanks again peterB

Yes, the printer device driver and software is installed.

Once plugged in, using the printer software on the guest, we manually assign the port to use, in our case I did verify it has to be COM1 or COM2.  The printer software comes back and tells us, that COM1 and COM2 are already in use and to select another port.  We can successfully select COM3, 4, 5, etc and the printer software accepts it.  The problem is, the application that works with the printer will only use COM1 or COM2.

For our testing the servers and clients are all on the same LAN, 1000 MB,

[peterbrown05]

can you look in device manager on your agent vm, and check if any serial ports are listed? ie do you see COM1 and COM2?

if they are, then can you go to the vm config and remove the serial ports from the vm settings?

[voelk01]

Yes, COM1 and COM2 are listed in the guest OS Device Manager. How can access the VM config and remove the serial ports.  I Went to Edit Settings for the VM under VMware Client and do not see any options?

[peterbrown05]

so its not a client side configuration...

you need to open up the virtual machine configuration from vCenter.

What you will actually need to do will vary based on the type of vm you have and how it has been provisioned to you by View... but assuming its a statically assigned vm, then you can go to vCenter - shut down the vm (ie power it off), then right click on it and Edit Settings. On the Hardware Configuration tab, I presume you will see 2x serial ports listed there. You need to delete them.

then power the vm back on, and log back in via the zero client.

if its a pool that is provisioned then you need to edit the vm template, and reprovision from there.

make sense?

cheers

peterB

[peterbrown05]

actually - my apologies. I just dug around my test system here, and found that i too have 2x com ports  and a parallel port in my windows vm. so even if you don't add any, then i think they are created by default for legacy reasons.

this is likely to be the cause of why you cant connect to it though.

let me see if i can turn it off in the bios.... give me a minute.

[voelk01]

Thanks again peterB.  I had the same thoughts to Disable the Serial Ports in the guest OS BIOS.  That does remove the ports in the guest OS Device Manager, however the printer software still has COM1 and COM2 as in use. Even though disabled in the BIOS, there still must be some VM setting/config in the background that has it in use.

[peterbrown05]

ok - so scratch my previous comments. maybe you can try one of these options;

1. in windows, you can change a com port number. so maybe you can make com2 com45 .

or

2. you could boot to the vm bios screen (do this from the vm boot options), and then disable the 2nd com port in the IO bios options.

cheers

peterB

[voelk01]

1) I was able to successfully change the COM2 settings in Device Manager to be listed as COM64 and not COM2.  This allowed my printer software use the "available" COM2.  However, when I try to print I receive a generic error message "Device is not connected". So I am not sure if this is a COM port related issue or an issue with the physical printer plugged into the zero client and not playing nice with View

2) If I disable the serial ports in the guest BIOS, it does not list them in the guest OS Windows Device Manager but the printer software still has COM1 and COM2 in use.

[peterbrown05]

ok... some progress maybe then.

right, so once the usb device redirects to the guest - do you see windows installing the usb driver? once it installs, then does it register itself as a COM2 device?

this might be the point in time when I need to start seeing the debug logs from the agent so I can see what's going on with usb...

(btw; lets stick with approach (1) for now  - ie change com2 to com6. rather than the bios changes)

[voelk01]

Thanks again for your help peter. Just a little background info that I found out yesterday from the vendor.  This is a known issue that they have with the VMware View Agent above v. 5.0. The vendor told me they have been working with VMware to resolve the issue since VMware View v. 5.1, but they were not aware of any fix.  Their recommendation as a workaround was to create a VMware View environment with the Connection/Compose server running v. 5.1 and have all the agents running v. 5.0. After reading the documentation from VMware, I don't believe that compatibility will work.

While still working with the vendor for some clarification, I came across another thread that you were helping with:  https://communities.vmware.com/thread/417217?start=15&tstart=0

After reading this thread, this sounds very much like what we are running into.  The printer that we are working with is a Epson TM-U3250. Do you think an upgrade to v. 5.3 and the registry modification would resolve this issue as well?  We are a brand new View environment with 5.2, and I would rather go forward than have to go backward and piece things together.

[peterbrown05]

wow ok - sorry - i hadn't realized this was an Epson printer. Yeah; 5.3 with that registry fix (as documented in KB VMware KB: Epson printers become unresponsive in VMware Horizon View ) is definately your next step! We need to interact with the Epson device driver in a different way to other devices, because the Epson drivers seem to work in a non standard way.

We did some major changes to the way USB works in View 5.1, and as such really going back to 5.0 isn't the right solution here.

Lets try the 5.3 agent, with that registry fix - and then move forward from there. Im sure we will get there in the end!

cheers

peterB

[voelk01]

Thanks peter, that is my fault. I did not mention that it was an Epson printer.  I am very glad I came across the other community thread you were working on.

I am assuming, when you say upgrade the 5.3 agent you mean upgrade the Connection/Composer server to 5.3 along with the agents on the desktop.  I just want to make sure before going forward.  I am going to go through all the release note information but will update asap and reply back.

Thank again peter, we have been working with VMware for little over a year and I am always impressed with the level of support reliability we receive by opening up cases and the community threads.

[peterbrown05]

for a quick test, i think you could install the 5.3 agent and leave your connection sever as it is. but, certainly not for long term production use -

I'm not a qualified expert on what can be used with what, but I'm pretty sure for what we are trying here you could just try upgrading the agent for now. lets solve that, and then loop back around to solve the rest of the infrastructure.

if of course once you do that then you can no longer connect to the desktop, then maybe Im wrong and it all does need upgrading.

[voelk01]

I installed the 5.3 agent on the guest machine and made the registry change but I am not able to login to the guest machine from a thin client.  Logging into the Connection server for the guest desktop an agent status of "Unknown and agent is unreachable".

I am going to guess that the Connection Server and Compose server must also be upgraded to version 5.3

[voelk01 · Accepted solution]

peter, this issue has been resolved.  I will post the exact steps I used in the thread: https://communities.vmware.com/message/2322994#2322994

Thank you for all your help to resolve this issue.

[peterbrown05]

yay! most excellent news. glad we got there in the end. apologies it took a whilst to get there.

cheers

peterB