Windows Server 2012 Simplifies VDI Deployment with Microsoft RDS

With the release of Windows 8 and Windows Server 2012 approaching, it's worth taking a moment to understand the changes in the new Microsoft RDS. Although there is almost no revolutionary change, it is still a surprise. Of course, there will be some features that make you feel "It's time!" ”. Microsoft has made significant improvements in the VDI capabilities of Windows Server 2012, simplifying VDI deployment. Changes in RDP Perhaps you have heard that Microsoft has retained a lot, but abandoned the RDP (Remote Desktop Protocol) naming and replaced it with RemoteFX. This does not mean that RDP is over. In Server 2008 R2, RemoteFX is one of the RDP options, but considering the VDI load problem, it requires a separate, more compatible GPU to perform the encoding. This makes RemoteFX more like an immature solution and limits its applicability. On the other hand, RDS-based RemoteFX does not require a dedicated GPU, but is implemented by software coding. This is less efficient than a dedicated GPU, and there are some gaps in the remote desktop user experience. Users like to use RemoteFX based on RDSH (RemoteFX on Remote Desktop Session Hosts) because no additional cost or hardware support is required. In Windows Server 2012, Microsoft added a software-encoded version of RemoteFX to support VDI, while retaining other features, just renamed RDP to RemoteFX. The underlying technology is still RDP, but the latest version is called RemoteFX (similar to Citrix HDX is actually the new name for the ICA protocol). Encoding is not the only change, there are other things that deserve special attention. For example, RemoteFX is based on the TCP (Transmission Control Protocol) protocol, and Windows Server 2012 supports the UDP (User Datagram Protocol) protocol. This means that RemoteFX will adopt the corresponding protocol according to the access requirements. For example, if you play a movie, the UDP protocol is more efficient, transferring large numbers of packets between two points without waiting for handshakes and acknowledgments. Conversely, for keyboard and mouse click input, the TCP protocol is used to verify that all data arrives correctly at the destination. Therefore, the end result is the introduction of agile and efficient protocols to meet the needs of WAN use. Reducing the pitfalls of performing VDI work As we learned in Brian Madden.com's Geek Week in 2009, Microsoft already has an all-in-one VDI product called "in-box" in Windows Server 2008. If you look closely, you'll find that all the components, such as the broker, license server, hypervisor, secure gateway, and Web interface, are available, but there is an official tool that links them all together. In fact, installing and deploying the Server 2008 built-in VDI solution is one of the most complicated tasks I have ever done. The problem is that even if you have all the required components, the Remote Desktop Connection Broker still cannot recognize VDI or a virtual machine running Windows 7 cannot open a remote desktop session. It only recognizes the terminal (RDSH) server. Microsoft's solution is not to upgrade the broker, but to set the RDSH Server to "redirection mode" to trick the broker into thinking that it is directing the user connection to the RDSH Server, but actually the RDSH server without any sessions. The user is then redirected to a Windows XP or Windows 7 instance running on Hyper-V. This is too complicated, especially the steps required for installation are intuitively difficult to understand. We need to install a simple role and then change it to do something that we shouldn't have to do. There are a few scripts that can be run, login registration, and a lot of work that you didn't need to do when deploying a remote desktop product. In the end, the in-box VDI tool became complicated and impractical. It needs to change. In Windows Server 2012, the connection broker can identify both RDSH sessions and VDI sessions (from the RDVH role). The user gets a very simple solution and all the work is done normally. In addition to easy-to-track workflows, Microsoft has also fixed VDI deployment and management issues based on RDS and Hyper-V. The installation process in Windows Server 2012 is based on the Server Manager wizard. All components and roles are installed to the appropriate server in a controlled and automated manner (all at a single site). Similarly, the next management work can also be done through the Server Manager. Both Remote Desktop Configuration and Remote Desktop Manager are tools of the past. Also, if you don't want to use the wizard, you can install and configure it through Windows PowerShell. In Server 2012, Microsoft seems to have incorporated all the technologies that have been created or mastered in the past few years. Will these new solutions work with Terminal Server and VDI (including the name change to RemoteFX) to compete with Citrix, VMware and Dell/Quest in the field, or are they still lacking? We will wait and see.