More Longhorn Terminal Server details uncovered in yesterday's product group chat

As many of you know, the Microsoft Terminal Server Product Team hosted a live chat yesterday. There were a lot of great questions and it was a great opportunity to interact directly with the Terminal Server group.

As many of you know, the Microsoft Terminal Server Product Team hosted a live chat yesterday. There were a lot of great questions and it was a great opportunity to interact directly with the Terminal Server group. A PDF transcript of the chat is available above, and highlights are covered in this article.

The experts present in the chat from the Terminal Services Product Team included:

Ted Kummert -- Vice President of the Security, Access and Solutions Division
Chandra Shekaran -- Product Unit Manager of Terminal Services
Maxim Oustiougov -- Program Manager with Microsoft's Terminal Services team
Alex Balcanquall -- Product Manager for Terminal Services
Tad Brockway -- Group Program Manager, for the Terminal Services Product Development
Nelly Porter -- Lead Program Manager on Terminal Services team
Joy Chik -- Development Manager for Terminal Server
Guaray -- Program Manager in the Windows Terminal Services team
Samim Erdogan -- Program Manager with the Terminal Services Team

So what’s the latest with Longhorn Server? Let’s start by taking a brief look at what we learned from the last live chat held on this topic in September, 2005.

  • Application Publishing with client-side file type associations
  • Seamless Windows
  • A Terminal Server Gateway (TSG)
  • Intelligent Avalon/WinFX Remoting
  • A Unified Management Console
  • Redirection of Plug-n-Play devices with UDMF drivers
  • Major Reworking of the Logon Process
  • Per-User Licenses will be Tracked
  • Web interface
  • RDP 6
  • A Refined Windows System Resource Manager (WSRM)
  • WMI Interface for Everything
  • RDP Virtual Channel Tuning.

The above features are discussed in more detail here.

After reading this list of features, a common question is (and has been), “is Microsoft trying to compete with Citrix, its own ISV partner?” Tad Brockway reiterated Microsoft’s position on this question in yesterday’s chat saying,

Citrix will continue to add great value on top of our Longhorn Server feature set. It's our goal, for Longhorn, for customers to have the basic features in-the-Windows-box for scenarios of small to medium scale and complexity. So, Longhorn Server will include features, like: Remote Programs and a Terminal Server Gateway for VPN-less access to TS resources. In terms of deployment scenarios, our ISV partners will add value on top of these features as well as our existing features.

This is a good perspective for us, the system engineers, to keep in mind as our managers and clients ask us why Microsoft is adding some of the same features as Citrix.

What we learned from the August 2006 chat…

Beyond the features discussed in the September 2005 chat, we learned of some additional features slated to be released with Windows Longhorn.

Softricity Acquisition

Microsoft’s acquisition of Softricity has been a hot topic as of late and in yesterday’s chat the community was able to ask if there were any plans to incorporate Softricity specifically with Terminal Server. (Until now the rumor had been that Softricity would be incorporated with the SMS group.) While no specifics were released on how Softricity will be built-in to Microsoft products, Chandra Shekaran indicated that there will be involvements with Terminal Services. When asked specifically how the Softricity acquisition will affect Terminal Services in Longhorn, Chandra provided us with this insight:

In the medium term, one should expect TS Application Compatibility and efficiency of TS deployments to significantly improve. That said, we just closed on the acquisition and haven't finalized product evolution or announced licensing plans going forward. We will announce more details in the next couple of weeks.

It will be interesting to hear how Softricity may interact with Terminal Server in the future.

Monitor Spanning

Whether or not multi-monitor support would be supported in Longhorn Server was another popular topic. Longhorn Server and the RDP 6.0 client will not provide multi-monitor support, but will provide “monitor spanning.” So what’s the difference? With monitor spanning, the system only "sees" one display. Therefore if you had two monitors, your start menu taskbar would stretch across both screens. You would have some ability to move and resize windows to one monitor or the nother, but the system only sees it as one display. A popup message would appear "on the seam" in the middle of your display, half on one monitor and half on the other.

With true multi-monitor support, using the same example of two monitors, the system would see the extra display and therefore your taskbar, and pop up messages etc., would appear only on your primary display. You would be able to maximize windows within their specific display without having them stretch across both.

The new RDP client will allow you to invoke monitor spanning from the command prompt via mstsc.exe /span.

Terminal Server Web Access (TS Web Access or TSWA)

Terminal Server Web Access provides a web interface to remote programs. (TS Web Access is to Remote Programs as Web Interface is to Published Applications. S.A.T. flashback anyone?) Tad made a good analogy comparing TSWA to OWA (Outlook Web Access).

TS Web Access can be configured in two modes; Simple Mode and Group Policy Mode. Simple mode is configured per Terminal Server and Group Policy Mode, as you may expect, is configured in Active Directory Group Policy. Samim went on to explain:

In TSWebAccess: There are two modes: Simple Mode and GP (Group Policy) mode. In Simple mode, it is possible to point the TSWebAccess page to a particular TS installation or deployment. You can use multiple TS Servers in this mode as long as the servers are all in a farm accessible with the same DNS name. In the GP mode, the app definitions come from Group Policy.


There is an indication, based on today’s chat, that there is going to be a big overhaul to profiles. (Woo hoo!) Alex Balcanquall states,

I am not sure what we have announced but yes profiles and folder redirection have been enhanced. For example profile sync has been vastly improved and is more efficient, almost all folders can be redirected and sync is super efficient for off line files; the new profile service ensure profile corruption is mitigated in most scenarios. Basically vastly improved.

Will roaming profiles as we know them (slow and prone to corruption like an Enron executive) soon be a thing of the past?

Enhancements to RDP and WPF Remoting

There were a handful of audio-video improvements announced to release with the next version of the RDP client. Among them, ClearType support and 32-bit color depth in RDP. In addition, Microsoft announced that they are working on enabling audio redirection for MIDI formats.

Another popular topic in the chat was how Windows Presentation Foundations (WPF) Remoting, also known as Avalon/WinFX Remoting, will work in Longhron. Just so we have all the terminology out there, WinFX technology is now referred to as the ".NET Framework 3.0." Aero-Glass, which was referred to in the chat as well, is one theme available in WPF. What is WPF Remoting? In short, WPF Remoting changes how and where an application is rendered and presented to the user via Terminal Services. You can read more about it about this here.

Advantages to WPF Remoting include:

  1. Less network bandwidth utilization
  2. A more seamless client experience. For example, remote applications will feel more integrated with the client.
  3. Less server load since less rendering is not taking place there.

On the other hand, the main disadvantages to WPF Remoting is that you must have a client that's running WPF, either Vista or a Windows XP with the WinFX / .NET Framework 3.0 update.

The big question is "will WPF Remoting be released with Longhorn?" Previously we thought this answer was "yes." However, when the question was asked, “What support will Longhorn Terminal Services provide for Avalon-based applications?” The response given was,

Yes, we are working to support Aero-Glass via RDP, when connecting from a Vista client. …. We have more work to do and we haven't yet targeted a specific release vehicle. (Tad Brockway)

Based on this answer it doesn’t sound like the WPF Remoting capability will be released with Longhorn as was originally thought. Perhaps it will arrive later in the form of a Service Pack?

RDP Client Versions and Updates

Of course many of these new features will require a new RDP client. Tad Brockway elaborated on how the new client for Windows XP, SP2 will be made available—via Windows Update!

When we ship Vista, we will make an updated version of our TS Client available via download from Windows Update ... for Windows XP SP2 clients. Similarly, when we ship Longhorn Server we will update the client that is available via Windows Update ... for Windows XP SP2 and Vista clients. This approach will result in supported Windows clients to get access to the new features in Longhorn Server. Current plan is for the Vista SP1 OS to include the version of the TS Client that we ship with Longhorn Server, automatically, so no download will be required for Vista SP1 clients.

TS Gateway Single Sign On update.

The upcoming arrival of Microsoft’s TS Gateway (TSG) product, similar to Citrix’s CSG product, is no surprise. The chat, however, revealed some additional information about the product which is worth noting. For example, the question was asked if a TSG server can exist outside of a domain. Alex explains that,

The TSG can be standalone if needed - but this means you would need local accounts on the TSG. The other alternative is to put the TSG in the internal network and use an SSL terminator in the DMZ instead.

The drawback of having a TSG standalone server is that local credentials would be necessary and Single Sign On (SSO) would not be possible without a 3rd party tool. So what's the deal with SSO? The question was posed whether SSO would be possible between TSWA, TSG, and the TS Server? Tad fielded this question.

In Longhorn Server, we implemented a Network Authentication feature so that your local credentials that you provided at the login screen are automatically forwarded (securely of course) to the Terminal Server. This feature effectively enables SSO from the TS client to the TS server. We do not have a true integrated SSO solution that crosses TS Web Access, TS Gateway, and the Terminal Server. However, we do a pretty good job of supporting credential caching and if it is allowed via your admin would enable an 'SSO experience' for many scenarios. It isn't something we would refer to as SSO, of course.

Another cool piece of information shared a couple of times throughout the chat was that the TS Gateway would work connecting to Windows 2000 and 2003 Server in addition to Vista and Windows XP clients. The ability to connect to desktops and not just servers could be profound with respects to VDI!

In summary, there is a lot of added functionality in Longhorn Server to look forward to. A big thank you is extended to this panel of experts who took time to chat with us!

Additional Resources

  • A great document on the features included with Longhorn Server is available from Microsoft here.
  • Some great Step-by-Step guides to installing and configuring Longhorn, Remote Programs, and the TS Gateway are available for download here.

Chat with Microsoft Terminal Server Product Group.pdf

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Thanks for the summary Brian. You would think that they would have allowed a non domain member TS gateway to authenticate to an ADAM server (which is a domain member) in the DMZ (ADAM would proxy auth to AD).
Strange - it seems like such an obvious addition..?
Good question Andrew. I'll pose to the TS team.
One clarification though.. I didn't write this summary! This is Katie's write-up.
Oops - sorry Katie! Actually I'm now thinking it was a dumb question, if they had the ability to LDAP auth from ADAM then they could do it directly to AD anyway from a non domain member (it's just that many people may prefer to use ADAM in the DMZ as a security measure).
Ho hum, suck it and see I guess...
...there's a bunch of products out there giving clients the ability to connect to a Temrinal-Server via HTTP/HTTPS,

e.g. take a look at