The future of Windows Terminal Services
As part of the announcement of the changes to the Longhorn Client and server announcements some more details have started to emerge around the future of Terminal Services. The timeline appears to be:
- As part of the next Service pack for Windows 2003 server we will get access to WTS over https, 2004/5.
- As part of the longhorn server release we will get application publishing, seamless windows, and redirection at the XAML level, rather than the “Virtual device driver level”. This will allow DirectX equipped clients to render XAML locally. In addition it seems that it may be possible to seamlessly integrate content from multiple application servers and local applications onto a single local canvas. 2007.
These two changes will have a dramatic effect on the future of application publishing. rich applications can be seamlessly integrated on the rich client. I know that there is some comment that the Avalon team are a bit confused right now over how they are going to implement some of these features with an Avalon Stack ported to XP and Windows 2003 as well as Longhorn, so there may be some changes to these plans.
There is an interesting lock-in/value proposition that seem to arise here as the implication is that Windows Application servers publishing XAML will only work with Windows Clients. Citrix will probably be left addressing only the non Windows Client market. Remember that currently Microsoft software runs on 70+% of all thin clients currently as well as 90%+ thick clients.
I have provided some links and snippets from the most interesting articles I can find on this topic.
The Future of Terminal Services: 2007 and Beyond
Conceptually, this local rendering is how Terminal Services will work in Longhorn’s Avalon presentation layer. A longhorn application (web, local, or whatever) will send XAML markup code to the Avalon system where it will be rendered to the screen. In traditional Terminal Server environments, the screen would be deconstructed and sent down to the client device as screen pixel data. However, why not just send the raw XAML code to the client device directly? After all, this solution is good enough for web surfing. The only reason we don’t do this with today’s Windows apps is because there is no XAML-like intermediary.
An added benefit of this model is that we will finally get “true” local and remote application interaction and integration—far beyond today’s “cut and paste” integration. We’ll also see “remote” applications that feel local, complete with the proper local colors and themes.
Will this be the end of our niche? Will Citrix’s dominance of the thin client computing industry die as the industry fundamentally changes? Will I get everything I predicted horribly wrong? I can’t wait to find out.
It’s Official! Microsoft is Adding an RDP over HTTPS Proxy to Windows
One of the new Terminal Services features is the ability for a Windows Server to encapsulate and proxy RDP traffic over HTTPS connections. The RDP over HTTPS proxy is part of what Microsoft calls “Anywhere Access.” Not to be confused with Citrix’s “Access Infrastructure,” Microsoft’s Anywhere Access will allow users to securely access corporate resources over the public Internet without using VPN software.
This capability is already available today for users connecting to Microsoft Exchange 2003 Servers from Outlook 2003 clients. In this case, the Exchange/Outlook connection uses Windows Server 2003’s built-in RPC proxy. Essentially, standard RPC traffic is wrapped in HTTPS at the client. A Windows 2003 IIS server receives the HTTPS packets, pulls out the RPC data, and forwards the packets off to the Exchange server. This allows users to have “full” Outlook RPC-based connectivity using standard SSL-encrypted HTTPS traffic.
For the Anywhere Access component of R2, Microsoft is expanding the RPC proxy’s capabilities so that it can also support SMB file shares and RDP Terminal Server sessions. This will allow users to securely connect to a Terminal Server across the Internet and is a direct threat to Citrix’s MetaFrame Secure Gateway product.
So what about Citrix? Their MetaFrame products are based on Terminal Server, and they makes use of the same “screen scrape” technology. Sure, Citrix’s new “Hudson” version of MetaFrame Presentation Server (due out later this year) will make several important steps towards Microsoft’s vision of seamless computing (as seen in features like dynamic “follow me” roaming). In fact, over the next 18 months, Citrix will most likely integrate the newly-acquired Expertcity GoToMyPC technology so that users can start an application on a local workstation and then have it “follow them” to other devices once they leave that workstation (with users accessing the application on that workstation via ICA and the standard Web Interface and Secure Gateway components). However, the point remains that underneath all the shiny new features, the “ Hudson ” edition of Citrix MetaFrame will still be based on ten year old Terminal Server technology.
How Terminal Services will Help Microsoft Deliver the .NET Vision
So what does all this have to do with .NET? By transferring Avalon Primitives and raw XML component data via RDP, local client devices will essentially become “presentation aggregators” for applications. This goes beyond .NET web services. True, rich data from multiple applications on multiple servers can be aggregated, consumed, processed, and used by local devices. Microsoft can use Terminal Services as a conduit for getting true .NET applications onto users’ desktops.
In this sense, Terminal Servers will become more like generic application servers, almost like traditional client-server architectures. However, this time around, the performance of the application will not be limited by connection speed or local client resources. Furthermore, the push towards utility computing will build more resilient data centers that are dynamic and flexible.
At the same time, fluid computing technology will allow users to disconnect and reconnect from applications anywhere. (We’re already starting to see this in Citrix’s new SmoothRoam technology.) Applications will be able to dynamically resize themselves and turn on and off different bits of the interface depending on the type of device that you’re connecting from.
I think Microsoft will ultimately change the name of Terminal Services. Most likely we’ll see Terminal Server become something like “Remote Application Server.” (I think Citrix’s “Presentation Server” is a really good name.) Maybe RDP will become RAP (Remote Application Protocol) or RCP (Remote Computing Protocol)?
Throughout all of this, however, there will always be a place for “screen scrape” technology. Ultimately, these protocols and systems will be smart enough to figure out what’s needed where. There’s a good chance that true “thin client” devices will exist for a long time. (Even a truly “dumb” client device will still be able to realize these advantages. The Longhorn Terminal Server will act as their application aggregator, and dumb client devices will be able to scrape a smarter screen.
Quote from Microsoft Avalon Development Team
Longhorn newsgroups already prove to be a great resource for all interested in Longhorn. Here is an answer from the member of Avalon Team on the question about Remote Desktop:
Avalon will support remoting at a higher level than DirectX. When remoting we will not rasterize on the server machine but instead we will send higher level graphics instructions to the client machine and then call DirectX on the client machine.
This will enable us to send less data over the network as well as reducing the server load because all graphics operations will run on the client machine. We also will get higher performance and fidelity rendering and animations because we will not need to round trip data across the network for these operations since they will be retained on the client machine.
