To address the problem, the next version of Windows Server 2008 R2 will include the integration of Terminal Services, along with virtual desktop infrastructure support (renamed Remote Desktop Services). It will also add an improved version Terminal Services' underlying technology -- Microsoft's Remote Desktop Protocol (RDP). This will support more enterprise users with faster performance while using less bandwidth.
Improving support for multimedia
Users frequently use media like audio and video -- often spread across multiple monitors -- to boost productivity. This has often proved problematic for virtualized applications and desktops because of limitations in server computing power and bandwidth.
For example, to execute a media application on a virtual desktop, the server would need to open the media file, decode the audio and video on the server, render each screen frame into server memory, and then pass that screen/sound data to the user's display. Performance often suffered and media playback usually fell out of sync. The corresponding demands of rendering a single desktop typically limited a user to a single display.
The RDP used with Windows Server 2008 R2 addresses these limitations. The most notable improvement is in audio/video "redirection" which takes advantage of processing
Enhancements to RDP support bi-directional audio, allowing audio input and recording capabilities that enable things like podcast recording, speech recognition and VoIP applications on the virtual machine (VM). Combined with redirection and architectural improvements, RDP should provide better audio/video synchronization and bolster the overall multimedia experience for virtual users. Improved efficiency and reduced bandwidth needs also provide new opportunities for multiple monitor support. Windows Server 2008 R2 adds support for up to 10 displays of any size, layout or resolution.
Improving support for graphics and UI
As with media files and streams, graphics have been a sticking point for virtualized endpoints. A server needs to render each screen (or more accurately, each change to the screen) to a video buffer in the server's memory. It then passes display data to the endpoint as a bitmap image. While Direct3D -compatible hardware can accelerate this rendering process, it still presents a potential bottleneck for graphics-intensive applications like CAD or video-editing tools. Graphics applications that rely on DirectX 9, 10 and 11 will continue to use this paradigm.
However, applications that support the new DirectX 10.1 API with remote extensions can use RDP to "redirect" the DirectX graphics workload from the server to the client. This has profound implications for the server. Rather than requiring a graphics processor at the server, it can offload DirectX graphics processing to a graphics processor on the endpoint. This allows each respective endpoint to do more of the graphics work locally, enabling more sophisticated graphics that come closer to local system performance.
Another persistent concern with virtual endpoints is the visual difference between local and virtual desktop sessions. Virtualization requires an additional logon and navigation to access the remote desktop. Improvements in interface design help eliminate these visual differences (particularly with VDI), and let remote sessions look exactly like local desktop sessions using established and familiar user interfaces like Aero.
In addition, the language selection for a remote application can be controlled locally; scheduled tasks will execute in the background rather than appearing in the foreground and potentially confusing users. For best results, these interface improvements may require deployment of Windows 7 on the endpoints.
No substitute for testing and configuration
While RDP continues to improve with better performance and some new features, there is no guarantee that it will support every application adequately. The performance of a virtualized environment still depends on available server and network resources, as well as the overall design of the respective applications.
A graphically demanding application that is poorly or inefficiently coded, runs on an underpowered server and communicates across an overtaxed network simply won't behave well -- regardless of the protocol. Pre-deployment testing remains crucially important. Application behavior can be optimized using the compression and bandwidth allocation features in RDP itself.