Daniele Tosatto

Feature Overview

The goal of RemoteFX USB redirection is simple: the user should be able to use any device they want, and have it just work. RDP has numerous high-level redirections that allow specific types of devices to be used effectively in a remote session, such as:

• Easy Print, which allows users to print to local printers in remote sessions
• Drive Redirection, which allows users to access the file system on any local drive in a remote session, including USB drives
• Smart Card Redirection, which allows users to authenticate to and in a remote session by using smart cards/e-tokens
• Plug-and-Play Device Redirection, which allows users to access PTP digital cameras, MTP music players, and POS for .NET devices in a remote session, among others
• Input Redirection, which allows the use of keyboards/mice in remote sessions
• Audio Redirection, which allows recording and playback of audio in remote sessions
• Port Redirection, which allows the use of serial and parallel ports in remote sessions

However, there are many devices which are not covered by these redirections, such as scanners, multifunction printers, webcams, and more. RemoteFX USB redirection acts as a catch-all mechanism that redirects these USB devices! Unlike high-level redirections such as drive redirection, RemoteFX USB redirection happens at the port protocol (USB request block or URB) level, and is similar to how one can redirect serial or parallel ports via RDP. This provides some unique advantages, as you’ll see below. However, RemoteFX USB redirection is meant to supplement high-level redirections, not to supplant them. By combining RemoteFX USB redirection with RDP high-level device redirections, you can have the best of both worlds. Here is a table that compares and contrasts the two forms of redirection.

Setting up a Basic Deployment

Now that you’ve seen what RemoteFX USB redirection can do, let’s take a look at how to set up the feature.

Prerequisites

You will need the following:

• A RemoteFX-capable client (Remote Desktop Connection 7.1 or later)
• A virtual machine hosted on a RemoteFX host (Windows 7 SP1 or later)

Enabling RemoteFX USB redirection on the clients

1. In order to redirect USB devices from a given machine, the RemoteFX USB redirection feature must be enabled. In Group Policy, navigate to Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\RemoteFX USB Device Redirection, and edit “Allow RDP redirection of other supported RemoteFX USB devices from this computer.” Enable the policy, and specify whether you wish to allow all users or only admins to redirect devices.
   
2. On the client machines, run “gpupdate /force” (without quotes) from an Administrator command prompt to enable/disable the feature, and then restart the computer for the changes to take effect. The feature will not work until you restart.

Using the feature

1. On the client, open Remote Desktop Connection. If the tabs are not listed, click Options to expand the dialog box.
2. On the Local Resources tab, click More to display the Local devices and resources dialog box. If at least one supported RemoteFX USB device is connected, it should be listed in the device tree under Other supported RemoteFX USB devices.

   Note: The heading “Other supported RemoteFX USB devices” will only appear if the RemoteFX USB redirection feature is enabled on the client (apply the Group Policy setting, run gpupdate, and then restart) and at least one supported RemoteFX USB device is connected and available for redirection.
   

3. After you are connected, the devices that you have selected should appear in the remote virtual desktop.
   

ompanies that are creating an implementation of the Remote Desktop Protocol set can license the Intellectual Property(IP) rights they need from Microsoft by signing the RDP Client License. Products that might need these rights to interact with Windows Remote Desktop Servers (Sessions or VM based) include:

• Non-Windows Thin Client devices
• Non-Windows based client software

To understand if you might need the patent rights associated with the protocols, Microsoft has also published a map of which patents are associated with each protocol.

http://www.microsoft.com/openspecifications/patent-rights/mcpp-licensing/

The copyrighted documentation for the protocols has been available for free on MSDN for over two years:

http://msdn.microsoft.com/en-us/library/cc216517(v=prot.10).aspx

Other Benefits of the RDP Client License

In addition to receiving a license to the patent rights you need, companies that have taken the RDP Client license will also enjoy:

• Free documentation support via community forums
  http://msdn.microsoft.com/en-us/library/cc320426(v=PROT.10).aspx
• Free attendance at protocol plugfest events: these are quarterly meetings where attendees receive presentations about a specific area of protocol technology and have a chance to interact directly with Microsoft engineers.
• Network Monitoring (NetMon) tool, a protocol analyzer that allows you to capture network traffic, view and analyze it.
• Test Suites: Microsoft has begun releasing test suites for different protocols and will continue to roll them out over time.
• Reference Source Code: Microsoft will shortly be making available reference source code for an implementation of RDP 7.1 only to RDP Client licensees. Look for a future blog post for more information.

The Remote Desktop Services Deployment Guide for Windows Server 2008 R2 is now live on the Download Center and on TechNet.  This guide is intended for use by system administrators and system engineers who are responsible for deploying the role services and features for Remote Desktop Services for the Virtual Desktop Infrastructure (VDI) environment. It provides detailed guidance for deploying a Remote Desktop Services design that is preselected by you, an infrastructure specialist, or a system architect in your organization.

The Terminal Services Deployment Guide for Windows Server 2008 is now live on the Download Center and on TechNet.  This guide is intended for use by system administrators and system engineers who are responsible for deploying the role services and features for Terminal Services. It provides detailed guidance for deploying a Terminal Services design that is preselected by you, an infrastructure specialist, or a system architect in your organization.

Microsoft released App-V 4.6 for RDS Whitepaper.

This whitepaper discusses the benefits, configurations and considerations when planning a Microsoft® Windows Server® Remote Desktop Services solution with Microsoft Application Virtualization.

You can download the whitepaper here.

Microsoft is increasing its marketing effort in promoting its VDI platform since a few months now.

Microsoft published a guide to help Deploying Remote Desktop Connection Broker with High Availability.

This guide is intended for IT professionals, and tells how to configure Remote Desktop Connection Broker in a failover cluster. The configuration provides users with access to personal virtual desktops or virtual machines in a virtual desktop pool through RemoteApp and Desktop Connection.

You can find it here.

Microsoft has introduced a new MMC snap-in tool called Remote Desktop Connection Manager in Windows Server 2008 R2 for managing the in-box VDI solution from Microsoft. In this blog, I will explain how you can specify various RDP settings for the virtual desktops published using this tool.

You can specify a different set of RDP settings for each type of virtual desktops (Personal and Pooled) published by this tool.

To modify RDP settings for “Personal Virtual Desktops,” expand the “RD Virtualization Host Servers” node, select “Personal Virtual desktops” and then select “Properties” from actions.

To modify the RDP settings for pooled virtual desktops, select the pool node under “RD Virtualization Host Servers” node and then select “Properties” from actions. This allows you to change the RDP property for the pool that you have selected. If you have more than one pool of virtual desktops, you will have to change RDP settings for each pool by going to their respective nodes.

For most common RDP settings there is a “Common RDP Settings” property tab with dedicated UI controls for each of the setting. The “Custom RDP Settings” tab allows you to specify advanced RDP settings which are not modified very frequently. Given below is an example of how Custom RDP Settings can be used to enable optimal audio/visual experience for virtual desktop users.

Enabling optimal user experience

By default, the virtual desktops published through this tool are tuned for performance. For example, with default RDP settings, users will not be able to see the wallpaper on their virtual desktop. To enable the optimal audio/visual user experience, you can add following RDP settings under the “Custom RDP settings” tab:

With the above settings, RDP connections to virtual machines require higher network bandwidth compared to default settings. Therefore the admin should enable these settings taking into account the available network bandwidth and the desired user experience.

For a complete list of RDP settings for Remote Desktop Services, see the Remote Desktop Services Technical Reference (http://go.microsoft.com/fwlink/?LinkId=139899).

Starting with Windows Server 2003 SP1, it is possible to provide server authentication by issuing a Secure Sockets Layer (SSL) certificate to the Remote Desktop server. This is easy to configure using the “Remote Desktop Session Host Configuration” tool on Server operating systems. Though no such tool is available on Client operating systems such as Windows Vista and Windows 7, it is still possible to provide them with certificates for Remote Desktop connections. There are two possible ways to accomplish this. The first method is using Group Policy and Certificate Templates, and the second one is using a WMI script.

Part I: Using Group Policy and Certificate Templates.

This method allows you to install Remote Desktop certificates on multiple computers in your domain but it requires your domain to have a working public key infrastructure (PKI).

First, you need to create a Remote Desktop certificate template.

Creating Remote Desktop certificate template:

1. On the computer that has your enterprise Certification Authority installed start MMC and open the “Certificate Templates” MMC snap-in.
2. Find the “Computer” template, right-click on it, and then choose “Duplicate Template” from the menu.
3. In the “Duplicate Template” dialog box, choose “Windows Server 2003 Enterprise” template version.
   
4. The “Properties of New Template” dialog box will appear.
5. On the “General” page of this dialog box, set both “Template display name” and “Template name” to “RemoteDesktopComputer”. Note: it is important to use the same string for both properties.
6. On the “Extensions” page, select “Application Policies”, and then click the “Edit…” button.
7. The “Edit Application Policies Extension” dialog box appears.
   
8. Now you can either remove the “Client Authentication” policy leaving the “Server Authentication” policy, or you can use the special “Remote Desktop Authentication” policy. Doing the latter will prevent certificates based on this template from being used for any purpose other than Remote Desktop authentication.
9. To create the “Remote Desktop Authentication” policy, first remove both the “Client Authentication” and “Server Authentication” policies, and then click “Add…”
10. The “Add Application Policy” dialog box appears. In this dialog box click the “New…”
    
11. The “New Application Policy” dialog box appears. In this dialog box, set “Name” to “Remote Desktop Authentication” and “Object Identifier” to “1.3.6.1.4.1.311.54.1.2”, and then click “OK.”
    
12. Select “Remote Desktop Authentication” in the “Add Application Policy” dialog box, and then click “OK.”
13. Now the “Edit Application Policies Extension” dialog box should look like this:
    
14. Click “OK” in this dialog box, and then click “OK” in the “Properties of New Template” dialog box.

The new template is now ready to use.

The next step is to publish the template.

Publishing the “RemoteDesktopComputer” certificate template:

1. On the computer that has your enterprise Certification Authority installed, start the Certification Authority MMC snap-in.
2. Right-click on “Certificate Templates”, then select “New\Certificate Template to Issue” from the menu that appears.
3. The “Enable Certificate Templates” dialog box appears. Select “RemoteDesktopComputer”, and then click “OK.”

Now the “RemoteDesktopComputer” template is published and can be used in certificate requests.

The last step is to configure Group Policy to use certificates based on the “RemoteDesktopComputer” template for Remote Desktop authentication.

Configuring Group Policy:

Note: The following steps create the new policy to apply to all computers in the domain, but it can also be scoped to an Organizational Unit if needed.

1. On the domain controller, start the “Group Policy Management” administrative tool.
2. Right-click the “Default Domain Policy” and click on “Edit…” in the menu that appears. The “Group Policy Management Editor” appears.
3. Navigate to “Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.”
4. Double-click the “Server Authentication Certificate Template” policy.
5. Enable the policy, type “RemoteDesktopComputer” in the “Certificate Template Name” box, and then click “OK.”
   
6. As soon as this policy is propagated to domain computers, every computer that has Remote Desktop connections enabled will automatically request a certificate based on the “RemoteDesktopComputer” template from the Certification Authority server and use it to authenticate to Remote Desktop clients. You can speed up the propagation to a specific computer by running the “gpupdate.exe” command line tool on that computer.

Part II: Using a WMI script.

This method allows you to use a server certificate of your choice with Remote Desktop connections but the certificate needs to be manually installed on the computer first. For example, this method can be used if you bought your certificate from a public certificate authority.

First check that your certificate meets the requirements for Remote Desktop certificates. Certificates that don’t meet these requirements won’t work and will be ignored.

Basic requirements for Remote Desktop certificates:

1. The certificate is installed into computer’s “Personal” certificate store.
2. The certificate has a corresponding private key.
3. The” Enhanced Key Usage” extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). All-purpose certificates can be used as well.

In order for a certificate to be used for Remote Desktop connections you first need to obtain the certificate’s thumbprint.

Getting the certificate’s thumbprint:

1. Double-click on the certificate.
2. Click the “Details” tab.
3. Select the “Thumbprint” entry from the list.
   
4. Copy the thumbprint value into Notepad.
5. Delete all the spaces between the numbers.

Now you have the thumbprint string ready to use. It should look like this: 0e2a9eb75f1afc321790407fa4b130e0e4e223e2

Once you have the thumbprint you can use the following script to cause the certificate to be used for Remote Desktop connections.

WMI script for configuring Remote Desktop certificate:

var strComputer = ".";

var strNamespace = "\\root\\CIMV2\\TerminalServices";

var wbemChangeFlagUpdateOnly = 1;

var wbemAuthenticationLevelPktPrivacy = 6;

var Locator = new ActiveXObject("WbemScripting.SWbemLocator");

Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;

var Service = Locator.ConnectServer (strComputer, strNamespace);

var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");

if (WScript.Arguments.length >= 1 )

{

    TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);

}

else

{

     TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";

}

TSSettings.Put_(wbemChangeFlagUpdateOnly);

In Windows Server® 2008 R2, Microsoft introduced the Remote Desktop Services Provider for Windows PowerShell™. This post gives examples of how you can use this new feature to manage Remote Desktop Licensing (RD Licensing).

This post assumes that you have a basic understanding of Windows PowerShell. As you might already know, Windows PowerShell provides an easy scripting interface for performing administrative tasks. You can write Windows PowerShell scripts to automate the setup deployment per your requirements.

Prerequisites:

· Install the required Remote Desktop Services feature (that is, Remote Desktop Licensing for Example 1 and Remote Desktop Session Host for Example 2).

· Launch the Remote Desktop Services module for Windows PowerShell:

o Click Start -> All Programs -> Administrative Tools -> Remote Desktop Services.

o Right-click Remote Desktop Services module for Windows PowerShell, and then select Run as Administrator.

After you do this, you will see a Windows PowerShell window with the prompt set to the RDS drive.

Following are two examples for configuring a server with Windows PowerShell:

Note: When using Powershell commands, make sure that you execute them from the correct path. First cd to the correct directory before executing the command.

1. On the Remote Desktop license server:

a. Activate the license server using the Automatic Connection method with the following command:

PS RDS:\LicenseServer> Set-Item .\ActivationStatus -Value 1 -ConnectionMethod AUTO -Reason [Reason]

where [Reason] specifies the reason for activation of the license server. It has 6 possible values:

0 – The server was redeployed

1 – The certificate was corrupt

2 – The private key was compromised

3 – The activation key expired

4 – The server was upgraded

5 – The server is being activated for the first time

b. Install the Select License Key Pack by using the following command:

PS RDS:\LicenseServer\LicenseKeyPacks> New-Item -path RDS:\LicenseServer\LicenseKeyPacks -InstallOption INSTALL -ConnectionMethod AUTO -LicenseType AGREEMENT -AGREEMENTTYPE 0 -AGREEMENTNUMBER [AgreementNumber] -PRODUCTVERSION [ProductVersion] -PRODUCTTYPE [ProductType] -LICENSECOUNT [LicenseCount]
where [AgreementNumber] refers to the Agreement Number for the licenses, [ProductVersion] refers to the version of the licenses. It has three possible values:

0 – Windows 2000 Server

1 – Windows Server 2003

2 – Windows Server 2008 or Windows Server 2008 R2

[ProductType] refers to the type of license. It has four possible values:

0 – for Per Device

1 – for Per User

4 – for VDI Standard

5 - for VDI Premium, and

[LicenseCount] refers to the number of licenses that you want to install.

c. Add the license server to the Terminal Server License Servers group on the domain controller by using the following command:

PS RDS:\LicenseServer> Set-Item .\LSinTSLSGroup -Value 1

Note: To run this command, you need to have Enterprise Admin privileges.

d. Query to see if the license server is registered in Service Connection Point (SCP) by using the following command:

PS RDS:\LicenseServer> Get-Item .\SCPRegistrationStatus

This command will show the current value, permissible values, and the permissible operations for the property. If the value of ‘SCPRegistrationStatus’ property is set to 1, it means that the license server is already registered in SCP.

e. Generate the Per User license usage report by using the following command:

PS RDS:\LicenseServer\IssuedLicenses\PerUserLicenseReports> New-Item -Name [NameOfReport] -Scope [Scope]

where [NameOfReport] is the name with which you want to refer to the report, and [Scope] represents the scope of the report. It can have three values:

DOM – Generate a report for the entire domain

ALLTRUSTEDDOM – Generate a report for all trusted domains

OU – Generate a report for the organizational unit (OU)

2. On the Remote Desktop Session Host (RD Session Host) server:

a. Specify the licensing mode on the RD Session Host server using the following command:

PS RDS:\RDSConfiguration\LicensingSettings> Set-Item .\LicensingType -Value [Type]

where, the possible values of [Type] are:

2 – Per Device

4 – Per User

b. In the Specified License Server list, add the license server name by using the following command:

PS RDS:\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers> New-Item -Name [LSName]

where [LSName] refers to the name of the license server.

For more information about licensing and Windows PowerShell, use these commands: cd, dir, and Get-Help.

Recently, Microsoft have started to get more calls related to an issue with the Terminal Services and Remote Desktop Services license server that is caused by the expiration of a root certificate. This blog post will help to easily check if this has happened in your environment and how to address the issue.

How do I know I have this problem?

• Event 17 is getting logged on every license server restart (a restart of the computer or a restart of the Terminal Services Licensing service [termservlicensing]).
• After receiving Event 17, any interaction with the Microsoft Clearinghouse except “reactivation” pops up the error “The RD License Manager encountered an internal error from the license server. Message Number: 0xc0110011,”and then the license server gets deactivated (applies only to license servers connected to the Internet and that have the connection method set to Automatic).

Which license servers are affected by the above issues?

All the following versions of license servers that were activated before February 26, 2010 by using the automatic connection method will be affected by this issue:

• Windows 2000 Server
• Windows Server 2003
• Windows Server 2003 R2
• Windows Server 2008
• Windows Server 2008 R2

Why is this happening?

When a license server is activated by using the automatic method, the Microsoft Clearinghouse provides the server with a digital certificate chain that validates server ownership and identity. On February 26, 2010, a certificate that is part of the digital certificate chain expired. Due to a bug in the code, certificate expiration is interpreted as a corrupted certificate and thus Event 17 is getting logged.

How do I get rid of Event 17?

For the license server connected to the Internet

If the license server is connected to the Internet, set the Connection Method to Automatic and reactivate it. Reactivating the license server deletes the expired license server certificate and gets the renewed one from the Microsoft Clearinghouse.

For the license server not connected to the Internet

If the license server is not connected to the Internet, delete the license server certificates manually.

To delete the license server certificate

1. Stop the Terminal Services Licensing service (termservlicensing) either from the “Services” Manager snap-in or from the command line (net stop termservlicensing).

2. Delete all the following registry key hives:

· HKLM\Software\Microsoft\TermServLicensing\Certificates

· HKLM\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.000

· HKLM\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.001

3. Start the Terminal Services Licensing service either from the “Services” Manager snap-in or from the command line (net start termservlicensing).

Why does the license server go into the deactivated state automatically?

After Event 17 is logged, if the Microsoft Clearinghouse is contacted for any activity apart from the reactivation of the license server (for example, installing client access licenses or deactivating license servers), RD Licensing Manager throws the following error:

In addition, the certificate store on the license server that contains the Microsoft Clearinghouse-issued certificates gets corrupted, and as a result the license server goes into a deactivated state. Event 38 is logged with the following error:

“The Remote Desktop license server cannot issue a license to the client because of following error: Can’t add certificate to store, error c0010020.”

Note: The license server database is not corrupted, so there is no need to rebuild the database or reinstall the license server.

How do I recover my license server from the deactivated state?

Delete the license server certificate. The license server will stop throwing the error “0xc0110011” and will go back to the activated state.

The Promise of VDI

The promise of Virtual Desktop Infrastructure (VDI) is that end-user desktops can be centralized in such a way as to move complexity and state from the desktop into the datacenter. To execute on this promise, we needed to allow people to use a broad range of endpoint devices without compromising on the end-user experience. To this end, we are developing a remoting approach that complements traditional graphics remoting capabilities and works for endpoint devices ranging from PCs to the most lightweight of thin clients.

Client-Centric Remoting

Traditionally, graphics remoting protocols like RDP have approached remoting in a client-centric way.  These protocols intercept graphics on the host device and then efficiently forward the intercepted graphics ‘primitives’ (e.g., “Draw Rectangle”, “Draw Line”) to the client device.  The client endpoint renders the primitives using a client-side counterpart for each graphics intercept point on the host.

This style of remoting is client-centric because the architecture relies heavily on the rendering capabilities of the client software and hardware.  There are benefits to client-centric remoting.  Chiefly, the bandwidth utilization is very good for graphics types that can be intercepted high in the software stack and sent as primitives.  But, when the client and host don’t both support a particular graphics type, either the application fails to run properly or the two sides negotiate down to a least common denominator graphics construct: a bitmap.  Bitmaps require more bandwidth than primitives.  For example, the primitive representation of ‘Draw Line’ would simply include the x, y coordinates for the line start and the line finish. The bitmap representation of the line would have to describe, minimally, the X and Y coordinates for every single point on the line.

If you have a powerful client device with a rich software stack and your host has all the right graphics intercept points, you can have a great user experience over a relatively low-bandwidth connection with a client-centric graphics solution.  But, if you have a less complex client device and/or are missing some important graphics intercept points on the host, client-centric remoting will result in gaps in the experience, such as choppy video or missing graphics.

Client-centric remoting originated when there was limited bandwidth from the datacenter to the end-user desktop and when the vast majority of applications were developed on top of the same Windows graphics APIs, GDI.

Host-Centric Remoting

Today, bandwidth is less expensive and in many places widely available.  Today’s modern Windows desktop includes rich media and 3D graphics content.  Additionally, a wide array of graphics types (for example, Silverlight, Adobe Flash, DirectX, Aero Glass, Windows Media, etc.) is now relevant to Windows users. These changing conditions call for the addition of a new model that can support all graphics types, including 3D, by sending highly compressed bitmaps to the endpoint device in an adaptive manner. We call this host-centric remoting.

You can ensure a consistent end-user experience for a wide array of devices if you follow the VDI model and enable movement of a large portion of the client software and hardware into the datacenter. With host-centric remoting, all the graphics can be intercepted on the host at a very low layer in the software stack. All graphics are rendered on the host into a single frame buffer (a temporary holding station for graphical updates) that represents the end-user display.  Changes to the frame buffer are sent to the client at a frame rate that dynamically adapts to network conditions and the client’s ability to consume the changes. The changes are sent to the client endpoint as highly compressed bitmaps by using an encoding scheme optimized for Windows desktop content. The basic graphics requirement for the client endpoint is that it supports the ability to decode and display the highly compressed bitmaps that it receives from the host. At a minimum, the client needs the decoder counterpart to the encoder that was used on the host as well as a basic graphics display capability.

The downside to host-centric remoting is that it requires more bandwidth than client-centric remoting. However, it delivers a consistent experience for every aspect of the modern Windows desktop projected out to an amazing diversity of client devices.

It’s Additive!

If you have a client device with a rich software stack and advanced processing capabilities, client-centric remoting makes sense. But, to completely deliver on the promise of VDI, you also need host-centric remoting.

RemoteFX is Microsoft’s first big step into the world of host-centric remoting. But, the obvious relationship between client-centric remoting and host-centric remoting is that you need both sets of capabilities in your remoting protocol. We are adding RemoteFX as a new capability or ‘payload’ to the RDP platform, while continuing to support and enhance our existing client-centric model. We offer our customers the best of both worlds in one solution. Host-centric remoting takes advantage of environments with ample bandwidth for content- and device-independent remoting, and client-centric remoting works well for network-constrained environments with richer, more powerful client devices. The fundamentals of RDP are unchanged. RDP includes the same authentication, encryption, device redirection, and transport capabilities independent of the remoting model being leveraged.