LPT and COM port settings are configurable via Studio in XenApp / XenDesktop 7.9 or newer. In versions 7.0 through 7.8, these settings were only configurable using the registry. For more information, see Port redirection policies in Citrix Documentation.

Client COM port mapping allows devices attached to the COM ports on the user's endpoint to be used during virtual sessions. These mappings can be used like any other network mappings.
For each COM port, a driver in the OS assigns a symbolic link name such as COM1, COM2, etc, which is then utilized by the applications to access the port. 

While most PCs no longer have built-in serial (COM) ports, the ports are easy to add via USB converters. 
Beware that even if a device can attach to the endpoint via USB directly does not mean it can be redirected via Generic USB Redirection. Some USB devices function as virtual COM ports, which applications can access in the same way as physical serial port. The OS can abstract COM ports and treat them like fileshares. Two common protocols for virtual COM are CDC ACM or MCT.
(When connected through RS-485 port Applications might not work at all. Get a RS-485-to-RS232 converter to use it as a COM port)

Applications suited for serial ports often involve sensors, controllers, old check readers, pads, etc.

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 does not change even if connected to different USB sockets. This might be done from Device Manager / Ports (COM & LPT) / Properties, or from the Application itself, that controls the Device.

Warning: Some applications will only recognize the Device (e.g. signature pad) consistently if it is connected to COM1 or COM2 on the client workstation.

Instructions

You can map client COM ports to a Citrix session in three ways:

1. Using Studio policies. 
2. From the VDA's command prompt. 
3. Or from the Remote Desktop (Terminal Services) Configuration tool.

For information about policies, see the XenDesktop or XenApp documentation in edocs. 
Let us describe methods #1 and #2 from above:

1. For XenApp/XenDesktop 7.9 or higher, enable the "Client COM port redirection" and the "Auto connect client COM ports" Studio policies. Once applied, some info is available in HDX Monitor:
   

2. Or, If the "Auto connect client COM ports" is failing to map the port, you can do it manually or via logon scripts. Log on to VDA, and at a command prompt window, type:
   NET USE COMX: \\CLIENT\COMZ:  
   or
   NET USE COMX: \\CLIENT\CLIENTPORT:COMZ:  

Where 'X' is the number of the COM port on the VDA (ports 1 through 9 are available for mapping), and 'Z' is the number of the client COM port you want to map.

To confirm that the operation was successful, type in a VDA command prompt: NET USE
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.

Important: COM port mapping is not TAPI-compatible. TAPI devices cannot be mapped to client COM ports. The Windows Telephony Application Programming Interface (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 and supplemental services such as holding,  transferring and conference calls.

Troubleshooting

1. Make sure you can access the device from the endpoint directly, bypassing Citrix (while the port is NOT mapped to the VDA, id est, you are not connected to a Citrix session). Follow any troubleshooting instructions that came with the device and verify it works locally first.
   When a Device is connected to a Serial COM Port, a registry key is created on this hive. 
   This can also be queried from the command prompt by running 
   'chgport /query'.
   
   If troubleshooting instructions for the device are not available, you may try opening a PUTTY session and selecting Session and in Serial Line select your COM Port.
   
   Running "MODE" in a local command window might tell you the COM port in use, and the Baud/Parity/Data Bits/Stop Bits, which you will need to match in your Putty session.
   If the PUTTY connection is successful, you may be able to press 'Enter' and see some type of feedback from the Device. Whatever characters you type may be repeated on the screen, or responded to.
   If this step is not successful, you will not be able to access the device from a virtual session.
   

2. Now, map the local COM port to the VDA (either via Policies or via NET USE COMX: \\CLIENT\COMZ:) and repeat the same PUTTY procedures as above but this time from the VDA PUTTY.  
   If PUTTY fails with error "Unable to open connection to COM1. Unable to open serial port" then probably COM1 is in use by some other device.
   Run 'chgport /query'. Is the built-in Windows serial driver on the VDA auto-assigning \Device\Serial0 to a COM1 port of your VDA? If so, you can correct this:

   1. Open CMD on the VDA and type NET USE
   2. Delete any existing mapping (e.g. COM1) on the VDA: NET USE COM1 /DELETE
   3. Map the device to the VDA: NET USE COM1: \\CLIENT\COM3:  
   4. Point your Application on the VDA to COM3
      Lastly, you could try to map your local COM Port (e.g. COM3) to a different COM Port on the VDA (other than COM1, for example COM3), and make sure your application is pointing to it:
      NET USE COM3: \\CLIENT\COM3:

3. If now you do see it mapped, PUTTY is working but no data passing, it might be a race condition. Perhaps the application connects and opens the port before it is mapped, locking it from being mapped.  

   You could try one of the following:

   1. Opening a second application published on the same server first, wait a few seconds for the port to be mapped, and then open the real application that actually tries to use the port.
   2. Enabling the COM Port Redirection policies ("Client COM port redirection" and "Auto connect client COM ports") from the Group Policy Editor in AD instead of Studio.
      Policies applied that way might be processed earlier than 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>
   3. You can use a logon script (see script below) for the userOr, instead of publishing the application, publish a .bat script that first deletes any mapping on the VDA, remaps the Virtual COM Port and then launches the application:
      
      @echo off (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>
      NET USE COM1 /delete
      NET USE COM2 /delete
      NET USE COM1: \\CLIENT\COM1:
      NET USE COM2: \\CLIENT\COM2:MODE COM1: BAUD=1200

   4. Process Monitor from Sysinternals is the tool for last resort; when running it on the VDA you should Find and Filter objects like 'COM3', picaser.sys, CdmRedirector, but especially around <your_app>.exe. Any errors might pop-up there as 'Access Denied' or similar.

• CTX202448 - COM Port Communication Issues when 20 or More Users are Concurrently Using COM Ports in XenApp 6.5

• CTX214430 - Topaz Signature com port Redirection Works The First Time, Subsequent Logins Fail Requiring a Reboot