Most new PCs don’t have built-in serial (COM) ports. The ports are easy to add by using USB converters. Applications suited for serial ports often involve sensors, controllers, old check readers, pads, and so forth. Some USB virtual COM-port devices use vendor-specific drivers in place of the Windows-provided drivers (usbser.sys). These drivers allow you to force the virtual COM port of the USB device so that it doesn’t change even if connected to different USB sockets. This might be done from the Device Manager > Ports (COM & LPT) > Properties or from the application that controls the device.
Client COM port mapping allows devices attached to the COM ports on the user’s endpoint to be used during virtual sessions. You can use these mappings like any other network mappings.
For each COM port, a driver in the operating system assigns a symbolic link name such as COM1 and COM2. The applications then use the link to access the port.
Because a device can attach to the endpoint by using USB directly, doesn’t mean it can be redirected using generic USB redirection. Some USB devices function as virtual COM ports, which applications can access in the same way as physical serial port. The operating system can abstract COM ports and treat them like fileshares. Two common protocols for virtual COM are CDC ACM or MCT. When connected through an RS-485 port, applications might not work at all. Get an RS-485-to-RS232 converter to use RS-485 as a COM port. Important:
Some applications recognize the device (for example, a signature pad) consistently only if it is connected to COM1 or COM2 on the client workstation.
Map a client COM port to a server COM port
You can map client COM ports to a Citrix session in three ways:
- Studio policies. For more information about policies, see Port redirection policy settings.
- VDA command prompt.
- Remote Desktop (Terminal Services) configuration tool.
Enable the Client COM port redirection and the Auto connect client COM ports Studio policies. After applied, some information is available in HDX Monitor.
If Auto connect client COM ports failed to map the port, you can map the port manually or use logon scripts. Log on to the VDA, and at a command prompt window, type:
NET USE COMX: \\CLIENT\COMZ:
NET USE COMX: \\CLIENT\CLIENTPORT:COMZ:
X is the number of the COM port on the VDA (ports 1 through 9 are available for mapping). Z is the number of the client COM port you want to map.
To confirm that the operation was successful, type NET USE at a VDA command prompt. The list that appears contains mapped drives, LPT ports, and mapped COM ports.
To use this COM port in a virtual desktop or application, install your user device application and point it to the mapped COM port name. For example, if you map COM1 on the client to COM3 on the server, install your COM port device application in the VDA and point it to COM3 during the session. Use this mapped COM port as you would a COM port on the user device.
COM port mapping is not TAPI-compatible. You can’t map Windows Telephony Application Programming Interface (TAPI) devices to client COM ports. TAPI defines a standard way for applications to control telephone functions for data, fax, and voice calls. TAPI manages signaling, including dialing, answering, and ending calls. Also, supplemental services such as holding, transferring, and conference calls.
Ensure you can access the device directly from the endpoint, bypassing Citrix. While the port is not mapped to the VDA, you are not connected to a Citrix session. Follow any troubleshooting instructions that came with the device and verify that it works locally first. When a device is connected to a serial COM port, a registry key is created on the hive shown here:
You can also find this information from the command prompt by running chgport /query.
If troubleshooting instructions for the device aren’t available, try opening a PuTTY session. Choose Session and in Serial line specify your COM Port.
You can run MODE in a local command window. The output might display the COM port in use and the Baud/Parity/Data Bits/Stop Bits, which you need in your PuTTY session. If the PuTTY connection is successful, press Enter to see feedback from the device. Whatever characters you type might be repeated on the screen, or responded to. If this step is unsuccessful, you can’t access the device from a virtual session.
Map the local COM port to the VDA (using policies or NET USE COMX: \\CLIENT\COMZ:) and repeat the same PuTTY procedures in the previous step, but this time from the VDA PuTTY. If PuTTY fails to show the error Unable to open connection to COM1. Unable to open serial port, another device might be using COM1.
Run chgport /query. If the built-in Windows serial driver on the VDA is auto-assigning \Device\Serial0 to a COM1 port of your VDA, do the following: A. Open CMD on the VDA and type NET USE.
B. Delete any existing mapping (for example, COM1) on the VDA.
NET USE COM1 /DELETE
C. Map the device to the VDA.
NET USE COM1: \\CLIENT\COM3:
D. Point your application on the VDA to COM3.
Lastly, try to map your local COM port (for example, COM3) to a different COM port on the VDA (other than COM1, for example COM3). Ensure that your application is pointing to it: NET USE COM3: \\CLIENT\COM3
If now you do see the port mapped, PuTTY is working but no data passing, it might be a race condition. The application might connect and open the port before it is mapped, locking it from being mapped. Try one of the following:
- Open a second application published on the same server. Wait a few seconds for the port to be mapped, and then open the real application that tries to use the port.
Enable the COM port redirection policies from the Group Policy Editor in Active Directory instead of Studio. Those policies are Client COM port redirection and Auto connect client COM ports. Policies applied this way might be processed before the Studio policies, guaranteeing that the COM port is mapped. Citrix policies are pushed to the VDA and stored in:
HKLN\SOFTWARE\Policies\Citrix \<user session ID\>
- Use this logon script for the user or instead of publishing the application, publish a .bat script that first deletes any mapping on the VDA, remaps the virtual COM port, and then starts the application:
@echo off NET USE COM1 /delete NET USE COM2 /delete NET USE COM1: \\CLIENT\COM1: NET USE COM2: \\CLIENT\COM2: MODE COM1: BAUD=1200 (or whatever value needed) MODE COM2: BAUD=9600 PARITY=N Data=8 Stop=1 (or whatever value needed) START C:\Program Files\<Your Software Path>\<your_software.exe>
Process Monitor from Sysinternals is the tool of last resort. When running the tool on the VDA, find and filter objects like COM3, picaser.sys, CdmRedirector, but especially <your_app>.exe. Any errors might appear as Access Denied or similar.