Yesterday Channel 9 (the MSDN video blog) released an hour-long video of interviews with different members of Microsoft's Terminal Server product group. The video also give a tour of their offices, so now you can pretend like you know them! The video is a 200MB WMV file, but it's definitely worth downloading. You can get it directly from Channel 9.
Here are the highlights and my comments if you don’t have time to watch the whole thing:
Behind the camera is Robert Scoble, of the Scobleizer blog fame. The video starts off with an interview with Tad Brockway, the Group Program Manager for the Terminal Services product development team. This interview is pretty basic, as Tad talks about the basics of Terminal Services and how the different technologies are owned by different groups within Microsoft.
Fun Fact: Did you know that the RDP protocol was originally based on the NetMeeting protocol?
At 7:42 (as in 7 minutes and 42 seconds into the video), Tad mentioned that Windows clients in the Longhorn days will be able to "remote a single application." This is a fancy way of saying Terminal Server will offer “Published Applications” and "Seamless Windows." This set of technologies is codenamed “RAIL” (remote applications integrated locally).
The other major enhancement to Terminal Server for Longhorn is something called the “Terminal Server Gateway,” which is RDP over HTTPS.
At 10:29 in the video, Tad provided a live “show and tell” demo from a near Beta 1 Longhorn server and Beta 1 Vista client. He walked us through the process or publishing and application and connecting seamlessly from a client.
The first step is to create an application package. This package lets the user connect to a specific application by name instead of having to first connect to a server and then run the app. This is done on the server with a "Remote Application Publishing Wizard" that creates an RDP file or MSI package that can be pushed out to client desktops using group policy, SMS, Intellimirror, or whatever. The wizard digs through the start menu to provide a list of all the apps that are installed on the server, just like Citrix's application publishing wizard in their SMB Access Essentials product. An MSI package created by this wizard can be configured to connect via a TS gateway and is only about 70kb in size.
Tad then moved over to his Vista workstation, double-clicked the MSI file, and a few seconds later his newly-published application appeared in his start menu. The MSI file built the icons, shortcuts, and took care of the appropriate file type associations. Running the remote application looked pretty much like any remote application experience. The only notable aspect was that the remote application’s title bar had the old school square-ish dark blue color, not the smooth Avalon/WinFX bubble-gum style bar.
Tad also showed MSN messenger as a remote seamless app, complete with full systray and toast integration. (“Toast,” I learned, is Microsoft slang for those little Windows that slide up in the lower right corner of your screen that Messenger uses to tell you that your buddies are online.)
The interviewer and Tad chatted for a bit about how remote windows works. At one point the interviewer asked, “You don't share DirectX calls?" Tad’s answer of "today we don't" hinted of a possible new feature in future versions of the platform.
Finally, Tad showed a prototype of a web portal (which you can download via the Beta 1 of Longhorn) that works like Citrix's web interface. It wasn’t so much of a real product as it was some custom ASP and Java code wrapped around these application packages that pushes RDP files out to users for seamless published remote applications.
At 23:18, Tad and the Robert started walking the halls of the TS product group in a Mr. Roger’s-style tour to meet the neighbors.
They first met Costin Hagiu. He’s a TS Test lead who talked more about 64-bit Terminal Server. While they wouldn’t give specific scalability numbers, they feel it’s basically “as many users as the hardware allows.”
At 27:22 Tad and Costin headed into the test lab (where, by the way, everything I saw was Dell). This is the place where they do all the Terminal Server scalability testing, and Costin talked a little bit about how they perform their scalability and load testing.
At 30:53 they headed over to Geanina Andreiu’s office. She’s a member of the test team and owns the Terminal Server administration services. From an administrative standpoint, they’re trying to make their stuff more easy to use and more discoverable. Geanina also talked a bit about the Terminal Server WMI provider. It is very complete which is something they’re really proud of. For Terminal Server, you can use WMI to configure everything… settings, session directory, group policy settings… everything!
At 36:00, Tad interrupted two guys from the TS Gateway team named Ido and Meher. They talked a bit more about the gateway and told us that most of the TS code (both core TS code and in the gateway) was written C++ with some C.
Finally, at 38:30, Tad and Scoble visited the office of Nadim Abdo, the development lead for RDP team. The own the remote programs functionality, RDP performance, and pretty much anything else RDP-related. Apart from learning about the new Longhorn TS features, the conversation with Nadim was the most interesting to me. Nadim explained how the RDP protocol worked. (These next two paragraphs are almost direct quotes from him):
RDP is the protocol for remoting the windows experience. Today that’s primarily graphics. Terminal Server and RDP work by abstracting a lot of things out of the system. For RDP, Microsoft actually created a display driver called RDPDD that writes to the network instead of writing to a display. On the client side, the RDP client is just a GDI application that decodes the network format from RDP and uses GDI to play back what’s happening. That’s how the applications on the server can get away without knowing anything about TS or RDP. RDP tries to be smart for optimizations, and tries to be clever about how things are displayed when things get backed up on the network.
RDP tries to be as efficient as possible about what it sends over the network. For example, if you had a full screen that you had to send to a client, you could send it over as a bitmap. That would be the lowest common denominator, but that would be very bandwidth intensive. You’d be waiting and waiting even on the fastest links. But, since RDP is a display driver, it can intercept some higher-level primitives. So, for example, Excel comes along and says “I’m going to paint a cell.” Well to paint that it’s going to paint a bunch of lines and a rectangle and then paint some text in it. The RDP display driver gets all those instructions and is able to encode them using RDP in an efficient way for transmission over the network. So the client is actually painting what your display driver was told to paint. RDP tries to paint more complex primitives than bitmaps wherever it can.
Nadim also mentioned that Microsoft is trying to be very intentional about making sure that RDP is totally quiet if you’re not using anything on the screen while still providing a remote experience that’s as indistinguishable as possible from using local applications. He conceding that there are still a few cues that tip off people when they’re working in a remote RDP session, but they’re trying to get rid of those.