It’s no secret that Microsoft are struggling to stay relevant in todays open-source world without page boundaries, but they do have the upper hand in some areas. Take VDI – although Windows 7 is an awful platform for VDI, being so chatty and especially when it comes to disk, but Terminal Server shines, and with 2012, it really shines.
Everyone wants a rich-media enabled desktop. And it’s hardly a big ask in the smart-phone, media-powered world in which we find ourselves. Yet until now, RDP has meant video playing like the server somehow offloaded the content to a 386-powered multimedia PC from 1991.
RemoteFX
RemoteFX arrived with Windows Server 2008 R2, offering compression and media redirection with the aim of improving things. Scrolling a PDF for example on a 2008 R2 Terminal Server (with RDP 7.1 client) uses about 1/3rd of the bandwidth as on a 2008 Terminal Server, and playing a WMV file in Windows Media Player (WMP) uses content redirection, so rendering the video on the client device for a properly smooth video experience. Try it!
Meanwhile Microsoft have done a great job confusing everybody it seems with RemoteFX in Server 2012. RemoteFX has grown into a suite of technologies to enhance graphics on RDP, but the confusion has arisen because the hardware requirements for RemoteFX when operating in a classic VDI model (i.e. with Windows 8 VMs) are quite complex, needing dedicated graphics hardware and SLAT. And that means RemoteFX for Windows 8 VMs presumably won’t work under VMware.
But the hardware requirements for RemoteFX in Terminal Server (aka Remote Desktop Server Session Host) deployments? These are simple: SSE2, which arrived with Pentium 4 in 2001. Essentially then, none. And this works in virtual Terminal Servers too.
Configuration
To get RemoteFX working for RDS in Server 2012, we just need to install the RDS Session Host roles – that’s it! Everything has been designed to work straight out the box. The one gotcha is that it needs RDP Client v8 of course, which for some reason Microsoft makes difficult to download. Either spend about an hour fighting Microsoft updates 2574819 and 2592687, or for Windows 7 (x64) clients just copy mstsc from the Server 2012 installation as detailed here. Using the Microsoft updates, note that there is no local security policy editor for certain Windows 7 editions (like starter), but that’s only needed to enable the UDP transport which isn’t essential anyway.
Performance
This of course is the big question: what does it actually do? Lots, actually. But for me most importantly, video – regardless of the application or file format – is detected and the mechanism used to deliver the video to the client is dynamically determined based on bandwidth and latency, and can (and will) change continuously in real-time. Essentially, when moving content is detected, the RDS server switches to a video-conferencing style of encoding using H.264.
Of course real-time H.264 encoding comes at a cost in CPU cycles. Testing on my laptop (Server 2012 VMs running under KVM on 3rd-gen Ivy Bridge CPU) a single full-screen RDP session entirely absorbs one CPU core at 3GHz (on the server side) and 100% of an Atom N450 on the client side. But, it does work!
Bandwidth depends on the video bit rate, file type, codec, client resolution, and the playing application. Windows Media Player still benefits from media redirection and so has much lower server CPU and network bandwidth needs (say 50% of one core on the server side, and about 3Mbps network in my particular test). Switching to VLC with the same video, server CPU jumped to ~130% of one core, and network bandwidth to about 6Mbps, the RDS server transcoding screen refresh to an H.264 stream on-the-fly. In both cases, the Atom N450 client I was using was properly maxed, but the video was acceptable. Moving to a newer Intel B950 CPU, the client side runs at about 25% and full screen video works just fine.
Switching back to RDP 7.1, the difference is clear. With only WMP redirection at hand, playing video outside of Media Player runs straight into network bandwidth constraint with the continual bitmap refreshes, c.20Mbps on my home wireless, and is totally unusable, whilst WMP redirection itself of course works fine at about 3Mbps.
In Summary
For Terminal Server deployments, the Windows Server 2012 RemoteFX Requirements are simply to have a CPU with SSE2, which is provided by all commodity hypervisors and any CPU that will run Server 2012. RemoteFX for Remote Desktop Session Hosts works just fine on virtualised terminal servers, but the H.264 media transcoding is CPU intensive and when in use, a single user will chew up about 3GHz of an Ivy Bridge CPU.
Nevertheless, it’s a big step forward for Microsoft and in my opinion this will only reinforce the trend of Terminal Server replacing Windows XP on the Corporate Desktop, rather than any Windows derivative other than for it’s RDP client.
Get the RDP 8 client either from Microsoft updates 2574819 and 2592687, or from the Windows Server 2012 installation itself.
VN:D [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:D [1.9.22_1171]
My budget would stretch only to