It is necessary to prevent or allow mapping of specific USB devices to virtual desktops. Sometimes a particular USB device does not map to a virtual desktop session, or a USB device redirects which is must not. This article describes the required settings that state which devices redirect in an ICA session.
For example, an XPe thin client has a USB printer connected. The user connects to their XenDesktop session and USB redirection connects the USB printer to the Virtual desktop Agent (VDA). The user prints documents to the printer object that was created from client printer auto-creation, but the documents fail to print. Once the user disconnects from their session, all the submitted print jobs print.
The user is printing to a printer object created by client printer auto-creation. When print jobs transfer to the client, the client’s spooler cannot communicate to the USB printer because the USB device redirected to the VDA; essentially the same as unplugging the USB cable from the client device and plugging it into the virtual desktop. When the session ends, USB redirection releases the USB printer device back to the thin client. When the connection is re-established, the spooled jobs print.

Following are the two Solutions to resolve this issue:

Solution 1

Install the printer drivers for the USB printer on the VDA. If the USB printer has system tray services and other applications that install, if you are in a single image environment you have now installed them for all VDAs, and you must educate the user to print to the local printer object rather than the auto-created printer.

Solution 2

Prevent the USB printer from redirecting to the VDA.
Solution 2 is recommended in this scenario as the way the user works is not changed and/or configurations of the virtual desktops are not manipulated.
The following procedure implements Solution 2.

Configuring USB Support

Refer to the following Citrix documentation on this feature - Configure USB support.

Following are few important points:

The ADM template for USB policy is found on the product installation ISO.

• XenDesktop 4: <operating system>\en\Support\Configuration\icaclient_usb.adm

• XenDesktop 5: \Support\Configuration\en\icaclient_usb.adm

USB device rules use one or more of six identifiers for USB devices. For specific rules, refer to www.usb.org. This website has the identifiers to use with XenDesktop.

This procedure builds upon the following Default rules which are evaluated prior to additional instructions. The default rules are held in a separate registry location than the policies created later in the procedure.

These are the default rules on the VDA:

# Syntax is an ordered list of case insensitive rules where # is line comment
# and each rule is (ALLOW | DENY) : ( match ( match )* )?
# and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
DENY: vid=17e9 # All DisplayLink USB displays
DENY: class=02 # Communications and CDC-Control
DENY: class=09 # Hub devices
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
ALLOW: # Otherwise allow everything else
These are the default rules on the endpoint (note they are more restrictive):
# Syntax is an ordered list of case insensitive rules where # is line comment
# and each rule is (ALLOW | DENY) : ( match )*
# and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
DENY: vid=17e9 # All DisplayLink USB displays
DENY: class=02 # Communications and CDC-Control
DENY: class=09 # Hub devices
DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
DENY: class=03 subclass=01 prot=02 # HID Boot mice
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
ALLOW: # Otherwise allow everything else

These rules are found in the following locations:

VDA: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\GenericUSB
Endpoint: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\GenericUSB

*location is under WOW6432node in 64-bit operating systems.

The endpoint has mor​e restrictive default rules to prevent devices such as USB mice (HID device) from redirecting which redirects the mouse to the virtual desktop, causing the user to lose control of the endpoint. Now that the default expected behavior is known, gather information on the device. A great tool to do this is USBDeview from Nirsoft.
Following is an example screen shot:

This tool shows any device that was ever connected to USB on the computer. Devices that are shaded and have a green light on the left side are currently active.
This example prevents the USB Audio device from redirecting to the VDA. An audio device must stay local to the endpoint rather than connect to the VDA unless audio is required in the VDA session. There are several ways to prevent this device from redirecting. A specific VID (VendorID) and PID (ProductID) is noticed. A simple VID rule would prevent the device from redirection.
Create the following rule:
DENY: vid=0763 pid=2015
Decide to create the rule - on the endpoint or on the VDA. If all VDA computer accounts are in the same OU or use the same base image (Provisioning Services), applying a GPO at an Organizational Unit (OU) level or a local policy setting to the base image affects all VDAs. Endpoints can reside in separate OUs and usually do not have a common base image, so logically rule can be separated using endpoints. In this case, to prevent USB Audio devices from connecting to any of the VDAs with no exception, so we will apply the rule to the VDAs.

Now, the USB Audio device no longer maps to the VDA. It is important to understand that while the endpoint is not configured to DENY the redirection, after it attempts to redirect the device, the VDA will DENY the redirection based upon the rule applied to the VDA. Configure both the VDA and the endpoint if we are required to allow a device that is denied by default. It is also important to be as specific as possible when configuring a device that is denied by default. We do not want to allow any other devices by accident and yield unwanted results.
What if we want to be more general on this deny rule and prevent ANY USB Audio device from connecting to our VDAs? Look at the Class of our audio device (01). What does “01” include? Refer to http://www.usb.org/developers/defined_class and note that Class 01 is an Audio interface. If we want to prevent all USB Audio interfaces from redirecting to the VDA, we could include the entire class.
This rule will encompass all USB Audio devices:
DENY: Class=01
If we apply this rule to the VDA, we never have to worry about USB Audio devices redirecting through USB. What if there is an exception? Device rules are processed sequentially so we can add an ALLOW rule after the DENY rule for an exception. Say we want only that particular USB Audio device in our previous example to redirect:
This rule will DENY all USB Audio devices, but allow one model in particular:
DENY: Class=01
ALLOW: vid=0763 pid=2015
Note: When entering multiple rules in Group Policy Editor, separate rules with a semicolon. Refer to the Help section of the GPO setting.
The last rule to process takes precedence over the previous rules. In reality, the complete processing of rules includes the default rules and our rules. This is what the entire chain looks like:

# Syntax is an ordered list of case insensitive rules where # is line comment
#  and each rule is (ALLOW | DENY) : ( match ( match )* )?
#  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
DENY: vid=17e9 # All DisplayLink USB displays
DENY: class=02 # Communications and CDC-Control
DENY: class=09 # Hub devices
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
ALLOW: # Otherwise allow everything else
DENY: Class=01
ALLOW: vid=0763 pid=2015

In conclusion, remember that ALLOW rules must exist on the endpoint AND the VDA, otherwise a single DENY wins. A DENY rule on either side prevents redirection; placement is dependent of your scenario.