As we near the release of Windows 8 and Windows Server 2012, it's worth taking a look at how a few things have changed with Microsoft RDS in the new version. Most of the changes aren't earth-shattering or revolutionary, but there are a few surprises.
Of course, there will also be some features that will have you saying "It's about time!" Microsoft has come a long way from the virtual desktop infrastructure (VDI) capabilities of Windows Server 2008, making VDI deployment simpler in this latest release.
What's happening to RDP?
Perhaps you've already heard that Microsoft has all but abandoned the Remote Desktop Protocol (RDP) name in favor of RemoteFX. That doesn't mean RDP is gone, though. Remember, RemoteFX was an option on top of RDP in Server 2008 R2, but with a virtual desktop infrastructure (VDI) workload, it required a separate, compatible GPU to handle encoding. This made RemoteFX more of a niche solution and prevented widespread adoption.
At the same time, though, RemoteFX on Remote Desktop Services (RDS) did not require a GPU. Instead, it used software encoding that, while not as efficient as handling encoding with a separate GPU, was still a step or two up in terms of the remote desktop experience. Companies loved that they could just start using RemoteFX on Remote Desktop Session Hosts (RDSH) without any additional cost or hardware.
More on Microsoft RDS
VDI vs. Remote Desktop Services
Microsoft RDS in a mobile world
RemoteFX requirements in Windows Server 2012
With Windows Server 2012, Microsoft has made the software encoding version of RemoteFX available for VDI as well and has all but renamed RDP to RemoteFX. The underlying technology will still be RDP, but this latest evolution will be called RemoteFX (sort of like how Citrix HDX is the new name for its ICA protocol).
Where the encoding happens isn't the only thing changing. There are other new features that probably deserve their own articles. For instance, RemoteFX traditionally used the Transmission Control Protocol (TCP), but in Server 2012 it will be updated to also work via the User Datagram Protocol (UDP). This means that RemoteFX will use each protocol depending on what's being asked of it.
For instance, if a movie is playing, it may be more efficient to use UDP, which blasts packets from one place to another without waiting for handshakes or acknowledgements. Conversely, for things like keyboard strokes or mouse-button pushes, it would use TCP to verify that all the data is going where it needs to go, when it needs to go there. The end result is a nimble, efficient protocol that is also more effective over the WAN.
No more trickery to make VDI work
As we learned during BrianMadden.com's Geek Week way back in 2009, Microsoft has had what we call an "in-box" VDI offering as part of Windows Server 2008. If you think of it, all the parts were there. They had a broker, license server, hypervisor, secure gateway and Web interface, but there was nothing formalized pulling it all together. In fact, installing and deploying the built-in VDI offering from Server 2008 was one of the most convoluted things I've ever done.
The problem was that even though you had all the required components, the Remote Desktop Connection Broker wasn't aware of VDI or that virtual machines running Windows 7 could have remote desktop sessions on them. Instead, it only knew about terminal servers (RDSH servers).
Rather than update the broker, Microsoft's solution was to trick the broker into thinking it was guiding the users to an RDSH server by putting an RDSH server in "redirection mode," which is essentially an RDSH server without sessions. The users are then redirected to a virtual instance of Windows XP or Windows 7 running on Hyper-V.
As complex as that is, it was exacerbated by the fact that nothing was intuitive to set up. You'd need to install a simple role, and then change it to do something it wasn't meant to do. There were scripts to run, registry entries to change and a host of things that should never have to happen to deploy a remote desktop offering. In the end, the in-box VDI tool was complex and impractical, and it had to change.
In Windows Server 2012, the connection broker is now aware of both RDSH sessions and VDI sessions (that come via the Remote Desktop Virtualization Host role). What you get is a relatively easy solution where everything works the way it should (Figure 1).
In addition to an easy-to-follow workflow, Microsoft has also fixed the implementation and management problem of VDI based on Remote Desktop Services and Hyper-V. In Windows Server 2012, the setup is wizard-based via Server Manager. All the components and roles are installed in a controlled, automated fashion on the appropriate servers (all from a single location).
Likewise, ongoing management is done from Server Manager. Remote Desktop Configuration and Remote Desktop Manager are utilities of the past. Plus, if wizards aren't your thing, you can do all the installations and configurations using Windows PowerShell.
With Server 2012, Microsoft seems to putting all the technology they've been creating or acquiring over the years into a usable package. Will the new solution that works with terminal servers and VDI -- plus the changes to RemoteFX -- be enough to make a dent in the reign of Citrix, VMware and Dell/Quest, or will it still leave us wanting more? We'll have to wait and see.
Dig deeper on Terminal Services and Remote Desktop Services
Gabe Knuth asks:
Will RDS in Windows Server 2012 take business away from Citrix, VMware and Dell/Quest?
0 ResponsesJoin the Discussion