Hi, Tad Brockway here. I am a Product Unit Manager on the Windows Server team.  My team is focused on rich media remoting technologies for the new Remote Desktop Services (RDS) in Windows Server which we announced last week at ITForum EMEA in Barcelona. I just returned from WinHEC 2008 in Los Angeles where we showed a demo of some of the new rich media capabilities of RDS as well as a technology preview of what the Calista team has been working on since the company was acquired by Microsoft earlier this year. For those of you that have not heard of Calista before – Calista developed a set of unique GPU virtualization technologies designed to significantly enhance the end-user experience of 3D and multimedia for server-hosted virtual desktops (also often referred to as virtual desktop infrastructure or VDI).

So, before I talk about the demos and presentation at WinHEC, let me quickly summarize why rich media remoting is important to our customers. In many IT environments today, customers are looking to apply virtualization technologies in new ways to increase data security and operational flexibility for desktops and applications by centralizing them in the data center, and enabling users to remotely connect to them via the Remote Desktop Protocol (RDP). The increased adoption of centralized desktops and apps, coupled with the more prevalent use of 3D graphics and rich multimedia content are driving new requirements to enhance the end user experience in remote desktop and application scenarios.

Both RDS in Windows Server 2008 R2 and eventually Calista (when it ships at a yet to be determined point in the future) will help us address these customer needs.

Our first WinHEC demo showed a Remote Desktop Server (preview code) feature slated for the Windows Server 2008 R2 release. We demoed full-motion video running in Windows Media Player over RDP; the same demo setup showed the remoting of Windows Aero and of a DirectX 10.1 application. Finally, the demo included multiple monitors connected to the client, another important new feature of RDS in Windows Server 2008 R2.

The second demo showed two virtual machines along with early Calista bits running on Hyper-V server (preview code), showing a variety of rich graphics applications - DirectX9, Aero Glass, 3D Flip, Adobe Flash, and Silverlight – as part of a Windows 7 desktop over RDP. And finally, as a variation of the second demo, we showed a complete, Calista-enabled hardware-to-hardware solution involving a prototype thin client connected to one of the VMs playing full-motion videos in Windows Media Player.

RDS and Calista demos at the Microsoft Booth at WinHEC 2008

 

The Microsoft booth team, consisting of Marty Amon, Ricardo Baratto, Rommy Channe, Nelly Porter, Jackson Tung and Moshe Zilberstein, supported the RDS demos and the Calista technology preview, which were well received by the attendees.

Both the exhibit and the session breakout that Nelly Porter and I held on Friday afternoon were meant to highlight Microsoft’s commitment to RDP and to a better Windows remoting experience for our customers. Based on the conversations our team had with a number of ISVs and IHVs at WinHEC, our partners seemed excited to hear how we plan to enable, in Windows Server 2008 R2 and beyond, the remoting of a rich user experience with a powerful set of platform capabilities, including support for both primitive and bitmap remoting, support for hardware-assisted solutions, and support for rich (‘thick’) and thin clients.

 

I hope you are as excited as I am about the progress our engineering teams have made and the prospects of these new platform features. Post some questions in the comments section - I'm interested to hear what you think and to answer questions.

 

Tad

The Remote Desktop Protocol is an efficient and feature-rich protocol which we have invested in greatly over the years.   As such, we’ve worked to make RDP available not just in traditional Terminal Server scenarios, but also as a platform for additional products from Microsoft and third party ISV’s.  We are seeing the benefits of this work in very cool products like the Live Mesh Remote Desktop, which we developed with one of our partner teams.  This service was just released to public Beta during Microsoft’s PDC, and in this post we’ll walk you through how it is used.

If you’ve ever wanted to have quick access to one of your computers from anywhere without the hassle of advanced network configuration and VPNs, Live Mesh is for you. Live Mesh uses advanced routing technology to enable seamless connectivity to any of your machines that are connected to the internet, regardless of network topology.

Note that there are a number of other valuable features in Live Mesh, but this post will focus exclusively on Live Remote Desktop. For more information on the additional features of Live Mesh, feel free to stop by their blog at http://blogs.msdn.com/livemesh/. Now, let’s get you up and accessing your devices!

Adding Devices to Your Mesh

It is very simple to get started with Live Mesh. If you don’t already have a Windows Live ID, you can start by creating one from www.passport.net. Once you have an ID to use for your Live Mesh account, you’ll need to visit www.mesh.com and sign in.

After signing in with your Windows Live ID, you will be presented with a first look at your mesh of devices. Initially your list of devices will be empty, so the first step will be to add devices you’d like to access to your Mesh.

To add your device to the mesh, simply click the large Add Device button, select the operating system from the drop down menu, and click Install.

This process will accomplish two things. First, it will download and install the Live Mesh desktop software onto your computer. Installing this software adds all the Live Mesh functionality to your computer, including the components which make it remotely accessible. Second, it will register the computer with the Live Mesh service, to make your computer show up in your list of devices. After downloading and running the installer from the Mesh website, you will see a Live Mesh notification in your system tray.

Next, click Sign in and enter your Live ID to get your computer logged on to your Live Mesh account. By allowing Live Mesh to save your password and sign in automatically, you can ensure that you’ll always have access to your computer, even upon reboot before logging in to your user account.

After you’ve signed in to your Live Mesh account, you’ll be able to create a friendly name to identify the device you’ve added to your mesh.

After clicking “Add Device” you have officially added the device to your Mesh and are ready to access it from anywhere. You should repeat this process on all machines you’d like remote access to. I personally have it on every computer I own =).

Connecting to Your Devices

Now that you have added your desired devices to your mesh, the next step will be to connect to your computers. The Live Mesh desktop software will be installed on any Windows XP or Vista computer you add to your mesh, and can be accessed via the Live Mesh icon in your taskbar’s notification area.

To begin, ensure that the device you’d like to access is turned on and has been signed in to your mesh either manually or by configuring it for automatic sign-in. Note that any machines which are set to automatically sleep for power-saving reasons won’t be reachable while they are asleep. On the computer you’re connecting from, click the Live Mesh icon on the right of your taskbar to bring up your list of devices. You will see that any device in your mesh which is online and logged in to your Live Mesh account will have the “Connect to device” option below its name.

Upon connecting you’ll see the lock screen of the target device. For security reasons, the device you are connecting to is locked upon connection, ensuring that whoever is accessing the device has not only successfully signed in to your Mesh account, but also has full rights to the remote device’s user account. After you log in, you can control your device in the same manner as you would through traditional Remote Desktop.

So far we’ve gone through how sign up for Live Mesh, add your devices to the mesh, and get connected via the Live Mesh software. In Part 2 of this post, I’ll outline how you can use Live Mesh to access your devices from anywhere via the browser, as well as some of the ways that Live Mesh Remote Desktop is unique when compared to the well-known Windows Remote Desktop feature.

The TS team had a great presence at PDC 2008 with a couple of breakout sessions and a booth at the Microsoft Pavilion where we showed off our Windows Vista and Windows Server 2008 features and previewed a few of our new features that are slated for Windows 7 and Windows Server 2008 R2, the next Microsoft client and server releases.

To start off, there was a demonstration of the true multi-monitor support in remote desktop in the day two keynote. While the whole keynote is worth a watch to get a flavor of a number of new features in Windows 7 and other upcoming Microsoft products and technologies, 01:01:33 has the said remote desktop true multi-monitor support demo.

Next was a session on day three by Christa Anderson and Niraj Agarwala - ES22 Extending Terminal Services and Hyper-V VDI in Windows 7

And finally there was a session on day four by Nadim Abdo and Gaurav Daga - ES21 Windows 7 Presentation Virtualization: Graphics Remoting (RDP) Today and Tomorrow

Here is a picture of the TS team attendees at our booth in the Microsoft Pavilion where we demonstrated to attendees a whole array of our Windows Server 2008 and upcoming Windows Server 2008 R2 features.

Terminal Services was renamed to Remote Desktop Services reflecting the expanded role in Windows Server 2008 R2 to provide desktops and applications in the datacenter that users can access anywhere from managed or unmanaged devices.  Remote Desktop Services now includes VDI and session based desktops utilizing existing components such as RemoteApp and Desktop WebAccess or Remote Desktop Gateway as well as the new Remote Desktop Connection Broker.

Read the full report here

With the Windows Server®°2008 and Windows°Vista® operating systems, Remote Desktop Protocol (RDP 6.1) enables new presentation and remote-oriented features such as Desktop Window Manager (DWM) presentation virtualization, 32-bit support, ClearType® display technology, and device redirection, together with important performance-related improvements.

As these features become integrated in the enterprise environment, it is critical to analyze and understand their overall impact on your current network infrastructure and the end-user experience.

The “RDP Performance White Paper” (http://www.microsoft.com/windowsserver2008/en/us/ts-product-home.aspx) describes the performance characteristics of several scenarios that include some of the key features in RDP 6.1. It also includes performance considerations for individual features that can help guide your decisions when modifying your deployment configuration to improve performance or tune it to the specific needs of your end users.

Note: You should not interpret the performance characteristics presented in this document as benchmark measurements that all systems can support. Only empirical testing on the target system can provide an accurate benchmark of your specific scenario.

The ”TS Application Compatibility” Connect program is aimed at providing content and tools to address application compatibility issues and to enable you to readily deploy your applications on TS. Anyone can join the Connect program to learn about ensuring that an application is ready to be hosted on Terminal Services.

A new whitepaper, “Application Readiness for TS,” is now available on the TS Application Compatibility Connect website.

This whitepaper discusses the common application compatibility issues on TS, their common causes, and ways to mitigate these issues by following TS-friendly best practices during application development. This document is targeted at both IT and application design teams.

Details on technical specifics for application developers are discussed in the TS Programming Guidelines (announced in an earlier post).

Application Virtualization 4.5 (App-V) for Terminal Services (formerly SoftGrid) will be available on the Volume Licensing Pricelist and for download on VLSC as of November 1, 2008. App-V 4.5 is the first version available that supports both Windows Server 2003 and Windows Server 2008.

App-V 4.5 for Terminal Services provides new and easier ways to deploy and manage applications on terminal servers -- reducing cost and making your life much easier. By consolidating your applications to fewer terminal servers, you reduce application conflicts, reduce application deployment time by removing the need for regression testing, and best of all, deploy any app to a terminal server without having to reboot, log users off, or use change user /install mode!

Ultimately, you’re connected to resources by IP address, not machine name. When working at home the other day, I found that stale DNS entries can make this connection mechanism yield interesting results when connecting to your desktop PC via TS Gateway. Although the set of circumstances that led to this error is unusual, it’s worth seeing what happened.

Like many people at Microsoft, I use the MSIT deployment of TS Gateway (click here for details of the setup) to get the corporate network from outside the office. I use it regularly and it always “just works”. It’s great—one of my favorite features of Terminal Services.

One day when working from home, I logged into the application and desktop portal, typed in the name of my desktop computer, and connected to my desktop… with one major glitch:

That isn’t good. The bar at the top showed my computer’s name, so why couldn’t I log on? I clicked OK, and was presented with an additional dialog box prompting me for my credentials. This dialog box isn’t normally presented when I’m logging on via TS Gateway.

This is new, I thought, but maybe something’s changed on the back end since two days ago. I typed in my PIN. This got me right back to the original error message.

Things got really weird when I clicked Switch User. Staring at the screen shown below, I wondered, “Why is someone logged into my computer?”

Clicking Other User and attempting to log in using my password got me nowhere either. When I did that the computer complained that I was not a member of the Remote Desktop Users Group and disconnected me when I clicked OK.

Since I was able to reproduce this repeatedly, and could connect to TS RemoteApps via the portal so my credentials were plainly being accepted, I called for help. One person observed that it didn’t look like I was connecting to my desktop at all, even though the display bar showing the remote computer’s name displayed the right name. MSIT looked up the records for my desktop computer, and sure enough, DNS had two IP addresses listed for my computer. One of those IP addresses was no longer associated with my computer, so the connection was being sent to the wrong endpoint.

Now, we were on the right track. Here’s how we determined the problem and resolved it:

1. MSIT ran nslookup –q=any mydesktopname to get the IP addresses listed for my desktop computer and found that my computer had two records. (You don’t have to be an admin to run nslookup.)

2. Once back in the office, I ran ipconfig /all to get my desktop computer’s current IP address. (You don’t have to be an admin to run this, either.)

3. We got in touch with the data center owners to ask them to remove the IP address that wasn’t the one my desktop computer was using.

Why did DNS have two entries for my desktop computer? This can happen when a computer is improperly disconnected from the network, since that will prevent the old entry from being deleted, but the computer gets a new one when it starts on the network. (One cause of stale DNS entries is rebuilding computers while still attached to the network. If doing a planned rebuild, you can avoid this problem by leaving the domain before rebuilding.) The DNS server had a 50-50 chance of sending my incoming request to the right IP address, and lost the gamble. The fix was to delete the old DNS record from the database.

There are two key points here. First, duplicate entries in DNS can cause a routing system based on IP address to fail. The second one is information that helped us troubleshoot this problem:

1. I could connect to TS RemoteApps, but not to my personal desktop. This indicated that the problem did not lie in my credentials.

2. When I clicked Switch User, someone who would never be attached to my desktop was apparently logged in. This indicated either a major security hole or that I was not looking at my own desktop.

3. To support #2, when I presented my credentials I saw an error message telling me that I was not a member of the Remote Desktop Users group, even though I’d previously been able to connect to my desktop computer.

4. Nslookup and ipconfig filled in the missing details.

TS Blog readers may be interested in a Virtualization Road Show that Microsoft is putting on. It’s free, but you must register.

The agenda includes discussion of server virtualization and management, Microsoft’s use of virtualization in data centers, and desktop virtualization. There will also be hands-on labs.

Date

City

October 10, 2008

Anaheim , CA

October 13, 2008

Santa Clara , CA

October 15, 2008

San Francisco , CA

October 21, 2008

Minneapolis , MN

October 24, 2008

Dallas , TX

October 27, 2008

Chicago , IL

October 31, 2008

Boston , MA

November 3, 2008

New York , NY

November 10, 2008

Washington , DC

November 13, 2008

Philadelphia , PA

November 17, 2008

Atlanta , GA

In a previous blog post, Christa gave a high level explanation of the extensibility points we introduced to Session Broker (SB) in Windows Server 2008. In this post, we will dive a bit deeper to see how we can use SB Extensibility to build our own load balancing logic.

As Christa mentioned, when a new incoming connection is received by a terminal server, the terminal server contacts the SB for directions on where to redirect this new user. To answer this question, the SB must go through its load balancing logic. Our implementation of this logic consists of:

1. The SB looking through its database and picking the terminal server with the least number of sessions. (This is a slight simplification as the SB takes some other factors into account, but for now it is safe to ignore them for this discussion.)
2. The SB then returns that information to the terminal server to which the user initially connected.
3. The terminal server uses the returned data to execute the actual redirection.

Since the debut of Windows Server 2008, we’ve received some feedback regarding SB load balancing logic, labeling it too simplistic. While this may or may not be the case, with the extensibility points we’ve provided, you can fully replace the SB load logic with your own to load balance based on what might be important to you in your organization.

To implement your own load balancing logic and make use of these extensibility points, you will have to construct a COM server which implements the IWTSSBPlugin interface. This COM server (which I’ll refer to as an “extensibility plug-in”) will be called by the SB for passive notifications as well as requests to make load balancing decisions.

The IWTSSBPlugin interface has five methods which SB calls at different points. We will temporarily ignore WTSSBX_GetUserExternalSession and revisit it in a later blog post.

Let’s quickly review the four methods and when SB calls them:

· Initialize – called by SB when the SB service starts to allow the plug-in to do its initialization.

· Terminated – called by SB when the SB service shuts down to allow the plug-in to do its termination cleanup.

· WTSSBX_GetMostSuitableServer – called by SB when a load balancing decision needs to be made. We can use this method to override the SB’s default load balancing logic.

· WTSSBX_MachineChangeNotification – called by SB when a change occurs in one of the servers in the farm. We can use this method to get information on new terminal servers that have joined or left the farm.

· WTSSBX_SessionChangeNotification – called by SB when a change occurs in a session on a terminal server that is part of the farm. We can use this method to detect session state changes (such as when a user disconnects from his session).

The order in which these methods are called depends on what is happening in the farm. Let’s first look at the machine notifications:

When a server joins a farm the following notifications are called on the plug-in in the following order:

1. WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_ADDED. This notification also provides the unique Machine ID which SB will use to identify this terminal server in all subsequent calls to the plug-in.
2. WTSSBX_SessionChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_RESYNC. This notification reports the state of the sessions already existing on the terminal server joining the SB.
3. WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_CHANGED. This notifies the plug-in that the terminal server is now part of the farm and is ready for incoming connections.

Similarly, when a server leaves the farm WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_REMOVED.

The session notifications are also quite simple:

• When a user connects to a terminal server in the farm, a WTSSBX_SessionChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_ADDED.
• Similarly, when a user logs off a session WTSSBX_NOTIFICATION_REMOVED is used.
• Session state changes are called through WTSSBX_SessionChangeNotification with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_CHANGED.

These notifications provide the plug-in with enough information to make load balancing decisions.

The actual decisions are communicated to the SB via the WTSSBX_GetMostSuitableServer method. Let’s look back at the original explanation of how the SB load balancing logic is invoked to see where in that process WTSSBX_GetMostSuitableServer is called.

When a new connection comes to a terminal server, the server asks the SB to provide the Machine ID of the terminal server which has an existing session for the user. The SB queries its database and if no such session exists, the SB uses its standard load balancing logic to determine a Machine ID to which the user should be redirected. At this point, instead of returning this ID to the terminal server, the SB calls into the plug-in via the WTSSBX_GetMostSuitableServer method and passes the Machine ID it has just calculated as one of the parameters. The plug-in can then change this parameter to redirect to a different terminal server than the one originally intended.

So we see that by returning a different Machine ID in response to a WTSSBX_GetMostSuitableServer method call, we can override the default SB load balancing logic and provide our own.

In the next blog post, I will provide some design guidelines on how to construct your plug-in as well as an example of a plug-in that does resource-based load balancing.

The location on the virtual desktop where the TS Client initially positions itself can be controlled via the winposstr setting in the RDP file (Default.rdp or any other custom RDP file that you use).

An example winposstr is:

winposstr:s:0,1,1370,92,2500,992

So, let’s break it down and see what each field means:

winposstr:s:0,ShowCmd,Left,Top,Right,Bottom

The first field is always set to zero. Next, the ShowCmd field can be set to one of the following two values:

Value Meaning 1 Displays the TS Client as using the virtual desktop-relative coordinates specified in the Left, Top, Right and Bottom fields. 3

Displays the TS Client as a maximized window.

The Left, Top, Right and Bottom fields are the coordinates which specify where the TS Client window must be positioned on the local desktop when it is not maximized.

Closely related to winposstr is the screen mode id RDP file setting. This field can be set to one of the following two values:

Value Meaning 1 Start the TS Client in “windowed” mode. 2 Start the TS Client in “full-screen” mode.

 

An example screen mode id is:

screen mode id:i:1

If the screen mode id is set to use the full screen, the winposstr value helps to determine which monitor the client will start on by choosing the monitor with the largest area of intersection with the rectangle specified by the Left, Top, Right and Bottom fields.

While most 32-bit and 64-bit applications run “as is” on Windows Terminal Services, some do not perform as expected due to differences in the platform between Vista and Windows 2008 Terminal Services:

1. Multiple users – Issues related to maintaining user isolation for privacy/security.

2. Concurrent access by several users – Issues related to concurrent access/modification of data/resources, etc.

3. Application deployment – Precise deployment in a multi-user scenario is very important since you want to make sure that the application’s user specific data/resources are isolated and system wide data/resources are protected.

4. Remote devices – Running applications remotely requires Windows to handle your client devices and enable them to work with the application that is actually running on the server. This results in a somewhat different experience as compared to local devices.

5. Performance – Using your application over a limited bandwidth connection and running it on a server shared by multiple users mandates careful design for performance on TS.

The TS Programming Guidelines provide information on how to design your application to ensure that it runs smoothly on Terminal Services and provides a rich, seamless, and integrated experience to your end users.

While these guidelines have been written for Windows 2008 Terminal Services, they are also applicable to Windows 2003 Terminal Services. Moreover, these are general good programming guidelines that benefit application design even in non-TS specific scenarios such as Fast User Switching.

Terminal Services is both a collection of features and a platform for the TS team’s independent software vendor (ISV) partners. As a platform, we want to make sure that our components can be easily extended to support our partners’ vision of what Terminal Services can do—and we want to be sure that people know about those extensibility points.

One of the new Terminal Services roles in Windows Server 2008 is the TS Session Broker, responsible for routing incoming connections to the right terminal server. When the TS Session Broker gets an incoming connection, it checks first to see if that user has an existing session on a terminal server in the farm. If they do, then the connection goes to that terminal server. If they don’t, then the Session Broker will redirect to the terminal server with the lowest number of sessions. (The TS Session Broker supports redirection to Windows Server 2003 terminal server sessions, but the Win2K3 terminal servers can’t participate in load balancing.) In another blog entry, we’ve explained how CredSSP can even speed the redirection process to terminal servers.

But what about destinations, such as virtual desktops, blade PCs, or even PCs? While the built-in functionality of the TS Session Broker in WS08 only supports routing connections to terminal server sessions, we’ve created a set of APIs that ISVs can use to create connection brokers for other kinds of devices. Basically, these APIs allow you to lobotomize the TS Session Broker and replace its brain—its brokering mechanism—with a new plug-in. This plug-in can contain a new set of rules that support redirection to other types of destinations. It can also provide different means of deciding the best target for new connections, such as load balancing rules based on server resources or login time.

ISVs can extend the capabilities of TS Session Broker through the IWTSSBPlugin interface. This interface includes several benefits:

· It doesn’t need an agent on the client or terminal server to support connection brokering, so there’s never anything to update.

· Plug-ins using this interface can easily interact with other Terminal Services role services, such as Terminal Services Gateway (TS Gateway) and rely on information from TS Session Broker about session and computer states (available through WMI).

· The plug-ins can manage connections with client or server devices that support RDP 5.2 or later.

The IWTSSBPlugin interface can:

· Return the ID of the server to which TS Session Broker should direct the incoming connection.

· Direct an incoming connection to an external computing resource.

· Notify the plug-in that a change occurred in the server environment.

· Notify the plug-in that a change, such as a logon, logoff, disconnect, or reconnect, occurred in a user session.

You can learn more about the methods for the IWTSSBPlugin interface at http://msdn.microsoft.com/en-us/library/cc644955(VS.85).aspx and Roman Porter will include some code samples in a follow-up blog entry.

Finally, here’s a question to everyone reading this: When it comes to Terminal Services as a platform, what other extensibility points would you find useful?

Since the Windows XP timeframe, the TS Client has had the ability to run in “smart-sized” mode (users of Remote Assistance will be familiar with this mode). Smart-sized mode means that the entire remote desktop is always visible in the client window, with no scrollbars being necessary. In effect, for the same size client window, smart-sizing shows you more graphic data, while a non-smart-sized client window has to use scrollbars and shows much less.

Smart-sized client view of a user’s desktop:

Non-smart-size client view (with scrollbars) of the same desktop:

You cannot enable smart-sizing through the TS Client UI, but you can switch it on using RDP file settings. Add the following line to Default.rdp (or any other custom RDP file that you use):

smart sizing:i:1

The next time you connect, your client view will be smart-sized.