I’m limited to Remote Desktop for 7-hour shifts, so I cannot plug the 3Dconnexion Mouse directly into the workstation. I enabled all available local device redirection options and reconnected, but the remote session only sees standard pointer movement; the 3D controls do nothing. What setting or forwarding method should I try next?
Don’t keep toggling the ordinary mouse and local-resource boxes. Those redirect pointer input, not the SpaceMouse’s full USB interface, so the 3D axes never reach the workstation.
Try low-level USB redirection, sometimes still labeled RemoteFX USB redirection. On the client, enable “Allow RDP redirection of other supported RemoteFX USB devices from this computer.” On the workstation, disable “Do not allow supported Plug and Play device redirection.” Restart both sides, reopen the RDP client, then check Local Resources > More > Other supported USB devices and select the 3Dconnexion device. The 3DxWare driver should be installed on the remote workstation too. These policies may require your IT administrator.
If the device still does not appear there, native RDP redirection probably is not going to handle it reliably. FlexiHub is the next method I’d try because it presents the complete device to the remote machine as though it were locally attached, rather than translating it into ordinary pointer movement. Install it at both ends and use these steps to access 3Dconnexion. Check with IT first, since USB-over-network software may be blocked by company policy.
13 Likes
If the workstation is locked down by company policy, neither RDP settings nor USB software will get around that. With IT approval, install the flexihub app at both ends. FlexiHub is especially handy because you can reconnect the SpaceMouse from its device list after an RDP session drops, without redoing the Windows redirection setup.
Don’t treat “passthrough” and ordinary RDP device redirection as interchangeable. Keyboard and pointer redirection sends translated input events. A SpaceMouse needs its multi-axis HID reports exposed to the remote operating system, so checking every Local Resources box will not make it behave like a directly connected device.
The caveat with full USB forwarding is device ownership. Once the SpaceMouse is attached to the workstation through RemoteFX-style redirection or USB-over-network software, the local computer may no longer be able to use it. Session drops, sleep, VPN changes, and switching between remote machines can leave the device captured or disconnected until you release and reconnect it. That is especially annoying during a long shift, so test recovery from a deliberately disconnected RDP session before relying on the setup.
@matrixcache9848 is right that the remote side needs 3DxWare, but matching driver generations at both ends can matter too. Remove stale SpaceMouse entries from Device Manager if Windows keeps detecting a new or unusable copy after each connection. Then verify the device in the 3Dconnexion trainer or control panel on the remote workstation before troubleshooting the CAD application. If it fails there, application settings are not the problem.
I would use native USB forwarding if company policy allows it and the device actually appears in the selectable USB list. If it never appears, stop adjusting standard RDP options. At that point, a dedicated USB-over-IP tool such as FlexiHub is the practical route, but IT needs to approve the service, firewall traffic, and licensing. There is no software workaround for a workstation policy that blocks installation or forwarded USB devices.
Do not test it through a jump box and assume that because the CAD workstation sees the device the redirection has succeeded. Low level USB redirection typically breaks at the first remote windows session, it will not reliably persist through a second RDP session riding on the first.
Check Device Manager on the box that is actually running the CAD software. Finding the SpaceMouse on an intermediate desktop is a pretty weak indicator of success.
An RD Gateway is just a transport so that’s not the issue, a jump host is an additional session which changes the whole story.
For two hop connectivity, your IT department has two options. Either they allow direct connections to the final machine or they install whatever USB over network service you folks are using on the final machine. Checking boxes under local resources on a jump host is not going to change the architecture of the problem.
If your VPN has any real distance or jitter, the whole passthrough question changes before you even touch policy settings. A SpaceMouse isn’t sending the odd keypress, it’s streaming continuous axis reports the entire time your hand is on the puck. Run that through USB-over-IP on a laggy link and the model can drift, overshoot, or stutter when you feather a rotation. Native input redirection would actually hide that better because it only sends the resulting motion, but as everyone here already worked out, redirection throws away the axes you need. So you’re stuck with the method that’s also the most sensitive to a bad connection.
@quantumwizard3323zon nailed the part most people skip, which is that a jump host is a separate session and checking boxes there does nothing. That’s the real trap. If you’re two hops in, the only clean answer is getting the forwarding software onto the machine actually running CAD, not the desktop in the middle.
On FlexiHub, I’d frame it a little differently than the reconnect-after-drop pitch above. The convenience of picking the device back off a list is nice, but the reason it fits this thread is that it doesn’t care about your RDP topology at all. You install it on the final workstation and the client, and the intermediate desktop stops being part of the equation. That sidesteps exactly the architecture problem raised earlier. It’s still a network service your IT has to bless, and it won’t rescue you from a slow pipe, so before you commit a full shift to it, load a heavy assembly and see how the axes feel under real conditions, not an empty scene.
The ability to rotate a model by interacting with the puck would be a partial success if I were using its buttons and accelerometers throughout the day. I am skeptical of any forwarding arrangement that amounts to a solution for people whose work revolves around device detection and smooth transformations. But what exactly would have to function for it to be not a partial, but an outright success? The axes alone, or do I have to be able to rely on the whole control scheme?
The trainer check is a reasonable way to troubleshoot the issue, but I would separate the acceptance of daily use from this list. In your CAD application, check if the buttons you assigned to it, the keybindings you set up still work, and if the controls in general stop being a hurdle when you switch between it and another application via a document or a dialog window. All of these tests are orthogonal to the question of the remote workstation’s ability to read the hardware.
I would make a list of controls I cannot work without before investing in a forwarding arrangement. It might be more honest to make myself a list of what I can do without. If rotating the model in space is an unquestionable must, but I find myself always reaching for the keyboard to do everything else, that might be a tolerable productivity hit for a seamless experience.
Don’t pay for a forwarding setup until you know whether you’ll be allowed to reconnect the device yourself. Reading these replies, I’m getting stuck on the difference between “IT approves the installation” and “I can fix a dropped connection without calling IT.” I’d ask them explicitly whether releasing and reconnecting the mouse would be available under your normal work account.
@chris59 is looking at which controls you can live without. I’d put waiting for support on that list too. For me, the useful trial would include disconnecting it and trying to get back to work with only the permissions you actually have during a shift. An administrator getting everything running once wouldn’t answer that question.