Channel 9 Video reveals new Longhorn Terminal Server features

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!

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.

Cool.

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.

Join the conversation

16 comments

Send me notifications when other members comment.

Please create a username to comment.

MS are really closing the functionality gap between them and Citrix, Web Interfaces, secure gateways, published apps, seamless windows .....
Good for them I say - nothing like a bit of healthy competition to keep people and their products on their toes ...

I dont suppose you know where I can download a BETA copy of Longhorn server for free do you?
Cheers,
mitch
Cancel
If yoe are MSDN subscriber, you can download the BETA version from subscriber downloads. If your not, I think you have to participate in some beta programs.
Cancel
This is not true yet. The Beta for Longhorn Server is not yet available. The only betas available via MSDN are for the Longhorn Client (now called Vista).

Brian
Cancel
Well it is available and was handed out at PDC (as I have it), but um... it's early so maybe you won't find lab code in there yet.

anon
Cancel
An interesting point was the security topic. What i'd realy like to know is how secure is a server that can only be accessed by common rdp. So how sure can i be that my server can't be "hacked" by just opening rdp port 3389...???
Cancel

Well it seems to me that yea they are moving a bit closer to Citrix in functionality maybe we will be able to get a product that will be worth it all directly from Microsoft, my first thought though is wont Microsoft try to charge us for this?
If they are competitive with Citrix i am sure they will find some way of charging us, killing your competition isnt enough, getting their revenue is, the story of the world we live in :)

But yea as Mitch says, nothing like a little competition to keep people on their toes :)

/Rene
Cancel
>If they are competitive with Citrix i am sure they will find some way of charging us, killing your competition isnt enough, getting their revenue is, the story of the world we live in :)<

To be realistic, it surely wont be as much as Citrix costs - highway robbery if you ask me. MS is needing an image campaign anyway. ; )
Cancel
So... (I liked how they all started their sentences with that) No one mentioned anything about load balancing. Sure, TS Gateway and TS Remoting are going to be great for us people who deal with thin-client computing, but what about load balancing? Windows hasn't been great with this yet, nor is it super-easy. Citrix handles this seamlessly. I think once that issue is solved, we're a lot further from using just TS without Citrix.
Cancel
What's interesting is how shall RAIL work with Linux Thin Clients? I mean i'm not the Linux crack but as far as i know msi packages are not that much well known in the penguin world...
Cancel
Just guessing, but MS hasn't been great about working with other systems (I guess the MAC folks should consider themselves lucky there's an Office for MAC out there). How many OS's does MS make an RDP client for? According to the RDP Client download page, only WIN95 through XP. So unless they make it so the transport at the client level is something else, and they're making it MSI-based, I would imagine this solution will only work for Windows.
Cancel
Take a look at [link=http:
Available this year, not 2007. And it does encrypted RDP over HTTP for situations where HTTPS is unavailable.

bye!
Cancel
Actually it says expected release of october 2005, so it's definately not here. As well it gives no description of how it works. It is a man in the middle like CSG or do you have to expose your servers to the Internet? it may be a great solution but without any details, it's hard to know.

so please, don't go bye bye, if you know more, let everyone know.
Cancel
Hi Jeff!

I've just seen your post.

I am part of the developement team and can send you an evaluation version if you're interested.

Additionally, we have installed a beta tester program at tunnel2.com.

Btw, the gateway does not only support HTTPS but even plain HTTP with rdp-level-encryption. Thats equally secure, even simpler to configure and won't be blocked by firewalls that use https-whitelists.

Best regards,

Juergen
Cancel
Hi, Juergen!
 
 
Tested your stuff through our local ISA server (authenticating proxy) via HTTP and HTTPS (accessed your testserver).
 
Works fine so far :-)
 
 
Will install the server-part for IIS next week and contact you through your webpage then.
 
Bye!
 
AlexP
 
 
ORIGINAL: Juergen

Hi Jeff!

I've just seen your post.

I am part of the developement team and can send you an evaluation version if you're interested.

Additionally, we have installed a beta tester program at tunnel2.com.

Btw, the gateway does not only support HTTPS but even plain HTTP with rdp-level-encryption. Thats equally secure, even simpler to configure and won't be blocked by firewalls that use https-whitelists.

Best regards,

Juergen

Cancel
Hi Jeff!

Nice to read your reply. We've had a very long beta phase but now everything is working (and performing!) as exptected.

I hope you'll be satisfied with the server component as well.

Best regards,

Juergen
Cancel
In the demo, he had to log in to access Excel, is there still no pass-through authentication even for published apps?
Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close