Getting COM Ports in client list is inconsistent across machines

Love your software, but we are having an issue and really need some help. 

We are forwarding a device from one machine to another using your software.  

The device we are forwarding is a USB device but uses a USB to serial driver, so the device shows up in windows under LPT and Ports with a COM Port number. 

We have the device drivers installed on both the client and server side. 

When we “use” the device in VHUI64.exe, we see the COM port and the Server Machine name.  

Which IS what we need.  

Then, when we use the command prompt vhui64.exe -t list command on some of our machines we get the COM PORT in the list. Which is also what we need.  

 

But in other machines, we don’t get the COM port listed in the GUI or in the -t list.

 

We need to map the COM Port number to a Machine Name for each device that connects to our remote computer where we are running your client.   

Is this a setting issue? Or something else?  How can we reliably always get the COM Port and the forwarding Machine name? 

#2

You must use the latest virtualhere client on all machines and the latest virtualhere server. You probably have old versions of virtualhere client on some machines which dont support the COM details.

#3

I'm pretty sure we dowloaded new client and server packages to the machines that we tested on.   Any other thoughts? 
Eric G who is working with me will follow up as he is doing the dev work on this.  
We need to map and store the Com Port and clientname for the devices that get redirected to our server. 

#4

I think you should double check the versions you are running first. Remember you cant just copy over an exe if the client is running as a service because the exe will be in use. You need to uninstall the service first (Right click USB Servers->Uninstall service)

 

#5

Client was not installed to run as a service, BUT it may have been running on the machine! Will look into that. 

It was run from Powershell  .\vhui64.exe 

#6

To other readers: this was fully resolved by updating the VirtualHere client  for all machines

#7

Yes, fully resolved by updating the VirtualHere client for all machines!  Thank you!