Terminal Services Team Blog

Improving TS Gateway availability using NLB

termserv — Tue, 24 Mar 2009 18:35:00 GMT

TS Gateway is a Windows Server 2008 role which provides secure access to corporate desktops and applications for Internet users. Mobile workforces rely heavily on TS Gateway for remote access needs. To ensure 100% availability there are three methods we recommend which can help achieve this goal for TS Gateway:

Load balancing device (HW implementation): A third-party load balancer like F5 Networks BIG-IP, as one example, can be used to load-balance SSL traffic to TS Gateway servers.

SW load balancing (Ex: Microsoft NLB): This is the low cost and optimal solution for load balancing the TS Gateway traffic.

DNS Round Robin (DNSRR): DNS round robin can be used to balance the load on TS Gateway servers. One disadvantage with DNSRR is that it cannot act as a fail-over cluster. Therefore, if one server fails, clients might continue to attempt connection to the failed server.

In this article, we will focus on configuring TS Gateway high availability mode using NLB.

About Microsoft NLB:

The Network Load Balancing (NLB) role is available in Windows Server 2008. Every TS Gateway server member in the farm must install and configure NLB to form a fail-over load balancing server cluster. NLB distributes traffic between different TS Gateway server farm members. When a server in the cluster fails, NLB automatically removes the failed server from the cluster. The NLB cluster has a virtual IP address which is used by the clients to connect to the TS Gateway farm. Figure 1 below illustrates load-balancing TS Gateway using NLB. To further understand the Microsoft NLB deployment, click the following link: http://technet.microsoft.com/en-us/library/cc754833.aspx.

Figure 1. TS Gateway load balancing

Configuring TS Gateway for a farm scenario:

A TS client establishes an RPC/HTTPS connection to TS Gateway. Every RPC/HTTPS connection internally consists of two SSL channels to TS Gateway representing RPC_IN_DATA/RPC_OUT_DATA channels. In a farm environment, a situation could occur where the RPC_IN_DATA/RPC_OUT_DATA channels end up on two different TS Gateway servers. Normally to address this problem NLB requires IP affinity. However TS Gateway if configured as a farm ensures that the RPC_IN_DATA and RPC_OUT_DATA channels are routed to the same TS Gateway server. See Recommendations about NLB parameters for TS Gateway farm scenario to know more information on different scenarios, IP affinity, and NLB.

To configure a TS Gateway farm :

1. Launch “TS Gateway Manager” from Start->Administrative Tools -> Terminal Services.

2. In the right pane click on Properties, go to Server Farm tab and enter FQDN name of all the servers which will be members of the farm, including local host.

3. Repeat the above steps on each TS Gateway server in the farm.

Setting up Microsoft NLB for TS Gateway farm:

1. Install the Network Load Balancing feature using Server Manager on all the TS Gateway servers in the farm. To install the NLB feature:

a. Open Server Manager, select Features in the left pane, right-click Features, click Add Features, and select Network Load Balancing in the available features. Click Next, and then click Install.

b. Open an elevated command prompt and run the command “servermanagercmd –install nlb”

2. NLB cluster can be configured using NLB manager. Launch NLB manager from Start-> Administrative Tools.

3. Right-click Network Load Balancing Clusters, and then click New Cluster

4. In Host, enter the name of the host, and then click Connect.

5. Select the network interface that you want to use with the cluster and click Next. The interface hosts the cluster virtual IP address and receives the client traffic to load balance. (Note: NLB does not support DHCP, so here you will see a warning message about DHCP. Click OK. )

6. In the Host Parameters page, select a Priority (Unique host identifier). The cluster node with the lowest priority handles the traffic that is not covered by port rules. If there is a single network adapter which is used both for communication between cluster nodes and external network traffic, then the dedicated IP address parameter is needed. The dedicated IP address is used for the communication between the cluster nodes (Ex: By TS Gateway farm services). This address should be a static IP address. Make sure the network adapter is configured with this address.

7. To specify the dedicated IP address, click Add and enter the IP address and subnet mask. Keep the remaining settings in the Host Parameters page as default.

8. Click Next to see the Cluster IP Addresses page. Click Add and enter the IP address for the cluster. This is the IP address which is used by the clients to connect to the TS Gateway farm.

9. Click Next to see the Cluster Parameters screen. Enter the public DNS name of the TS Gateway farm as Full Internet Name ( Ex: TSGatewayFarm.contoso.com )

10. Set Cluster operation mode to either unicast or multicast. Recommendations about the cluster operation mode are discussed at the end of this post.

11. Click Next to see the Port Rules page.

12. Click Edit to change the default port rules. Specify the port range as 443 to 443 if TS Gateway is an SSL end point. If you are using HTTPS-HTTP bridging with ISA in front, specify 80 to 80 as the port range. Only the incoming traffic to the range of ports specified in the port rules is load balanced.

13. In Protocols specify TCP.

14. In Filtering mode select Multiple host, which specifies that multiple nodes in the cluster will handle the network traffic for the port rule.

15. Set the Affinity to Single. Recommendations about the IP Affinity setting are discussed at the end of this post.

16. Click Finish to create the cluster.

17. To add more TS Gateway servers to the cluster, right-click the new cluster and then click Add Host to Cluster. Configure the host parameters (including host priority and dedicated IP addresses) for the additional hosts by following the same instructions that you used to configure the initial host. All the cluster parameters remain the same for the new hosts.

Recommendations about NLB parameters for TS Gateway farm scenario:

Cluster operation mode (multicast / unicast): If the gateway servers have multiple network adapters, use unicast cluster operation mode. It is a requirement that the TS Gateway farm can communicate between gateway servers. So if you have only a single NIC on gateway servers, then multicast should be used to enable communication between gateway servers in the cluster.

IP Affinity: In most cases, especially when clients originate from many different locations on the internet, like their homes, set the IP affinity to Single. There is one scenario where the IP affinity must be set to None: if many of the TS Gateway clients are behind NAT devices causing all connections to end up with the same IP and hence the same TS Gateway server, then IP affinity set to Single on NLB will load one server more than another (for example, all remote workers in a branch behind a NAT with a single external IP). In this scenario IP affinity should be set to None.

It is recommended to configure TS Gateway for a farm scenario, no matter what affinity is used. This allows users to connect in the situation where the 2 SSL connections (RPC_IN_DATA, RPC_OUT_DATA channels) originate from different client IP addresses. For example, suppose a client is trying to connect from within an organization having two proxies to the Internet (or a proxy having two Internet IP addresses) which are used randomly. In this scenario, If TS Gateway farm is not configured then the connection might fail for any NLB IP Affinity setting because SSL connections (RPC_IN_DATA, RPC_OUT_DATA) from the client may go to different TS Gateway servers.

Useful links:

1. To know how MSIT used TS Gateway as a scalable remote access solution, see http://technet.microsoft.com/en-us/library/cc304366.aspx

2. NLB FAQ: http://technet.microsoft.com/en-us/library/cc758834.aspx

3. TS Gateway step-by-step guide:

http://technet.microsoft.com/en-us/library/cc771530.aspx

Top 10 RDP Protocol Misconceptions – Part 2

termserv — Fri, 13 Mar 2009 04:36:58 GMT

Hi,

Nadim here again. Today we’re wrapping up our Top 10 list of RDP Misconceptions. So without further ado…

1) Myth: RDP is insecure; there is no encryption

To be clear, this is totally false! RDP has always supported strong encryption and is by default encrypted!

What has changed over the releases is the type of encryption we offer. The very first versions of RDP back in the Windows 2000 era had encryption that was based on SSL.

As early as Windows 2003 SP1 RDP we decided to introduce full-blown standards-based encryption (i.e. the same SSL as your browser uses to connect to your bank). SP1 did this by introducing standard SSL-encryption as an option.

Current versions of RDP have even stronger encryption and server authentication options out of the box. This is because they are built on top of a security mechanism in Windows called CredSSP which uses Kerberos or TLS (aka SSL) for authentication – when you use those settings RDP is using the same or stronger encryption that your browser uses when communicating with your bank.

2) Myth: RDP performance hasn’t changed much over the releases

False! We’re constantly working to improve RDP performance as well as adding a lot of great functionality to RDP in terms of features.

Every release since Windows 2000 has seen improved perf, i.e. there is a real benefit to upgrading to the latest client and server (e.g. RDP 6.1).

Here’s just one example of the bandwidth difference for a common scenario across several releases of RDP. We essentially have in these scenarios gains of between 8% to 45% bandwidth improvement from switching to the latest protocol. See the RDP Performance Whitepaper for more details on this data.

Going forward - We’re hard at work to continue that trend and bring even better innovations and improved remote experiences – see Asael’s post on some of the future upcoming improvements.

3) Myth: RDP is only used in Remote Desktop Services (formerly TS)

RDP is actually used under the hood in pretty much every Microsoft product that benefits from desktop or application remoting.

Just some examples of products or features you may not have known were built on top of RDP for their remoting needs:

· Remote Assistance

· Windows Media Center Extenders use RDP internally (including Xbox360)

· Windows Live Mesh

· Hyper-V Virtual Machine console

· Office Communications Server 2007 R2

· System Center Configuration Manager (SCCM)

If you’re interesting in seeing how RDP might be able to fit within your application, see the next point...

4) Myth: I can’t customize or program extensions to RDP

There are actually several useful ways to extend/or customize RDP:

· Programming the RDP Client: Host the RDP ActiveX control in your web page or application.

The Remote Desktop client in Windows is a great example of an application that hosts the RDP ActiveX control. This control is fully documented in MSDN. It’s possible for 3^rd party software developers to host this control in an app or a web page to provide desktop remoting as part of your larger app.

· Programming the RDP Server side: Use the Windows Desktop Sharing API

This blog post by Seenu has a lot of good detail and examples on how you can use our Windows Desktop Sharing API to write custom collaboration or desktop sharing applications, these APIs are all built on the same core RDP protocol that powers Windows Remote Desktop.

· Write a dynamic virtual channel extension to RDP

Probably the most powerful way to extend RDP is to actually write a virtual channel plug-in extension to RDP. This allows you to extend the protocol with your own bi-directional channel that can communicate from client to server. The possibilities are limitless but some examples include supporting new devices over RDP. We have a nice blog post with an overview of the dynamic virtual channel API or the docs are in MSDN.

5) Myth: The RDP protocol is not publicly documented

If you’re curious to learn more about very low-level technical details of RDP, we have thousands of pages of detailed specifications up on MSDN. For example, you can see the documents for the core protocol sequence and basic graphics here.

I hope this list was useful, if you’ve got any questions or want to provide us with feedback or suggestions for what you’d like to see in RDP we’d love to hear it!

Thank you!

Remote Desktop Services at the 2009 MVP Summit

termserv — Wed, 11 Mar 2009 00:17:00 GMT

Last week, Microsoft hosted the annual MVP Summit in Seattle and Redmond. The term MVP stands for Most Valuable Professionals. The Microsoft MVP Program is a worldwide award and recognition program that strives to recognize amazing individuals in technical communities around the world – these are individuals who are thought leaders and community leaders in different technologies. In fact, many of you have probably heard of many of our RDS MVPS through their individual blogs or their responses on RDS newsgroups and web forums.

The Remote Desktop Services feature area has 26 MVPs from about 10 countries. This year the RDS team was very happy to have many of the MVPs join us on the Microsoft campus in Redmond for some deep discussions on the current state and future directions of Remote Desktop Services.

We want to thank the RDS MVPs who were able to attend the Summit this year, as well as the rest of our RDS MVPs for their commitment to the RDS community and toward helping Microsoft build a better product: Douglas A. Brown, Shawn Bass, Rich Crusco, Alexander Danilychev, Laurent Falguière, Steve Greenberg, Gustavo Gurmandi, Bisheng Hu, Dong Jo Kim, Thomas Koetzing, Brian Madden, Vera Noest, Seung Heun Noh, Ron Oglesby, Andre Oliveira, Eric Perromat, Gus Pinto, Jeff Pitsch, Claudio Rodrigues, Michel Roth, Patrick C. Rouse, Greg Shields, Joe Shonk, Bernhard Tritsch, Wilco Van Bragt, and Alex Yushchenko.

Here are some of the videos and blog posts from our MVPs covering their experience at the 2009 MVP Summit

Brian Maddens videos (including demos from the RDS Product Group) covering RDS and RDP7 . Check back here in this Thursday for some more demos from the RDS product group.

Steve Greenbergs video highlights of the MVP Summit 2009 and RDS

Joe Shonks experience at the MVP Summit and RDS sessions

Greg Shields experience at the MVP Summit and what he learnt about VDI

Benny Tritschs thoughts on the RDS sessions at the MVP Summit

For those of you who already have access to the Win7 Beta, you can also learn out more about Win7/WS08 R2 and RDS/RDP using these resources:

What's New in Remote Desktop Services in Windows Server 2008 R2 Beta

RemoteApp and Desktop Connection Step-by-Step Guide for WS08 R2 Beta

RDS Application Compatibility Analyzer

Migrating a Windows Server 2003 TS License Server

termserv — Fri, 06 Mar 2009 19:38:37 GMT

This article is designed to help those who want to migrate their Windows Server 2003 TS License Server from one machine to another. We recommend that you read through the instructions once before beginning the migration.

License Server migration is an added feature in Windows Server 2008 R2. In Windows Server 2008 R2, when you right-click on the server name you will see the ‘Manage RDS CALs’ option. After selecting this, you will see the ‘Manage RDS CALs Wizard’ to guide you through the migration process. But to migrate Windows Server 2008 license server, you need to follow the same steps as mentioned in the post.

The migration of your license server requires three stages. First, you must activate the new license server. Next, you need to deactivate the old server. Lastly, you need to move all the licenses from the old server to the new server. To do this, you will need to contact Microsoft Clearinghouse over the telephone. You should to be prepared with the paperwork for the original TS licenses, as this data needs to be provided to clearinghouse personnel. If the original paperwork is lost, then you need to contact your Microsoft TAM (Technical Account Manager) to obtain copies.

To migrate your license server:

Step 1: Activate the new license server:

Set up the VM guest as a Win2003 TS license server.
Open the TS License Manager tool (licmgr.exe)
Activate the server by right-clicking on the server name under the ‘All servers’ node in the left pane and selecting ‘Activate Server’. The Activate Server Wizard will open.
Click Next. Select ‘Telephone’ as your connection method and click Next.
On the ‘Country or Region Selection’ page, select your appropriate country and region.
The next page will provide you with the License Server ID and the Microsoft Clearinghouse telephone number to call. Write them on a piece of paper but don’t make the call yet. You may want to keep the wizard open.

Step 2: De-activate the old license server:

Open the TS License Manager tool on your old license server.
Change the connection method to telephone by right-clicking the server name under the ‘All servers’ node in the left pane, selecting ‘Properties,’ and setting the connection method to ‘Telephone’.
Again right-click the server name under the ‘All servers’ node in the left pane, select ‘Advanced’ and then select ‘Deactivate Server.’ The License Server Deactivation Wizard will open. Click ‘Next’.
On the ‘License Server Deactivation’ page, you will be provided with the same clearinghouse phone number and the License Server ID of your old server. Make a note of this License Server ID as you need to provide this to Microsoft Clearinghouse.
Call Microsoft Clearinghouse at the number you have noted and give them the product ID of the new license server which you want to activate and of the old license server which you want to deactivate. Once you have given them this information, Microsoft Clearinghouse will provide you with the confirmation code. Enter this code into the License Server Deactivation Wizard when prompted.

Step 3: Move each of the license key packs one by one, from the older LS to the new one:

On the same call with the clearinghouse, inform them that you also want to migrate the licenses.
Open the License Install Wizard on the new license server.
Provide the following information to the clearinghouse which they will use to generate the new License Key Pack ID:
1. The license server ID of the old license server
2. Paper work for the original TS licenses
Enter the new license key pack ID in the Install License Wizard and complete the License Installation on the new license server.
Repeat the same process for migration of all license key packs.

Top 10 RDP Protocol Misconceptions – Part 1

termserv — Wed, 04 Mar 2009 01:36:41 GMT

Hi,

My name is Nadim Abdo and I’m the development manager responsible for the Remote Desktop Protocol (RDP).

Since we first shipped RDP in 1998 with Windows NT Terminal Services Edition we’ve gotten lot of very useful feedback on RDP (please keep it coming!). But we’ve also heard a lot of ‘interesting’ myths and misconceptions about RDP and its performance. So I thought why not try to bust some of those myths.

This post will at times get technical for those inclined to those details but I’ll also try to share some useful tidbits that end-users can apply to get an even better RDP experience.

Top 10 RDP Protocol Misconceptions (Part 1 of 2):

1) Myth: RDP is pretty slow because it has to scrape the screen and can only send giant bitmaps

This is a common misconception. While many alternative protocols are principally screen scrapers, RDP uses sophisticated techniques to get much better performance than can be obtained with a simple screen scraping approach.

To drill into this it helps to first talk a little about what screen scraping really means (i.e. what RDP does not do today) and why it can be slow:
In a screen scraping protocol the server side has to ‘poll’ screen contents frequently to see if anything has changed. Screen scraping polling involves frequent and costly memory ‘scrapes’ of screen content and then scanning through a lot of memory (a typical 1600x1200 by 32bpp screen is about 7MB of data) to see what parts may have changed. This burns up a lot of CPU cycles and leaves the protocol with few options but to send large resulting bitmaps down to the client.

So what does RDP do different today and why is it faster?

RDP uses presentation virtualization to enable a much better end-user experience, scalability and bandwidth utilization. RDP plugs into the Windows graphics system the same way a real display driver does, except that, instead of being a driver for a physical video card, RDP is a virtual display driver. Instead of sending drawing operations to a physical hardware GPU, RDP makes intelligent decisions about how to encode those commands into the RDP wire format. This can range from encoding bitmaps to, in many cases, encoding much smaller display commands such as “Draw line from point 1 to point 2” or “Render this text at this location.”

To illustrate some of the benefits on CPU load, terminal servers today can scale to many hundreds of users. In some of our scalability tests we see that even with hundreds of users connecting to one server running knowledge worker apps (e.g. Word, Outlook, Excel) the total CPU load consumed by RDP to encode and transmit the graphics is only a few percent of the whole system CPU load!

With this approach RDP avoids the costs of screen scraping and has a lot more flexibility in encoding the display as either bitmaps or a stream of commands to get the best possible performance.

2) Myth: RDP uses a lot of bandwidth

In many common and important scenarios such as knowledge worker applications and line of business app centralization RDP’s bandwidth usage is very low (on the order of Kbps per user depending on the app and scenario).

This is certainly much lower than many of the screen scraping approaches can hope to achieve (see point #1 above). More importantly it’s low enough that it provides a good experience for many users sharing the same network and datacenter infrastructure even when over a slow network.

So why has there been a perception that RDP uses a lot of bandwidth?

This is a good question and the answer probably lies in the fact that RDP does not use a constant amount of bandwidth; it actually tries to reduce bandwidth usage to 0 when nothing is changing on the screen. Bandwidth consumption only goes up in proportion to what is changing on screen. For instance, if you just run a line of business app with basic graphics and not much animation you may end up sending just a few Kbps of bandwidth down the wire. Of course if you start running animation-heavy applications or graphics your bandwidth usage will go up to support that scenario.

So let’s illustrate some sample bandwidth usages for RDP6.1 in common scenarios (data is from the RDP Performance Whitepaper).

Your mileage will vary depending on your application and network conditions, so it’s important to actually measure empirically for your scenario but the whitepaper gives useful general trends.

3) Myth: I can’t get the same rich experience I get locally when working over RDP

This is also a misconception. RDP provides a scalable remoting experience. By default it cuts down on rich effects in the desktop and application experience in order to preserve bandwidth and save on server load (e.g. CPU, memory). However, if you want the highest end user experience it is possible to turn on many rich effects and display enhancements such as:

· ClearType

· Wallpaper

· The Aero theme with full glass and 3D effects (when connecting to Vista with RDP 6.1)

· 32-bit per pixel color

The key to enabling many of these effects is to run the Remote Desktop client, click Options, and then click the Experience tab. Here you can select and enable many high-end features. Note that in some cases your admin might have controlled access to these features with server-side group policies.

In many cases you can get a great end user experience with good parity to the local case.

We’re also constantly working to ‘close the gap’ between the local and remote experience and so we’re looking to improve the remote experience even more in future versions.

4) Myth: RDP can’t be tuned to get better performance

This is again a misconception. RDP has a set of defaults that tries to provide the best balance between bandwidth usage, the remote user experience, and server scalability. However, you can override many settings if you want to manually tune for a specific scenario and in some cases get very significant boosts in performance.

TIP: One of my favorite such settings is the ability to set policy on the server to optimize RDP compression. This can give you a boost of as much as 60% bandwidth improvement over previous versions of RDP. The tradeoff here is that you’d be consuming more server resources (such as memory and possibly CPU) to achieve that bandwidth reduction.

The GP to control this is :

Administrative Templates\Windows Components\Terminal Services\Terminal Server\Remote Session Environment\“Set compression algorithm for RDP data”

There is more information on tuning the bulk compressor as well as other RDP-tunable parameters such as cache sizes in the RDP Performance Whitepaper.

5) Myth: Using lower color depths -- e.g. 8bpp -- gives the best end user experience

This is a common misconception and was historically true, but not anymore!

The first version of RDP only supported 8bpp color. However, ever since Windows XP, RDP has supported up to 32bpp color.

The reason for this is that more and more apps have come to expect 32bpp mode as the default. Even the Windows Aero experience requires it.

Rather than deny this trend and create a difference between the local and remote experiences, we put a lot of effort into optimizing the 32bpp case to bring down its cost. This allows the user to have the flexibility to pick what is best for their scenario without necessarily having to incur a much bigger bandwidth cost.

In general I’d recommend attempting to run your scenario at 32bpp and measuring the resulting bandwidth to see if it’s acceptable for your scenario. It will usually give the best visual experience and in several cases will consume only a small percentage more data than 16bpp.

That’s it for part 1. I hope this list has been useful, come back soon for part II of the Top 10 RDP Misconceptions list.

More details about Calista Technologies

termserv — Wed, 11 Feb 2009 01:14:00 GMT

It has been a year since Microsoft acquired Calista Technologies, a pioneering virtualization technologies company that I co-founded. I thought that it would be timely to provide some more details about Calista’s technologies and how they differ from traditional Windows desktop remoting.

The Calista acquisition has provided Microsoft with several independent, but interoperable and important technologies that significantly enhance the end user experience and will be incorporated into future versions of Microsoft’s Remote Desktop Protocol (RDP).

Host side rendering and “smart capture”

Before Calista, RDP remoted graphics primitives (the graphics drawing commands, such as “draw a line from screen location A to screen location B”) from the host, over the network, to the client. Those primitives where then rendered (drawn – converted from primitives to actual pixels on the screen), on the client device by the client’s software and hardware. Calista adds innovative and important host side rendering (with select primitive remoting – so as to optimize for certain client and network capabilities / bandwidth / application behavior / etc.) Thus, with Calista technology, rendering is done primarily on the host, and a “smart capture” mechanism is used to monitor which parts of the screen have changed and need to be forwarded to the client. This approach significantly increases the range of client device hardware/software combinations for which the full Windows desktop experience can be enabled. What more, this technology is especially well suited for ultra-lightweight thin clients (which have minimal hardware and software). Conceptually, while RDP before Calista was based on primitives remoting, Calista is based on “image” remoting.

Virtual GPU

For a given VDI host to be able to support many users and target the full range of possible client devices, each interacting with rich content, rendering needs to be performed by the GPU on the server. Current technologies do not allow a GPU to be shared (virtualized) by multiple VMs. Some approaches try to overcome this problem by using CPU rendering (which is less efficient, cannot handle rich 3D graphics, and uses CPU cycles that would otherwise be available to the application workload), or by using a GPU for every VM (very expensive and not scalable). Calista has pioneered the technology to share (virtualize) a single GPU between multiple VMs. This GPU virtualization technology has major implications for centralized computing scenarios like VDI and Terminal Services as well as other VM applications.

Compression

Host side rendering has many advantages over primitive remoting – most importantly desktop like performance for the end user, especially when the client device has limited rendering capabilities. However, a potential trade-off is that host side rendering may require more bandwidth (which can limit network scalability). To overcome this problem Calista uses a number of techniques (rich media redirection, hints, select primitive remoting, advanced caching, etc.).

Nevertheless, in many cases large bitmaps need to be sent across the network. For those cases, Calista developed an advanced compression scheme (CODEC) specifically designed to remote the Windows desktop (optimized for low latency, high-frequency data, etc.). While this CODEC can run on the CPU, large parts of it can also run on the GPU (providing better performance and utilizing the GPU’s untapped power). Furthermore, when even higher scalability is required on the server and for ultra-lightweight thin clients (without a powerful GPU/CPU), Calista has created a reference ASIC implementation of this CODEC so that hardware partners can develop solutions for such cases.

In summary, the combination of Microsoft’s proven primitive-remoting approach with the innovations that the Calista acquisition adds in the areas of host-side rendering, provides Microsoft with a comprehensive set of technologies that enables the remoting of a media-rich Windows-desktop with excellent user experience in numerous customer scenarios with varying network, host, and client requirements.

-- Asael Dror, Architect, Remote Desktop Virtualization, Microsoft.
(Previously, Co-Founder and Chief Architect, Calista Technologies.)

The Windows Server 2008 Terminal Services Resource Kit is now available!

termserv — Wed, 04 Feb 2009 19:28:06 GMT

Long before I joined the ~~Terminal Services~~ Remote Desktop Virtualization Team at Microsoft, I was writing/talking/teaching about Terminal Services. I had to quit being an MVP when I joined Microsoft in August of 2007, but the writing bug does not leave you so easily. When Microsoft Press asked me last year if I was interested in authoring the Windows Server 2008 Terminal Services Resource Kit, I couldn’t say no. (Thankfully, I had a great coauthor in mind: Kristin Griffin, whom you may have seen on microsoft.public.windows.terminal_services. Even more thankfully, she agreed to do it.)

While I sometimes doubted our sanity at having taken this on, it was a great experience. We had four main goals:

· Show how to set up a low-complexity Terminal Services environment with only the tools in the box

· Explain how the features of Terminal Services work, to help readers understand and troubleshoot the features

· Provide hands-on insights from the Terminal Services team and subject matter experts in the field

· Point readers to online resources for more information and free third-party tools

I’ve been part of the Terminal Services community since 1996 and have been impressed many times at how helpful its members are. This is truly a group of people who love what they do and want to share and teach. The process of writing this book demonstrated this yet again. I can’t stress enough how great the team was about pitching in first-hand knowledge, and people in the field—both those at Microsoft and others—were eager to share their experience in how to successfully deploy Terminal Services.

The bottom line is that the Windows Server 2008 Terminal Services Resource Kit is available today. See http://www.microsoft.com/MSPress/books/12716.aspx for more details and ordering information. I’ve already started a TechNet blog for collecting updates at http://blogs.technet.com/tsresourcekit/default.aspx, so be sure to let me know what you’d like to see in the next edition and check in for more content.

Want to see a sample chapter? Go to ftp://ftp.bookpool.com/sc/59/0735625859.pdf to see Chapter 4, on using profiles with Terminal Services.

Managing Remote Desktop Services (aka Terminal Services) using Windows PowerShell

termserv — Wed, 28 Jan 2009 22:25:06 GMT

Hello everyone,

We are pleased to announce that the Beta release of Windows Server 2008 R2 supports managing Remote Desktop Services using PowerShell. You can now configure and manage all RDS role services and components using PowerShell. For example, below are few management tasks that you can now do with PowerShell

View and edit configuration settings of Remote Desktop server
Publish RemoteApp applications
Configure License Server
Create and configure a Remote Desktop server farm
Configure and assign virtual IP addresses to either sessions or applications
Create and manage RDV (VDI) pools
Create and manage Gateway Resource Access & Client Access policies

Of course there is a lot more that you can do with Windows PowerShell. Install the Beta release of Windows Server 2008 R2 and give this feature a try. As always, we are eager to hear what you think, and it is important that you let us know what you like and don’t like as early as possible.

Read further to understand RDS PowerShell in detail.

Remote Desktop Services PowerShell

Once you install the Remote Desktop Services role, a PowerShell provider gets installed. This provider (we’ll call it RDS Provider in the rest of this post) allows you to view and manage the configuration of all role services and components of Remote Desktop Services.

Think of RDS Provider as something similar to the file system provider, registry provider or the IIS Provider. You view, navigate and work with RDS Provider as you would with any of the other providers.

Working with RDS PowerShell

To get started, first install the Remote Desktop Services role and then launch RDS PowerShell.

Step 1: Install Remote Desktop Services role

RDS PowerShell is installed when you install the Remote Desktop Services role. You can install the Remote Desktop Services role using Server Manager.

Step 2: Launch RDS PowerShell

Right click on Start Menu -> All Programs -> Administrative Tools -> Remote Desktop Services -> ‘Remote Desktop Services PowerShell’ and select ‘Run as Administrator’.

Once you click on this link, you’ll see a PowerShell window with the prompt set to RDS drive. There it is – the RDS provider for you.

You’ll notice that once you issue the dir command, you see a view that has the following six columns.

Name: Name of the Container/Setting

Type: Type of Item. There are three possible values for Type – Container (Node), Integer, or String. Container (Node) denotes a Container Item, and Integer and String denote Settings. You can only CD (change directories) to container items. Containers represent a setting group or a logical entity, whereas Settings represent configuration settings. For example, roles such as RDS and Connection Broker, and entities such as Connection Objects and RemoteApps are represented as Containers, while server drain mode is represented as a setting

CurrentValue: Value set to the Item (applicable only to Items of ‘Integer’ or ‘String’ Type)

GP: Indicates whether an Item is controlled by Group Policy or not

PermissibleValues: Possible values that a Setting Item can have

PermissibleOperations: Operations (cmdlets) that can be performed on the Item

Users can select which columns are displayed by using the Format-table cmdlet. For example Get-Item * | format-table -Property Name, CurrentValue displays only Name and CurrentValue columns. Alternatively you can use dir * | ft -Property N*,C* to achieve the same result.

You can also customize the default view. More on this in a later post.

How to get help?

One of the salient features of PowerShell is that it makes it easy to get information and help on a particular aspect. That advantage is retained in RDS Provider as well. There is a property called Description associated with every Item which succinctly describes what a particular setting does.

For example PS RDS:\RDSConfiguration> get-item .\DrainMode| fl displays information about the DrainMode item. You can also change the default view to always display the Description column.

Now, let’s look at few examples.

Example 1: Set RDP encryption level

Step 1: View current encryption level

PS RDS:\RDSConfiguration\Connections\RDP-Tcp\SecuritySettings> dir .\EncryptionLevel | fl

Step 2: Set value of EncryptionLevel item to desired value

PS RDS:\RDSConfiguration\Connections\RDP-Tcp\SecuritySettings> Set-Item .\EncryptionLevel 2

Example 2: Specify License servers that a Remote Desktop server will use

Step 1: View the current list of License Servers in use

PS RDS:\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers> dir

Step2: View the list of license servers registered with the domain controller.

PS RDS:\RDSConfiguration\LicensingSettings\RegisteredLicenseServers> dir

Step 3: Add a License server to SpecifiedLicenseServers list

The simplest way to add a license server is to use new-item and specify the name of the license server that you want to add.

PS RDS:\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers> New-Item -name ls.contoso.com

You can use the below command to add all license servers from the registered license server list to specified license server list.

PS RDS:\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers> dir ..\RegisteredLicenseServers | new-item –force

Example 3: Join a Remote Desktop server to a Session Broker farm

PS RDS:\RDSConfiguration\ConnectionBrokerSettings> Set-Item MemberOfFarm 1 -FarmName testFarm -sessionbroker contoso-sb-test -CurrentRedirectableAddresses 65.52.65.53

Example 4: Add a RemoteApp

PS RDS:\RemoteApps\PublishedApplications> new-item -Name "IExplore" -ApplicationPath "c:\Program Files\Internet Explorer\iexplore.exe" -ApplicationName "Internet Explorer" -ShowInPortal 1

These are just few examples that demonstrate the various possibilities. Almost all configuration tasks related to RD server configuration, RemoteApp, Gateway, License server, and RDV can now be performed using the RDS provider.

Also, the true potential of RDS Provider is realized when writing a script to:

1. Chain multiple configuration activities together

2. Perform configuration on multiple servers

One scenario that best demonstrates the above is the creation of RD server farms. The script shown as a example at the end of this post takes a list of servers and applications as input and creates an RD server farm and creates RemoteApp on all of the servers. Create two text files, one with a list of servers and another with a list of app paths (you can use paths with shell variables such as %windir%) and pass the names of these files as input to this script.

Since this script makes use of PowerShell remoting, before you execute the script make sure you have enabled PowerShell remoting (run Enable-PSRemoting from an elevated PowerShell window to enable remoting.).

Of course this is a very rudimentary script – you can augment it easily with advanced and specific functionality to suit your needs. Also, in our opinion, one of the important advantages of RDS Provider is that you don’t need to be a programmer to be able write such scripts as CreateRDFarm. All you need to know is basic PowerShell scripting.

I hope you are as excited as we are about the possibilities that this opens up. Do let us know what you think. Also, keep watching this space for more scripts that you can put to use.

Appendix: Sample script

#Windows PowerShell script to create a RD Server farm.

if ($args[0] -eq $null -or $args[1] -eq $null -or $args[2] -eq $null ){

Write-Host "Insuffecient parameters.`nUsage: CreateRDFarm.ps1 SessionBroker Farmname <File containing list of RDS servers> <File containing Applications to publish>"

exit

}else{

$sb = $args[0]

$farmname = $args[1]

}

$rdsarr = get-content $args[2]

if ($rdsarr -eq $null){

Write-Host "$args[2] cannot be read or is empty.`nUsage: CreateRDFarm.ps1 SessionBroker Farmname <File containing TS servers> <File containing Applications to publish>"

exit

}

if ($args[3] -eq $null){

Write-Host "No file containing Apps Servers specifed. TS Remote Apps will not be published.`nUsage: CreateFarm.ps1 SessionBroker Farmname <File containing TS servers> <txt file containing Applications to publish>.`n Farm creation will continue" -ForegroundColor yellow

}else{

$apparr = get-content $args[3]

if ($apparr -eq $null){

Write-Host "$args[3] cannot be read or is empty.`nUsage: CreateRDFarm.ps1 SessionBroker Farmname <File containing TS servers> <File containing Applications to publish>"

}

}

# Check whether session broker service is running on the remote machine

$sbservice = Get-Service -ComputerName $sb -Name Tssdis

if( $sbservice.status -ne "Running"){

Write-host "Session Broker service is not running on $sb. Exiting farm creation"

exit

}

if ($rdsarr[0] -eq $null){

Write-Host "No TS Server specified. Atleast one TS Server need to be specified.`nUsage: CreateFarm.ps1 SessionBroker Farmname TS1 TS2 ..."

exit

}

#create a run space to run remote commands on the Session Broker server

$sb_remotesession = New-PSSession -ComputerName $sb

foreach ($rds in $rdsarr){

#add ts server to Session Broker Computers group on SB server

$tst = $rds+"$"

invoke-command $sb_remotesession -ScriptBlock {

net localgroup 'Session Broker Computers' /add $args[0] 2>$null;`

} -ArgumentList $tst

#join each ts server to sb farm.

Write-Host "Joining RD server $rds to $farmname farm" -ForegroundColor magenta

$rds_remotesession = New-PSSession -ComputerName $rds

invoke-command $rds_remotesession -ScriptBlock { `

import-module RemoteDesktopServices ;`

$cipaddr = dir RDS:\RDSConfiguration\ConnectionBrokerSettings\RedirectableAddresses ;`

Set-Item RDS:\RDSConfiguration\ConnectionBrokerSettings\MemberOfFarm 1 -FarmName $args[0] -sessionbroker $args[1] -IPAddressRedirection 0 -CurrentRedirectableAddresses $cipaddr[0].Name ;`

}`

-ArgumentList $farmname,$sb

#create ts remote apps

if ($args[3] -ne $null){

foreach ($app in $apparr){

Write-Host Publishing $app on $rds -ForegroundColor magenta

$ind = $app.LastIndexof("\")

$alias = $app.SubString($ind+1,$app.LastIndexOf(".")-$ind-1)

invoke-command $rds_remotesession -ScriptBlock { `

new-item -Path RDS:\RemoteApps\PublishedApplications -Name $args[0] -ApplicationPath $args[1]`

}`

-ArgumentList $alias,$app

}

}

#close the remote session

Remove-PSSession $rds_remotesession

}

#close the sb runspace

Remove-PSSession $sb_remotesession

Application Compatibility - Survey on TS Application Analyzer

termserv — Fri, 09 Jan 2009 17:26:42 GMT

As part of the development of tools to help IT Administrators find compatibility issues with applications and relevant workarounds on Terminal Services (now Remote Desktop Services), the TS App Analyzer was released in 2008 as a beta effort. To further improve the usability and effectiveness of the tool, we are doing a survey to gather input from the community.

The survey is presently hosted at the TS App Compat Connect website and can be accessed here. Please participate and provide your input to help us make more useful tools for detecting and fixing compatibility issues on Remote Desktop Services.

Why you should sign RDP files and how to script the signing

termserv — Mon, 05 Jan 2009 18:30:00 GMT

RDP file signing is all about security. When you sign RDP files with trusted certificates, your clients can verify that important settings such as which server to connect to haven’t changed since the creation of the RDP file. This helps protect both the user and the server from potential attacks. As an added benefit, because the identity of the publisher can be determined, the client doesn’t need to display warning dialogs stating that the RDP file might not be safe.

So how do you get all this goodness for your users?

You can create signed RDP files using the RemoteApp manager tool, but if you’re looking for a scripted approach this isn’t practical. Luckily, there’s a tool that helps sign RDP files in a script called rdpsign.exe. Unfortunately, it shipped without the ability to write out the Unicode header, but this is easily fixed with vbscript and has been fixed in the next release of Windows.

So how do you sign using rdpsign?

First, create or import the certificate that you are going to be using. You can find more information on how to set up the certificates here: http://technet.microsoft.com/en-us/library/cc754499.aspx.

Second, get the thumbprint by looking at the certificates, clicking the Details tab, and then scrolling to the bottom. Keep in mind that the command line tool assumes there are no spaces in the thumbprint.

Third, sign the file with rdpsign.exe. You can find more information on the command line use of the tool here: http://technet.microsoft.com/en-us/library/cc753982.aspx. This will sign the rdp file, but when you double-click it, the mstsc dialog box will open with incorrect settings. This is because mstsc is trying to read the file as ASCII and it is encoded in Unicode. This bug has been fixed in the next release of Windows 7.

Finally, to fix this encoding issue, you can save the vb-script below and run the script on the file (for example: “fixsignRdp.vbs mySignedFile.rdp”). This script reads the file in as Unicode and writes it back out with the Unicode Byte-Order Mark. Then the RDP file will be signed and ready for anyone to use.

Cheers,
Kevin London

fixsignRdp.vbs

' This script will read in the file as Unicode 
' and then write the file back out as Unicode. 
' The issue is that the file is missing the Unicode header 
' and forcing the re-write adds this to the file. 

Dim argCount:argCount = Wscript.Arguments.Count

If (argCount < 1) Then
                Wscript.Echo "Usage: fixRdpSignature "
                Wscript.Quit 1
End If

path = Wscript.Arguments(0)

Dim fso,rdpFile

Set fso = CreateObject("Scripting.FileSystemObject")
Set rdpFile = fso.OpenTextFile(path,1, 0, -1)
rdpContents = rdpFile.ReadAll()
rdpFile.Close

Set rdpFile = fso.OpenTextFile(path, 2, 0, -1)
rdpFile.Write rdpContents
rdpFile.Close

TS Gateway Certificates Part III: Connection Time Issues related to TS Gateway Certificates

termserv — Thu, 18 Dec 2008 19:38:00 GMT

This is the third and final part of our recent series on configuring certificates on TS Gateway. See also Part I and Part II

Background

TS clients authenticate TS Gateway server using server security certificates (X.509 format). TS Gateway passes the server security certificate to the clients during the SSL handshake process. During the SSL handshake process, the clients might drop connections because the certificate authority is untrusted or the TS Gateway server was unable to produce a valid certificate. In either case, the user will be unable to launch a remote connection using the TS Gateway. The following illustration summarizes certificate-related issues that can occur during connection establishment:

This blog identifies certificate-related connection issues that affect the user’s ability to establish a remote TS connection using the TS Gateway server, and actions that can be taken by end users and administrators to resolve these issues. For information on why TS Gateway needs a certificate and which is the recommended certificate to use on TS Gateway, see Part I: Introduction to TS Gateway Certificates . And for information on how to deploy a certificate on TS Gateway, see Part II: How to deploy a certificate on TS Gateway.

Certificate authority not trusted

Error message - “This computer can’t connect to the remote computer because the certificate authority that generated the Terminal Services Gateway server’s certificate is not valid. Contact your network administrator for assistance. “

Brief description - The TS Gateway certificate authority is not trusted by the client. This issue can most likely arise if the administrator has provisioned the TS Gateway with a self-signed certificate or private certificate authority.

Resolution (user-specific) - Import the TS Gateway certificate to the client machine and install it in the user trusted store.

To install the certificate in the user trusted store:

1. Download the TS Gateway certificate on the client machine.

2. Click Start, click Run, type “mmc.exe” (without the quotation marks), and then click OK.

3. Click File, and then click Add/Remove Snap-In,

4. Click the Certificates snap-in, and then click Add.

5. Click User account, and then click Next.

6. Click Local computer, and then click Finish.

7. Expand Certificates (Local Computer).

8. Right-click Trusted Root Certification Authorities, click All Tasks, and then click Import.

9. Use the Certificate Import Wizard to import the certificate to the user trusted store.

After completing the above actions, try reconnecting using TS Gateway.

Certificate identity mismatch

Error message – “This computer can’t connect to the remote computer because the Terminal Services Gateway server address requested and the certificate subject name do not match. Contact your network administrator for assistance.”

Brief description - The security certificate name presented by the TS Gateway server does not match the TS Gateway name. This can happen either because you used the TS Gateway NetBIOS name to connect or the administrator has incorrectly configured the TS Gateway certificate name with an internal FQDN name. You can verify the discrepancy by reviewing the server certificates as shown here:

For SAN certificates:

Resolution -

1) User action - Try reconnecting using the full FQDN of the TS Gateway server

2) Administrators action - If you are an administrator, verify that the TS Gateway certificate name matches the external FQDN of the TS Gateway server

Invalid TS Gateway certificate -

Error message – “This computer can’t connect to the remote computer because the Terminal Services Gateway server’s certificate is expired or revoked. Contact your network administrator for assistance.”

Brief description – The TS Gateway server certificate’s validity period has expired. For instance, self-signed certificates have a validity period of 6 months. You will see the following screenshot on the TS Gateway server manager snap-in (Administrator only):

Resolution (administrator action) - Create and assign a TS Gateway certificate. Refer to the –“Obtain a certificate for the TS Gateway server” section at the following URL:

http://technet.microsoft.com/en-us/library/cc754252.aspx

No TS Gateway certificates received

Error message – “This computer can’t connect to the remote computer because no certificate was configured to use at the Terminal Services Gateway server. Contact your network administrator for assistance.”

Brief Description – The TS Gateway server certificate was either overwritten or was never configured on the TS Gateway. You will see the following screenshot on the TS Gateway manager snap-in:

The following screenshot represents the scenario in which no TS Gateway certificate exists for selection (Administrator action):

The following screenshot represents the scenario in which a valid TS Gateway certificate exists for selection (Administrator only):

Resolution (administrator action) – Create a certificate and export it to the certificate Personal store of Local Computer. Install the certificate on the TS Gateway. Refer to the –“To map a certificate to the local TS Gateway server” section at the following URL:

http://technet.microsoft.com/en-us/library/cc754252.aspx

Note: If you continue facing issues while trying to bind the TS Gateway certificate – refer to the following KB:

http://support.microsoft.com/kb/959120/

TS Gateway Certificates Part II: How to deploy a certificate on TS Gateway

termserv — Thu, 18 Dec 2008 19:16:42 GMT

For information on why TS Gateway needs a certificate and which is the recommended certificate to use on TS Gateway, see the first post in this series.

To deploy a certificate on TS Gateway server, you must have the server certificate (and private key) contained in a file. You must also have access to the Certificates snap-in and have it set to view computer certificates from the local computer (though this can be done remotely).

This blog will take you through the following steps. Please note that the screenshots in this blog are applicable to Windows Server 2008 only.

Viewing the certificate store on the local computer
Installing the certificate in the personal certificate store of the local computer
Installing the certificate on TS Gateway
A common issue when deploying a certificate on TS Gateway
How to trust the TS Gateway certificate on the clients

Viewing the certificate store on the local computer

To view the Certificates store on the local computer, follow these steps:

1. Click Start, and then click Run.

2. Type "MMC.EXE" (without the quotation marks), and then click OK.

3. Click File menu item in the new MMC you created, and then click Add/Remove Snap-in.

4. Click the Certificates snap-in, and then click Add.

5. Choose the Computer account option and click Next.

6. Select Local Computer on the next screen, and then click Finish.

7. Click OK.

8. You have now added the Certificates snap-in, which will allow you to work with any certificates in your computer's certificate store. You may want to save this MMC for later use.

Now that you have access to the Certificates snap-in, you can import the server certificate into your computer's certificate store by following the steps in the next section.

Installing the certificate in the personal certificate store of the local computer

1. Open the Certificates (Local Computer) snap-in and navigate to Personal, and then Certificates.

Note: Certificates may not be listed. If it is not, that is because there are no certificates installed.

2. Right-click Certificates (or Personal if that option does not exist.)

3. Choose All Tasks, and then click Import.

4. When the wizard starts, click Next. Browse to the PFX file you created containing your server certificate and private key. Click Next.

5. Enter the password you gave the PFX file when you created it. Be sure the Mark the key as exportable option is selected if you want to be able to export the key pair again from this computer. As an added security measure, you may want to leave this option unchecked to ensure that no one can make a backup of your private key.

6. Click Next, and then choose the Certificate Store you want to save the certificate to. You should select Personal because it is a server certificate. If you included the certificates in the certification hierarchy, it will also be added to this store.

7. Click Next. You should see a summary screen showing what the wizard is about to do. If this information is correct, click Finish.

8. You will now see the server certificate you just installed in the list of personal certificates. It will be denoted by the common name of the server (found in the subject section of the certificate).

Now that you have the certificate backup imported into the certificate store, you can use the TS Gateway Manager UI to install the certificate on TS Gateway. The steps for doing this are outlined in the next section.

Installing the certificate on TS Gateway

1. Click Start, click Administrative Tools, click Terminal Services, and then click TS Gateway Manager.

Right-click on the <Machine Name> and select Properties.

2. On the SSL Certificate tab, click Select an existing certificate for SSL encryption (recommended), and then click Browse Certificates.

3. Choose the certificate, and then click Install.

4. Click OK.

A common issue when deploying a certificate on TS Gateway

The most common issue faced by a TS Gateway administrator is that, although he has installed the certificate in the certificate store of the gateway machine, he is not able to view and install the certificate through the TS Gateway snap-in. Possible causes of this are:

1. The certificate does not have the private keys:

If you install the certificate without the private keys in the Personal Certificate Store of the Local Computer, then you can’t view the certificate on the Browse Certificate window of the TS Gateway Manager UI and therefore can’t install it for TS Gateway. This is how a certificate without a private key looks in the Certificate Manager UI. Notice that the first certificate (Issued to: www.contoso.com) does not have a key symbol over its icon.

2. The certificate is not installed in the personal certificate store of the local computer:

If you install the certificate in the personal certificate store of User instead of the personal certificate store of Local Computer, then you can’t view the certificate on the Browse Certificate window on the TS Gateway Manager UI and therefore can’t install it for TS Gateway.

3. The certificate is not a “Server Authentication” certificate:

If the “Intended Purpose” of the certificate is not “Server Authentication” then it won’t appear in the list of available certificates that can be installed on TS Gateway on the Browse Certificate window of the TS Gateway Manager UI. The following example shows how to view the “Intended Purpose.”

The general rule of thumb is that if you have installed the certificate but still don’t see it in the Browse Certificate window of the TS Gateway Manager UI, ensure that you have private keys installed for the certificate and that you have installed the certificate in the personal certificate store of the local computer instead of the User certificate store and that the certificate is intended for “Server Authentication.”

How to trust the TS Gateway certificate on the clients

When you are using a self-signed or private CA certificate on the TS Gateway, the clients won’t trust the TS Gateway certificate by default. In this case, follow the steps outlined in the blog at http://blogs.technet.com/sbs/archive/2008/10/03/receiving-certificate-errors-when-connecting-to-clients-servers-with-ts-gateway-or-remote-web-workplace-on-sbs-2008.aspx.

Introduction to TS Gateway Certificates

termserv — Thu, 04 Dec 2008 21:56:02 GMT

Why does TS Gateway need a certificate?

A TS Gateway certificate is used for authentication and secure communication purposes by the TS clients. To appreciate the purpose of TS Gateway certificates, you will need to understand SSL communication. As illustrated in the following diagram and described in the steps below, a TS client launches an HTTP-SSL connection to the TS Gateway, which begins with a SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques, and then allows the client and server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

Illustration borrowed from Windows Server 2008 Terminal Services Resource Kit, available here.

http://www.microsoft.com/learning/en/us/books/12716.aspx

The steps involved in the SSL handshake are as follows (note that the following steps assume the use of the cipher suites listed in Cipher Suites with RSA Key Exchange: Triple DES, RC4, RC2, DES):

SSL initiation - The client and server exchange cryptographic information such as SSL version number, cipher settings, session data, and other information needed to establish a SSL connection. In this stage, the TS Gateway server sends its X.509 SSL certificate, which is used by the client to authenticate.
Gateway authentication & session key generation – The client validates the server identity using the SSL certificate produced by the TS Gateway. If the TS Gateway server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the TS Gateway server can be authenticated successfully, the client creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 1), and then sends the encrypted pre-master secret to the server. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
Establishing encrypted session - If the server has requested client authentication, the server attempts to authenticate the client. If TS Gateway is configured to authenticate users using smartcard, then client authentication is enforced during the SSL handshake. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection). The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

What type of X.509 certificate can the TS Gateway work with?

X.509 certificates can be self-signed, also known as self-issued, or issued by an X.509 Certification Authority (CA). An X.509 CA is either a third-party public certification authority that issues certificates or a public key infrastructure (PKI) that is deployed within your organization. Unless otherwise noted specifically, this topic refers to both solutions as certification authorities (CA). Third-party public CAs are known as public CAs. For complete specifications about the kind of certificate that can be used on TS Gateway server, please refer to the “Certificates requirements for TS Gateway” section in the TS Gateway step-by-step guide at http://technet.microsoft.com/en-us/library/cc754252.aspx#BKMK_ObtainCertTSGateway .

How do I know which type of X.509 certificate is better?

1. Public CA certificate: Windows and various third-party operating systems include a set of built-in third-party public root CAs. If you trust the certificates issued by these third-party public root CAs, you can verify certificates issued by these CAs.

Trust is automatic if the following conditions are true:

1. Your organization uses the default Windows installation

2. The client software used in your organization also trusts the built-in third-party public root CAs

In this case, additional trust configuration is not required. Therefore, this is the recommended certificate option for TS Gateway.

2. Private CA certificate: A private trusted root CA is a root CA that has been deployed by a private or internal PKI. For example, when your organization has deployed an internal PKI with its own root certificate, you must make additional trust configurations. It is not a best practice to use certificates issued by a private PKI for TS Gateway that support external connections into your organization.

When a private root CA is used, you must update the Windows Trusted Root certificate store on all user devices where certificate authentication is required.

3. Self-signed certificate: The TS Gateway snap-in provides the admin a way to create a self-signed certificate and use it for TS Gateway. A self-signed certificate costs essentially nothing, but it does have the following disadvantage.

Self-signed certificates are not trusted by default on the clients. The admin will have the added responsibility of distributing the certificates to the clients, and the clients need to put the certificates in their “Trusted” Certificate store, which can become a tedious task and is prone to mistakes.

Using self-signed certificates on TS Gateway is not recommended.

Does TS Gateway support wildcard and SAN certificates?

Yes, TS Gateway does support wildcard certificates and Subject Alternative Name (SAN) certificates. The following matrix lists all the different types of supported certificates along with the client support and ISA support cases as well.

Certificates that can be used on TS Gateway:

Certificate type	RDC 6.0 on the client	RDC 6.1 and above on the client	With ISA on the edge
Self-signed	Yes	Yes	Yes
Public CA	Yes	Yes	Yes
Private CA	Yes	Yes	Yes
Wildcard certificates	No	Yes	Yes (ISA 2006 and later)
Certificate with Subject Alternative Name (SAN)	No	Yes	Yes for ISA 2006 SP1 No* for ISA 2004 and 2006

* ISA Server 2004 cannot process certificate SAN attributes at all. The Subject of the certificate installed at the published server must match the published host name used in the Web Publishing rule. ISA Server 2006 is able to use either the Subject or the first SAN entry. What this means for the ISA server admin is that if the ISA server is expecting the certificate to read “contoso.com,” that name should be either of the following:

1. The certificate “Subject” (AKA “common name”)

2. The first entry in the SAN list (ISA Server 2006 only)

References:

RDC: Remote Desktop Client. To check the version of the RDC client, check the information at the link http://technet.microsoft.com/en-us/library/cc736828.aspx

Wildcard certificate: A Wildcard Certificate allows you to secure multiple sub-domains on one domain on the same server using *.domain.com pattern for the common name (CN). For example, while a certificate for contoso.microsoft.com will not work for fabrikam.microsoft.com, a certificate with CN = *.microsoft.com will be valid for both.

Subject Alternative Name (SAN): Subject Alternative Names allow you to specify a list of host names to be protected by a single SSL certificate. A certificate with SAN entries for both contoso.microsoft.com and fabrikam.microsoft.com will work with both servers.

WinHEC 2008: Remote Desktop Services and Calista

termserv — Thu, 20 Nov 2008 00:40:00 GMT

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

Introducing Live Mesh Remote Desktop: Part 1

termserv — Thu, 13 Nov 2008 23:53:08 GMT

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.