Why aren't my RDP mode USB redirections working?

RDP USB redirection is hard because Microsoft really, really don't want you to use this, and try to hide this capability from you and/or artificially limit it so that you can't use it; they want you to use high-level redirection strategies instead.  But not all of those high-level redirection strategies are usable, in practical terms, in a Linux context.

In ThinLinX's experience to date, non-Linux-expert customers don't like either client drive redirection or CUPS printer redirection, the former because the way that ThinLinX has implemented it is "weird" and doesn't behave in a Windows-like fashion (e.g. drive letters, safe removal), the latter because it is too difficult to set up.  The TWAIN (scanner) protocol just isn't a thing in Linux, and USB vidcam redirection with H.264 acceleration is grossly impractical due to extremely difficult GStreamer setup.  If at all possible, you should really use USB redirection instead - this will be a lot simpler for you.

However, RDP (really RemoteFX, i.e. Vista or later required) USB redirection will work under the following conditions:

• If not grayed out, the RDP Submode option must be set to RemoteFX or "RemoteFX (software only)", because the RDP option downgrades the RDP protocol to v7, which lacks support for USB redirection.  We removed the "RDP" Submode option in TMS 8.2.0 and later / TLXOS 4.8.0 and later, because there is in practice never a good reason to force Submode = RDP (you'd only ever need that for Windows Server 2003 or earlier, and FreeRDP will fall back to that as needed anyway).
• If the RDP server is a desktop edition of Windows, you must be running at least Windows 7/8/8.1 Enterprise, or Windows 10/11 Professional (strictly speaking also Vista Ultimate).  Lesser editions lack the necessary RemoteFX features.
• If the RDP server is a server edition of Windows, it must be Windows 2008 R2 or later, and must have the Remote Desktop Session Host (RDSH) role installed.
• If the RDP server is Windows 10/11 or Windows Server 2016 or later, you will need to edit group/local policy to enable redirection of certain types of USB devices (e.g. printers/scanners) because this is disabled by default for recent Windows O/S releases.  In the Group Policy Editor, you must set "Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection\Do not allow supported Plug and Play device redirection" to Disabled, and then run "gpupdate /force" on your RDP server (or wait a few minutes).

Please note also that you may have issues if your USB device is integrated into a monitor that you are directly connecting to a Raspberry Pi, because monitor manufacturers like to save a few dollars by not powering their built-in USB hubs, and the Raspberry Pi - being a very low-power device - often cannot provide sufficient power to operate an unpowered hub.  For best results, connect your monitor's unpowered USB hub to an external powered USB hub, and then connect the powered hub to your Pi.  Or just avoid using the monitor's USB hub and plug devices directly into the Pi instead.

Up until TLXOS 5.0.2/5.2.2 it was not necessary to redirect USB storage devices, because access to these was automatically provided via client drive redirection.  Storage devices would appear as subfolders under the share named "Storage on <client-hostname>" (or \\tsclient\storage on really old Windows systems), whose names correspond to the volume name (if any) or a Linux device pathname (e.g. sda1) otherwise. This share corresponded to the /media area on your client.  Because the API lacks any kind of "safe removal" callback, we had to automount filesytems using a one-second idle timeout and the "sync" option (because we have no idea when they might be physically unplugged), which made writes to redirected drives very slow.

However, this feature proved difficult for customers to understand, so in 5.0.2 LTS and 5.2.2, we implemented our own DIY version of default USB device redirection instead, and now support client drive redirection only when Redirect USB is set to Manual rather than Auto.  See Default USB redirection policies for more information on the new behavior.

When trying to determine why USB redirection isn't working in RDP mode, to save time you should first test that it works when using Windows' own RDP client, mstsc.exe, because there are several reasons why it might not (see above condition list).  For this to work, your account on the client PC must have Administrator rights, i.e. be a member of the Administrators (or Domain Admins) group, otherwise you will need to make another group/local policy change (see above).

If you intend to redirect a USB webcam or printer, please note that mstsc.exe will not let you do that using RemoteFX USB redirection.  The is purely a Windows client limitation, and the Linux RDP client is not limited in this way.  However, it means that when testing whether USB redirection works using the Windows RDP client, you should attempt to redirect some other type of USB peripheral instead (not a storage device, the Windows client won't allow USB redirection of that either), e.g. a USB audio device.

The USB redirection option in mstsc.exe is somewhat hidden, and has nothing to do with more visible high-level audio/printer/port/drive redirection options:

Once you connect, you will see a new icon on the drop-down toolbar, which you can click on to see details of the redirections:

You can then check Device Manager to see whether the USB device has been detected by the server.

If all that seems to work, you can move on to testing USB redirection using TLXOS.  Please note that the FreeRDP client cannot (reliably) handle USB hotplug events, so the USB device must be plugged in before the session begins and remain plugged in until you have finished using it.