A while back (2 years ago now), I wrote a follow up post about building a standalone Lync system on a laptop using HyperV, and at the end had everything working except for remoteFX USB redirection. Time passed, and I didn’t give it much though until I got a new set of VMs that I wanted to experiment with, and came across the old problem of being able to test AV calls without an audio device. I was, however, able to get audio redirection working, which helped, but that still meant that all remote connections shared the default device. I thought there was a better solution, and as it turns out, there is, but you need to do some work to enable it…
There’s a good overview on what RemoteFX USB redirection does and how to configure it here on MSDN, although I did have to make some changes to the steps there to do what I needed to get it to work.
Here’s the VM environment I started out with:
- Host: Windows 8.1 with HyperV role, and 2 virtual switches, one sharing the ethernet adapter, and one private
- DC: A Windows Server 2012 R2 DC running ADDS, CA, DNS, and DHCP (private network)
- Lync 2013 SE: Running Server 2012 R2 (private network)
- Terminal Server: Running Server 2012 R2, Remote Desktop Services, and Office 2013 (connected to both the private and external networks).
At this point, I could RDP into the terminal server, run Lync in two sessions, and IM between them. To enable USB redirection though, you need to change some things on both the domain policy (or the policy of the TS I suppose) AND on your local PC, plus you’ll need to connect to the remote session in a very specific way:
On the Domain policy (I changed this under “Default Domain Policy\Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\”, so I’m assuming that as the starting point for any paths):
- Change “Remote Desktop Connection Client\RemoteFX USB Device Redirection\Allow RDP redirection of other supported RemoteFX USB devices” to enabled:
- You may also want to change “Allow audio and video playback redirection” and “allow audio recording redirection” under “Remote Desktop Session\Device and Resource Redirection\”. This is what allows you to share the default devices on an RDP session (sometimes useful).
Once those changes are made, update the policy (gpupdate /force) on the terminal server. Before you remote in though, you’ll need to change a policy setting on your local machine. Go to “Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\RemoteFX USB Device Redirection, and edit “Allow RDP redirection of other supported RemoteFX USB devices from this computer”:
Once that’s done, you’ll need to reboot, make sure the VMs are started, and then RDP into them. In the RDP connection dialog, you’ll need to change a couple of things on the “Local Resources” tab:
First, click the “more” button and select the devices you want to redirect (in this case, a headset and camera)
Next, click the remote audio settings and disable remote audio playback and recording. These settings will override USB redirection and will mean that “remote audio” is the only device that appears in the VM.
Then connect to the session, and you should see a driver installation dialog that says something like “installing Plantronics Savi 7xx-M (redirected)” that should disappear fairly quickly. After that, you should have your AV device appearing natively in the remote desktop session.
Of course, this works for multiple sessions and devices as well, so if you connect two headsets or speakerphones and two cameras, and log into the TS via RDP with two different users, you can place a video call between them and have each user get their own audio and video device. The number of unique AV devices is really only limited by the number of USB ports you have available.
Note that you can also do this through the enhanced RDP connection if you’re running Gen2 VMs (which is just running a remote desktop session anyway). This is useful because you don’t even need the external network adapter enabled:
Now, as for why this is useful, it’s great if you want to validate AV conferencing scenarios, or, say, UCMA applications that use custom audio routes, and want to do all of this in an isolated VM environment where it’s also not really practical to attach multiple devices to the virtual switch, which is where I use this kind of setup. However you use it though, this is kind of a neat setup to show people, and it helped me understand how some new virtualization and remote desktop features work.