Remote Desktop Services (Terminal Services) Team Blog

New update to the RDS wiki: The Case of the Invisible RemoteApp Programs

termserv — Wed, 07 Dec 2011 23:52:00 GMT

In our previous blog entry on Remote Desktop Services resources for IT Pros, we mentioned that we'd added a new wiki for Remote Desktop Services in Windows Server 2008 R2. This wiki has been growing quickly, thanks to the efforts of some of our community. Most recently, we've released a new article on the TechNet Wiki entitled The case of invisible RemoteApp programs (a.k.a. No RemoteApp programs listed on RD Web Access site). This article discusses one of the error messages that you may get while trying to add one or more RemoteApp sources by using the Configuration tab on the RD Web Access page. It includes an analysis and troubleshooting tips using RD Web Access Tracing. The article also covers the permissions related to WMI and DCOM that you can check when you get these error messages.

If you have your own tips, we encourage you to add them to our wiki and link them to the appropriate landing page.

Help! Finding Remote Desktop Services Information Online

termserv — Mon, 21 Nov 2011 19:32:00 GMT

We’d like to ensure you can find the information you need to use Remote Desktop Services, so here’s a quick roundup of the available resources and when they’re appropriate.

For a comprehensive view of current white papers, the most recent blog posts, highlighted technical whitepapers and links to information about previous versions of RDS, see our TechNet home page. If you bookmark only one link, make it this one: it links to all the others.
If you’d like guidance to get you started, here’s a landing page for all our Step by Step guides.
To ask specific questions (or see if someone else already asked your specific question) go to our Remote Desktop Services Support forum. Very smart people hang out here, including members of the product group, support specialists, RDS (and other) MVPs, and members of the community. If you’re new to our support forums, we suggest you read Arthur Li's excellent pointers on how to ask a question in a way most likely to get you an answer.
Finally, we’ve been working on the Remote Desktop Services TechNet wiki for Windows Server 2008 R2 and would like to encourage you to use it and contribute information you think would be useful to other people deploying Remote Desktop Services.
For an offline reference, we have the Windows Server 2008 R2 Remote Desktop Services Resource Kit (available in hard copy and on Kindle).

Most important: please ask questions in the support forums, not in the blog comments. The support forums are much more widely seen than blog comments, so asking in the right place both increases your chance to get an answer and helps others who might have a similar issue find the answer. Thanks!

Remote Desktop Services Coverage at BUILD 2011

termserv — Wed, 21 Sep 2011 23:49:03 GMT

Remote Desktop Services had strong coverage at the Windows BUILD 2011 Conference held last week in Anaheim, California. This blog post recaps the major presentations at the conference where Remote Desktop Services technology in Windows Server 8 Developer Preview and Windows 8 Developer Preview was showcased.

Metro-style Remote Desktop app demonstrated at the opening keynote (starting 1:40:54)

Rich Remote Desktop experience demonstrated at the Windows Server 8 session (starting 1:02:40)

Break-out session: Remote Desktop Experience in Windows 8

Break-out session: Design for a multimillion thin client market with RemoteFX

How to troubleshoot Logon Attempt Failed messages when connecting through RD Gateway

termserv — Wed, 07 Sep 2011 17:59:00 GMT

Hi folks, once again hello. Today I would like to discuss a case where I was trying to fix web single sign-on (SSO) externally. SSO was working well internally, but when we were trying to make it work outside the environment (by using Remote Desktop Gateway), it was not working and resulted in continuous logon attempt failed error messages:

After exhausting all the methods I could think of, I configured another server basically the same (I only included the Remote Desktop Services role services though). I figured that I could compare configurations and see the differential.

I started looking at the possibility of a corrupted web.config or host file as the error suggested, but the cause turned out to be defining an HTTP redirect for the default website in IIS.

To start working on this issue, first test to see if you are being redirected by going to the following website in a browser: https://<servername>/rpc

After entering your credentials, if everything is working fine you should see a blank screen with the URL https://<servername>/rpc. However, in my case, I saw Page cannot be displayed, which told me that something was not good and I needed to troubleshoot the issue.

Finally, after some research, I found the resolution, which was simpler than I expected (as I was thinking it could be a certificate-binding or broken-binding issue, which could have caused me hours to troubleshoot).

To resolve this issue, locate the HTTP redirection setting and disable it:

In Server Manager, on the RD Gateway server, open Internet Information Services (IIS) Manager.
In the IIS navigation tree, expand the server and the sites, and then select Default Web Site.
In the middle pane (the settings area), double-click HTTP Redirect.
Clear the Redirect requests to this destination check box.

After completing this, single sign-on was working externally as well, but the question remained: “How can I enable the redirection?” I didn’t want to manually type in http://contoso.com/rdweb because I wanted to use http://contoso.com/ instead. After doing some research and getting help from my colleagues, I found that it could be done by just making a small change, detailed in the following steps.

To redirect HTTP:

1. Open IIS Manager.

2. Go to the RD Web Access website (by default, it’s the “Default Web Site”).

3. In the middle pane, click HTTP redirect.

4. Select the Redirect requests to this destination check box, and type the address for your website; for example: http://contoso.com/rdweb.

5. In the Redirect Behavior section, select the Only redirect requests to content in this directory (not subdirectories) check box.

6. Apply settings.

You are now all set for HTTP redirection from http://contoso.com/ to http://contoso.com/rdweb without breaking RD Gateway connectivity.

LG announces support for Windows MultiPoint Server 2011

termserv — Thu, 14 Jul 2011 19:19:00 GMT

This week, LG announced the U Series Network Monitor that supports Windows MultiPoint Server 2011 with stated availability in the United States of October 2011.

This is the first monitor that supports Windows MultiPoint Server and helps deliver on the promise of efficient and cost effective solutions for educational institutions.

Free Remote Desktop Services Application Assessment Program by ChangeBASE

termserv — Wed, 06 Jul 2011 19:12:00 GMT

Are you planning to move your desktop applications to Remote Desktop Session Host (formerly Terminal Server) but are not sure if they will work without issues? Are you looking for a tool to help you automatically determine compatibility? Your wait is over! ChangeBASE, a world leader in automated application compatibility testing and remediation, has created a new application compatibility tool for companies that are considering moving to a session virtualization scenario with Remote Desktop Services in Windows Server 2008 R2. We have been working closely with ChangeBASE to help release new AOK Plugins that will analyze your application portfolio for potential compatibility issues with Remote Desktop Session Host – you can read the press release here. These Remote Desktop Services plug-ins for ChangeBASE AOK will help you automatically test for the most common issues that applications experience, namely:

Elevated Privileges Detection
Global User Data Settings Detection
Host Detection
Per User Install Detection
Printed Driver Detection

For a limited time, ChangeBASE is offering a FREE AOK license to assess Remote Desktop Services applications. So go ahead and make use of this opportunity. More information on the program here.

[Edited to fix some wording]

How to restrict users from accessing local drives of an RD Session Host server while using RemoteApp programs

termserv — Thu, 26 May 2011 22:26:01 GMT

Hello, my name is Pankaj Pande and I would like to discuss a method that an administrator can use to keep users from storing files in public folders and scattering files randomly throughout a virtual machine pool or Remote Desktop Session Host (RD Session Host) server farm, while using Remote Desktop Services and RemoteApp programs. (Note: an “RD Session Host server” was formerly called a “terminal server” in Windows Server 2008.)

Currently, when a user creates an RDP session or a RemoteApp program, they can see, and in some cases transverse, drives C and D of the RD Session Host server. They can also save anything on the desktop, which might look like their personal desktop, but it's actually the desktop of the RD Session Host server.

Restrictions will disable Libraries and Favorites and will hide or restrict users or a group of users from accessing and viewing any drives on the RD Session Host server. Users will be provided with an error message even if they use the UNC path to access the drives.

The primary reason to remove Favorites and Libraries and access to drives is because they contain mostly accessed locations on a system, so in the case of the RD Session Host server, this includes the desktop, downloads, recent places, etc. It is recommended that a user not save any documents to these locations.

Removing Favorites and Libraries

You must perform these modifications on the RD Session Host server. You can use the Registry to make these changes.

Using the Registry (applies to all users including the administrators)

Note: Back up the key first and take ownership of the ShellFolder before changing the value of Attributes.

1. For Favorites, the key is:

[HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolder]
"Attributes"=dword:a0900100
Changing a0900100 to a9400100 will hide Favorites from the navigation pane.

2. For Libraries, the key is:

[HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolder]
"Attributes"=dword:b080010d
Changing b080010d to b090010d will hide Libraries from the navigation pane.

Hiding/Preventing Access to Drives

You can use Group Policy settings to hide and restrict access to drives on the RD Session Host server. By enabling these settings you can ensure that users do not inadvertently access data stored on other drives, or delete or damage programs or other critical system files on drive C.

The following settings are located in the Group Policy Management Console under User Configuration\Policies\Administrative Templates\Windows Components\Windows Explorer:

Hide these specified drives in My Computer. You can remove the icons for specified drives from a user’s My Computer folder by enabling this setting and using the drop-down list to select the drives you would like to hide. However, this setting does not restrict access to these drives.
Prevent access to drives from My Computer. Enable this setting to prevent users from accessing the chosen combination of drives. Use this setting to lock down the RD Session Host server for users accessing it for their primary desktop.

Applies to:

Windows Server 2008 R2
Windows Server 2008
Windows Server 2003

Other Group Policy Settings for Additional Security

You can also enable the following Group Policy settings at User Configuration\Administrative Templates\Windows Components\Windows Explorer:

Hides the Manage item on the Windows Explorer context menu — Enabled
Remove Hardware tab — Enabled
Remove “Map Network Drive” and “Disconnect Network Drive” — Enabled
Remove Search button from Windows Explorer — Enabled
Disable Windows Explorer's default context menu — Enabled
Remove Run menu from Start Menu — Enabled

Applies to:

Windows Server 2008 R2
Windows Server 2008
Windows 7
Windows Vista
Windows XP

New white paper: Why Hyper-V for VDI

termserv — Tue, 19 Apr 2011 05:04:58 GMT

We’ve just released a new white paper entitled Why Hyper-V for VDI. It explains why organizations should choose Hyper-V as their hypervisor when designing and implementing a Virtual Desktop Infrastructure (VDI) solution. It includes requirements analysis and benchmarking.

How to Enable Certificate Revocation Checking on a Remote Desktop Gateway Client

termserv — Tue, 12 Apr 2011 02:45:06 GMT

This blog is intended for Remote Desktop Gateway (RD Gateway) users who want to turn on certificate revocation checking on the RD Gateway client as a security best practice.

An RD Gateway server is configured with a server authentication certificate that is used for authenticating and securing the communication between the RD Gateway client and the RD Gateway server. To learn more about certificates on RD Gateway, see the blog Introduction to TS Gateway certificates.

To help maintain the integrity of an organization's public key infrastructure (PKI), the administrator of a certification authority (CA) must revoke a certificate if the subject of the certificate leaves the organization, if the certificate subject's private key has been compromised, or if some other security-related event dictates that it is no longer desirable to have a certificate considered valid. When a certificate is revoked by a CA, it is added to that CA's certificate revocation list (CRL). To learn more, see the TechNet article Revoking certificates and publishing CRLs.

The RD Gateway client by default is not configured to check whether the certificate installed on the RD Gateway server is revoked or not. As such, if you want to enable your RD Gateway clients to check for certificate revocation and proceed with the connection only if the server certificate is not revoked, run the following command on a command prompt on the RD Gateway client computer:

reg add "HKCU\Software\Microsoft\Terminal Server Gateway\Transports\Rpc" /v CheckForRevocation /t REG_DWORD /d 1

Important

The publishing and maintenance of the CRL is an integral part of the public key infrastructure (PKI) and is external to RD Gateway. Please do not enable certificate revocation checking on RD Gateway clients until you have confirmed that your infrastructure can support this; otherwise, even the basic connection to an end resource through the RD Gateway server will not work. This is the reason why certificate revocation checking is disabled by default on the RD Gateway client, and the recommendation is to turn it on as a security best practice only after ensuring that the CRL is accessible from the Internet.

How to resolve the issue: “A website wants to start a remote connection. The publisher of this remote connection cannot be identified.”

termserv — Tue, 05 Apr 2011 17:18:00 GMT

Applies to:

Windows Server 2008 R2
Windows Server 2008
Windows 7
Windows Vista

Hello, my name is Pankaj Pande and I would like to clarify a bit about the error message “A website wants to start a remote connection. The publisher of this remote connection cannot be identified.”

Often you receive this message when you try to run your remote applications, even though you have all the certificates in place and they are configured properly. You might ask “I have already signed my application with the trusted certificate and my web single sign-on (SSO) is working fine, so why I am receiving this error message?”

The answer: Although you have signed in the application by using the trusted certificate, the client computer needs the Secure Hash Algorithm 1 (SHA1) certificate thumbprints that represent trusted Remote Desktop Protocol (RDP) file publishers.

There are two ways that you can configure your computers so that you don’t see this error message again.

Method 1: Create a GPO with RDP signing settings (permanent fix)

You can create a Group Policy object (GPO) by using the following settings from your domain controller and push that policy to all the client computers that are trying to access the remote application.

Locate the SHA1 thumbprint

1. To find the SHA1 thumbprint, click Start, click Run, type mmc, and then click OK.

2. On the File menu, click Add/Remove Snap-in.

3. In the Available snap-ins box, click Certificates, and then click Add.

4. In the Certificates snap-in dialog box, select Computer account, and then click Next.

5. In the Select Computer dialog box, click Local computer: (the computer this console is running on), and then click Finish.

6. In the Add or Remove Snap-ins dialog box, click OK.

7. In the Console tree, expand Certificates (Local Computer), expand Personal, and then click Certificates.

8. Double-click the certificate that you want to use.

9. In the Certificate Properties dialog box, on the Details tab, click Thumbprint. The thumbprint number will appear in the box (example: 25 1a 22 02 b3 6d b6 f0 64 0b db 8d b5 4a bb 99 0f bc ed af).

10. Copy the thumbprint number, making sure that you don’t include the space in front of the number, and then click OK. (For example, if the number starts with <space>74…, start copying from the “74.”)

Add the SHA1 thumbprint to the Group Policy setting

1. On the domain controller, open the Group Policy Management Console (GPMC). You can open the GPMC in one of two ways:

Click Start, point to Administrative Tools, and then click Group Policy Management Console.
Click Start, click Run, type gpmc.msc and then click OK or press ENTER.

2. Go to the location of the Group Policy setting: <computer> | < user>\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.

3. In the Settings pane, double-click Specify SHA1 thumbprints of certificates representing trusted .rdp publishers.

4. Click Enabled, and then in the Comma-separated list of SHA1 trusted certificate thumbprints box, enter the SHA1 thumbprint of the certificate that you use for signing your remote applications or RemoteApp programs (i.e., paste the thumbprint number that you copied from the Certificates Properties page), and then click OK.

Note: Make sure that when you paste the number, there isn’t a space in front of it.

5. After enabling this policy setting on all the client computers, you should no longer receive the error message.

Method 2: Change logon settings (temporary fix)

1. When you log on to the RD Web Access web page, you have an option to choose whether you are on a public or a private computer.

2. Select This is a private computer, and then click Sign in.

3. You will still see the prompt, but this time when the security warning appears, select the Don’t ask me again for remote connections to this computer check box, and then click Connect.

4. The error message should disappear the next time you open the remote application or RemoteApp program.

Windows Thin PC Preview Now Available

termserv — Mon, 28 Mar 2011 23:12:27 GMT

Today Microsoft announced the availability of the Windows Thin PC public Community Technology Program (CTP) release.

Windows Thin PC is a Software Assurance (SA) benefit that provides a low footprint, locked down version of Windows 7 that enables organizations to repurpose existing PCs as thin clients with RemoteFX support included. Any registered user of Microsoft Connect can try it out. To do so, sign on to Microsoft Connect and search products for "Windows Embedded" to find the program "Windows Thin PC."

Q&A: Microsoft RemoteFX and Remote Desktop Session Host Servers

termserv — Fri, 25 Mar 2011 22:35:00 GMT

While we've blogged a lot about Microsoft RemoteFX and how virtual machines benefit from it in a virtual desktop infrastructure (VDI), we realized that we hadn't always discussed it in detail in relation to Remote Desktop Session Host (RD Session Host). We'd like to use this opportunity to answer some questions about RemoteFX on RD Session Host servers running Windows Server 2008 R2 Service Pack 1 (SP1).

Question: Does RemoteFX work on RD Session Host?

Answer: RemoteFX is a collection of features that enhance the user experience in Remote Desktop Services deployments. The advanced bitmap acceleration of RemoteFX works for VDI on Remote Desktop Virtualization Host (RD Virtualization Host) servers as well as for session delivery on RD Session Host servers running Windows Server 2008 R2 SP1. Other features of RemoteFX, specifically virtualization of graphics processing units (GPUs) and broad support for USB devices, are specific to virtual machine delivery through Remote Desktop Services in a VDI environment.

Q: What are the key benefits of using RemoteFX with RD Session Host?

A: Using RemoteFX on RD Session Host servers allows you to use RemoteFX enabled thin clients and zero clients to connect to the server. It also reduces the bandwidth required for displaying bitmap-intensive applications (such as Flash, Silverlight, and Windows Presentation Foundation applications) on a full desktop

Q: Do any features of RD Session Host not use RemoteFX?

A: RemoteApp programs do not use RemoteFX because they need drawing orders, so RemoteApp programs use Remote Desktop Protocol (RDP) 7. No user action is required to use RDP 7 for RemoteApp programs. Also, Aero® "glass" remoting is disabled when using RemoteFX on RD Session Host servers. When RemoteFX codec is used on RD Session Host, the display driver is RDP's XPDM driver, which does not support 3D rendering.

Q: Can I virtualize an RD Session Host server and use RemoteFX with it?

A: Yes, but this RD Session Host server will not virtualize the GPU of the server even if a GPU is present.

Q: Can a virtualized RD Session Host server use a GPU at all?

A: Yes. Windowed DirectX apps will still work on RD Session Host servers if a GPU is present; however, the GPU will not be virtualized in each session.

Q: How can I learn more about using RemoteFX on an RD Session Host server? How can I tell that it's working? How do I configure the settings?

A: For answers to these and other related questions, see the Step-by-step guide to deploying RemoteFX on an RD Session Host server. For a complete list of all RemoteFX resources, see this blog entry.

Q: How can I evaluate Windows Server 2008 R2 with SP1?

A: You can download a 180-day evaluation of Windows Server 2008 R2 SP1, or, if you already have Windows Server 2008 R2, you can download the stand-alone SP1.

Windows MultiPoint Server application compatibility information now available

termserv — Thu, 24 Mar 2011 21:39:01 GMT

Last September we blogged about the Remote Desktop Services Community Verified Application Compatibility Center that contains application compatibility information for products tested with Remote Desktop Services.

We are now pleased to announce this update: the community verified site now contains application compatibility data for both Remote Desktop Services and Windows MultiPoint Server 2011. With this update, we have added application compatibility information for approximately 240 products that have been tested with Windows MultiPoint Server 2011.

We hope this update will be useful to all the potential customers of Windows MultiPoint Server 2011.

Visit the Remote Desktop Services and Windows MultiPoint Server Community Verified Application Compatibility Center and see for yourself!

Mac RDP Source Code Now Available to RDP Licensees

termserv — Wed, 16 Mar 2011 18:01:55 GMT

In a previous blog entry, we announced that Remote Desktop Protocol (RDP) licensees now had access to RDP source code to help licensees make their own RDP clients. We've now expanded that source code to include not only the Windows RDP source, but the source for the Mac RDP client. As with the Windows RDP source, this code is for reference only and only available to RDP licensees.

The Mac RDP client source code includes the following features.

Feature	Details
Connectivity and capability, including codec negotiation	Maintains connectivity stages and client capability exchange.
Bulk compression	Includes multiple bulk compressors, including the most recent RDP 7 era decompressors.
Bitmap compression	Includes multiple bitmap compressors.
Clipboard redirection	Supports copy and paste of text.
Audio playback redirection	Enables basic audio remoting over RDP that is played on the client device.

For more information about the Mac RDP client, see the Microsoft Office:mac site. To learn more about the business aspects of licensing RDP, please send email to IP Licensing Requests at iplicreq@microsoft.com.

Farewell from Chandra Shekaran and Tad Brockway

termserv — Tue, 15 Mar 2011 21:01:23 GMT

Dear Remote Desktop Services Customers, Partners, Pundits, and Enthusiasts:

Now that RemoteFX has shipped, we have each decided to take on other Microsoft challenges outside of Remote Desktop Services.

Chandra Shekaran is moving to Bing to be the General Manager of the Search Technology Center – India in Hyderabad. Tad Brockway is moving back to Redmond from Silicon Valley to lead the AppFabric Developer Platform Program Management team.

Tad joined the Remote Desktop Virtualization (RDV) team in 1998 as a Software Design Engineer and has shipped every major Remote Desktop Services release, starting with Windows 2000. He most recently ran the RemoteFX engineering team.

Chandra took over leadership of RDV in 2003 and has been the General Manager for the team and the Remote Desktop Services business from Windows Server 2003 forward. He conceived and led the Calista acquisition, and shipping that technology as a Hyper-V and Windows Server value-add in the just released Windows Server 2008 R2 Service Pack 1 completes this exciting chapter for both of us.

The Remote Desktop Services technology and business has been a thrill for both of us. Desktop virtualization has come a long way and is still rapidly evolving. The team has innovated Remote Desktop Services significantly during this period as manifested by a ten-fold increase in the number of Remote Desktop Services-related patents. The number of Remote Desktop Services client access licenses and the revenue from them has grown by more than 400% since 2003. Remote Desktop Protocol (RDP) has grown to become foundational to a wide range of Microsoft products, from Hyper-V and System Center to Lync, Windows Live, and Xbox. Remote Desktop Services has grown from a relatively niche scenario to being on the radar of every CIO! But it retains the grassroots and strong community feel that developed in the early days of Terminal Services.

There are exciting times ahead for our partners, customers, and the RDV engineering team. We wish you the best of luck and will enjoy watching your progress as spectators as you all take Remote Desktop Services forward.

Sincerely,

Chandra Shekaran and Tad Brockway

Documentation Available for Microsoft RemoteFX

termserv — Fri, 25 Feb 2011 20:01:00 GMT

The RemoteFX documentation team has been hard at work creating topics that you can use to evaluate and deploy Microsoft RemoteFX within your environment. Following is a list of all the RemoteFX documents that were published to coincide with the Windows Server 2008 R2 with Service Pack 1 release.

The following documents were created for Microsoft RemoteFX:

The following existing Remote Desktop Services documents were updated to include Microsoft RemoteFX:

For information about the RemoteFX WMI provider documentation, see MSDN.

If you are interested in seeing more Remote Desktop Services documentation, see the Remote Desktop Services TechCenter.

RD Connection Broker plug-in for System Center Virtual Machine Manager 2008 R2 released!

termserv — Fri, 21 Jan 2011 05:37:55 GMT

We just released an RD Connection Broker plug-in for VMM 2008 R2 that enables dynamic placement of VDI virtual machines for both personal virtual desktops and virtual desktop pools.

To determine how this can help your VDI deployment, see Michael Kleef’s write-up: http://blogs.technet.com/b/mkleef/archive/2011/01/19/scvmm-rds-connection-broker-plugin-released.aspx

How to resolve the issue “Remote Desktop Disconnected” or “Unable to Connect to Remote Desktop (Terminal Server)”

termserv — Mon, 10 Jan 2011 17:54:50 GMT

One of the recurring issues seen in product support is why a client cannot connect.

Specifically, errors such as “Unable to RDP,” “Remote Desktop Disconnected,” or “Unable to Connect to Remote Desktop (Terminal server)” are common problems that we have seen come up in product support.

This article summarizes the various causes for Terminal Server Client (Remote Desktop Client) connection failures and how to fix them.

Some of the commonly seen Symptoms (order of frequency):

You may be limited in the number of users who can connect simultaneously to a Remote Desktop session or Remote Desktop Services session
You may have a Port assignment conflict
- Associated Error messages:
  Remote Desktop Disconnected.
  This computer can’t connect to the remote computer.
  Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.
You may have an incorrectly configured Authentication and Encryption setting
You may have a corrupted Certificate
- Associated Error messages:
  Remote Desktop Disconnected.
  Because of a security error, the client could not connect to the remote computer.
  Verify that you are logged on to the network and then try connecting again.
- Associated Event IDs:
  Event ID: 50
  The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client.
- Additionally, you may also see this error message:
  The client could not establish a connection to the remote computer.
  The most likely causes for this error are:
  1) Remote connections might not be enabled at the remote computer.
  2) The maximum number of connections was exceeded at the remote computer
  3) A network error occurred while establishing the connection
  4) The remote computer might not support the required FIPS security level. Please lower the client side required security level policy, or contact your network administrator for assistance.

We have provided step-by-step documentation on how to fix these issues in the following articles.

Main article:

Troubleshooting RDP Client Connection problems:

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

Please refer to any/all of the following articles based on your Remote Desktop Session Host Server OS:

Windows Server 2003: http://support.microsoft.com/kb/2477023
Windows Server 2008: http://support.microsoft.com/kb/2477133
Windows Server 2008 R2: http://support.microsoft.com/kb/2477176

More Information:

The following posts discuss symptoms 2 & 3 from above caused due to port assignment conflicts and/or encryption level settings:
The following article from ehow.com talks about how to troubleshoot a remote desktop disconnected problem but only covers very basic issues.
- http://www.ehow.com/how_6574577_troubleshoot-remote-desktop-disconnected-problem.html
Ex: It asks you to check if the computer you are connecting to is powered ON and/or not in ‘Sleep’ mode.
It also talks about some of the basic settings to enable remote desktop sessions which are covered in symptom 1 above.

Additionally, we have more symptoms documented under the following article:

Troubleshooting General Remote Desktop Error Messages

http://technet.microsoft.com/en-us/library/cc780927(WS.10).aspx

Note: This is a work in progress and we will constantly be updating these articles to reflect the latest issues and how to fix them.

The Windows Server 2008 R2 Remote Desktop Services Resource Kit is now available!

termserv — Thu, 06 Jan 2011 22:26:19 GMT

In 2008, I coauthored the Windows Server 2008 Terminal Services Resource Kit with Kristin Griffin, Remote Desktop Services MVP and a moderator on our TechNet Web forum. Since we are slow learners, in 2010 we decided to do it again. With the help of the Remote Desktop Virtualization team and the Remote Desktop Services community (including MVP Alex Juschin, our technical editor), we have written the vastly expanded, revised, and updated Windows Server 2008 R2 Remote Desktop Services Resource Kit. I’m happy to announce that it’s available today.

Our goals for this project were simple:

Enable readers to set up a working Remote Desktop Services-only environment to deliver full desktop sessions, personal virtual desktops and virtual desktop pools , and RemoteApp programs
Show readers how to leverage related technologies such as profiles, folder redirection, and Network Access Policies alongside Remote Desktop Services
Explain how Remote Desktop Services works as an aid to troubleshooting
Give readers insight from members of the Remote Desktop Virtualization team about how the product works, and share expert advice from the field
Direct readers to online resources related to Remote Desktop Services

As always, the people in the Remote Desktop Services community make a project like this a pleasure. Thanks for all the questions along the way—the questions people asked made the book that much better!

Configuring Virtual Display Adapters for Virtual Machines on a RemoteFX Server

termserv — Wed, 22 Dec 2010 21:39:00 GMT

This blog post describes the new Remote Desktop Services Windows PowerShell cmdlets, introduced in the Windows Server 2008 R2 SP1 timeframe, that configure virtual display adapters for virtual machines on a RemoteFX-enabled RD Virtualization Host server.

For a given Virtual Desktop Infrastructure (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 (graphics processing unit, sometimes referred to as a “graphics adapter”) on the server. RemoteFX uses a technology to share (virtualize) a single GPU between multiple virtual machines (VMs). It takes advantage of virtual GPUs on the host and advanced codecs to enable multi-user support for full-fidelity video, Silverlight, and 3D applications. More info about this can be found here.

The Remote Desktop Services Provider for Windows PowerShell provides the administrator with four new cmdlets that he or she can utilize to configure (add/remove/modify) the vGPU (synthetic 3D adapter) for one or more virtual machines on a RemoteFX-enabled RD Virtualization Host server. These Windows PowerShell cmdlets are briefly explained below. Note that these cmdlets can only be executed from an elevated Windows PowerShell command window (from any directory path) and the RemoteDesktopServices module needs to be loaded (‘import-module remotedesktopservices’) before executing any of these. Also, the VM needs to be shut down before adding a vGPU, removing a vGPU, or setting a vGPU configuration.

ADD-VGPU

Purpose: Adds a virtual display adapter to one or more virtual machines
Usage: Add-VGPU [-VirtualMachine] <VMName> [-Confirm] [-ShutDownVM]
Sample Usage: This cmdlet adds a virtual display adapter to the virtual machine 'uservm1' and shuts down the virtual machine if it is running.
- Add-VGPU uservm1 –shutdownVM
To get more information about this cmdlet, type: get-help Add-VGPU -detailed

REMOVE-VGPU

Purpose: Removes a virtual display adapter from one or more virtual machines
Usage: Remove-VGPU [-VirtualMachine] <VMName> [-Confirm] [-ShutDownVM]
Sample Usage: This cmdlet removes virtual display adapters from all virtual machines on this host computer and shuts down any virtual machines that are running. Also displays status messages during this operation.
- Remove-VGPU -VirtualMachine * -shutdownVM –verbose
· To get more information about this cmdlet, type: get-help Remove-VGPU -detailed

SET-VGPUCONFIGURATION

Purpose: Configures (MaxMonitors or MaxResolution) the virtual display adapter for one or more virtual machines, if the virtual display adapter is already added
Usage: Set-VGPUConfiguration [-VirtualMachine] <VMName> -MaxMonitors <NumMonitors> -MaxResolution <Resolution> [-Confirm] [-ShutDownVM]
- NumMonitors represents the number of monitors that you want the virtual display adapter to support. It can be 1, 2, 3 or 4.
- Resolution represents the maximum screen resolution that you want the virtual display adapter to support. It can be '1024*768', '1280*1024', '1600*1200', or '1920*1200'.
Sample Usage: This cmdlet sets the maximum screen resolution to 1,920 by 1,200 pixels for virtual machine 'VM1'. It shuts down the virtual machine if it is running.
- set-VGPUConfiguration -VirtualMachine VM1 -MaxResolution 1920*1200 –ShutDownVM
To get more information about this cmdlet, type: get-help Set-VGPUConfiguration -detailed

GET-VGPUCONFIGURATION

Purpose: Retrieves the configuration (MaxMonitors and MaxResolution) of the virtual display adapter on one or more virtual machines, if the virtual display adapter is already added
Usage: Get-VGPUConfiguration [-VirtualMachine] <VMName>
Sample Usage: This cmdlet gets the virtual display adapter configuration for all virtual machines on this host computer.
- get-VGPUConfiguration -VirtualMachine *
To get more information about this cmdlet, type: get-help Get-VGPUConfiguration -detailed

Configuring Remote Desktop licensing settings on a Remote Desktop Virtualization Host server

termserv — Thu, 16 Dec 2010 02:16:00 GMT

[Step 4 corrected 1/27/2011. Thank you, pdias]

This blog post introduces the Windows PowerShell cmdlets for configuring Remote Desktop licensing settings on a RemoteFX-enabled RD Virtualization Host server in Windows Server 2008 R2 SP1.

Until Windows Server 2008 R2, in a Virtual Desktop Infrastructure (VDI) deployment, the RD Virtualization Host server was not aware of licensing settings because only the RD Session Host server participated in licensing and performed license validations for the client session/connection requests. But the new licensing model for the Microsoft VDI solution (in Windows Server 2008 R2 SP1) requires that the Remote Desktop licensing mode and the list of Remote Desktop license servers be specified on all RD Session Host servers (configured in virtual machine redirection mode) as well as on all RD Virtualization Host servers (with RemoteFX enabled), because the RD Virtualization Host servers can also participate in VDI licensing.

Because there is no GUI interface for specifying licensing configuration on an RD Virtualization Host server, support has been provided in Windows PowerShell to enable this scenario. As a result, a VDI administrator who does not want the (RemoteFX-enabled) RD Virtualization Host server’s licensing settings to be centrally managed (from the RD Connection Broker server) can manually configure these settings on the RD Virtualization Host server(s) in the VDI deployment by using the following Windows PowerShell cmdlets:

1) In an elevated Windows PowerShell command prompt, execute the following command: import-module remotedesktopservices; cd RDS:\RDVHConfiguration\LicensingSettings

2) This node displays licensing settings configured on the RD Virtualization Host server.

· The LicensingName and LicensingType properties denote the licensing type for the RD Virtualization Host servers.

· The SpecifiedLicenseServers container contains the list of license servers to be used.

· The RegisteredLicenseServers container contains the list of Remote Desktop license servers that are registered with the current domain.

· The default value of LicensingType will be 1, LicensingName will be blank, and SpecifiedLicenseServers will be empty when accessing these for the first time.

3) Execute the command: set-item LicensingType <value>, where <value> can be 2 (Per Device mode) or 4 (Per User mode).

4) Execute the command: new-item -path .\SpecifiedLicenseServers -name <value>, where <value> is the name of the Remote Desktop license server, for each of the Remote Desktop license servers that you want to specify on this computer.

These settings will be used by this RD Virtualization Host server to perform license validations for the virtual machine connection requests whenever applicable. These settings will be overwritten by the centralized licensing settings if the administrator enables ‘Central Licensing Management’ mode on the RD Connection Broker server that manages this RD Virtualization Host server.

If these licensing settings need to be modified later, in an elevated Windows PowerShell command prompt, execute the command: import-module remotedesktopservices; cd RDS:\RDVHConfiguration\LicensingSettings, and then update the Remote Desktop licensing mode or the list of Remote Desktop license servers as desired.

Centralized Licensing Management for Microsoft VDI

termserv — Mon, 06 Dec 2010 06:05:49 GMT

This blog post introduces the new Centralized Licensing Management work, implemented in Windows Server 2008 R2 Service Pack 1 (SP1) as a part of the RemoteFX feature, for centrally managing the licensing configuration in a Microsoft Virtual Desktop Infrastructure (VDI) deployment.

This post assumes that you have a basic understanding of the following:

Windows PowerShell
Various Remote Desktop Services role services
Remote Desktop Licensing
Microsoft VDI with Remote Desktop Services

What is Centralized Licensing Management?

Centralized Licensing Management is a new sub-feature that has been implemented in Windows Server 2008 R2 SP1, as a byproduct of RemoteFX work. It enables Microsoft VDI administrators to specify licensing configuration for the entire VDI deployment centrally from one place; that is, from the RD Connection Broker server.

Why is centralized licensing management required?

Until Windows Server 2008 R2, in a VDI deployment the RD Virtualization Host server was not aware of licensing settings because only the RD Session Host server participated in licensing and performed license validations for the client session/connection requests. But the new licensing model for Microsoft VDI (in Windows Server 2008 R2 SP1) requires that the Remote Desktop licensing mode and the list of Remote Desktop license servers must be specified in all RD Session Host servers (configured in VM redirection mode) as well as in all the RD Virtualization Host servers (with RemoteFX enabled), because the RD Virtualization Host servers can also participate in VDI licensing. Therefore, an option was provided for the admins to specify licensing configuration on the RD Connection Broker server. This would address the following concerns:

Lack of a GUI interface for specifying a licensing configuration on an RD Virtualization Host server, which makes it difficult for VDI administrators to configure this on multiple RemoteFX-enabled RD Virtualization Host servers.
Licensing mode mismatch across the RD Session Host server configured for VM redirection and RD Virtualization Host servers. (Licensing mode inconsistency across the deployment leads to license wastage and/or potential service denials.)

How does centralized licensing management work?

As a part of this feature, the licensing settings (Remote Desktop license type and the list of specified Remote Desktop license servers) can be specified on the RD Connection Broker server. This feature also provides an option to turn centralized licensing management ON or OFF (in case the VDI administrator decides to configure licensing separately on different servers). A VDI administrator can configure centralized licensing management on the RD Connection Broker server by using one of the following:

Remote Desktop Connection Manager UI
The Remote Desktop Services module for Windows PowerShell

Configuring licensing through the RD Connection Broker UI

On the RD Connection Manager (sbmgr.msc) home page in the middle pane, there is an entry for RD Licensing under the Virtual Desktops: Resources and Configuration table. Click the Specify link that corresponds to RD Licensing to open Virtual Desktops Properties.
When accessing centralized licensing for the first time, because it is disabled by default, all the other fields and buttons will be grayed out except the Apply the following settings to all servers check box.
Enable central mode by selecting this check box, if it is not already enabled.
Select the desired licensing mode, add the Remote Desktop license servers that you want to specify, and then click OK or Apply.
These settings will be propagated to the RD Session Host server in redirection mode and all the RemoteFX-enabled RD Virtualization Host servers which are added on the RD Connection Broker server.
As mentioned in Virtual Desktop Properties, the servers configured later will automatically inherit these licensing settings.

If these licensing settings need to be modified later, just open this Properties page again, update the licensing mode or the list of Remote Desktop license servers, and then click OK or Apply. The modified settings will be applied on all the servers that are configured on the RD Connection Broker server.

If the administrator decides that the licensing settings should not be centrally managed and wants to specify different licensing settings manually on different RD Virtualization Host servers, he can simply clear the Apply the following settings to all servers check box and specify licensing settings separately on all the RD Virtualization Host servers which have RemoteFX enabled.

Configuring licensing through the Remote Desktop Services module for Windows PowerShell

On an elevated Windows PowerShell command prompt, execute the following command: ‘import-module remotedesktopservices;cd RDS:\connectionbroker\VirtualDesktops\LicensingSettings; ’
This node displays licensing settings configured on the RD Connection Broker server.
The UseCentralLicensingSettings property specifies whether to use the centralized licensing settings. The LicensingType property denotes the licensing type for the VM redirectors and RD Virtualization Host servers. The LicenseServers container contains the list of license servers to be used.
Because central licensing is disabled by default, UseCentralLicensingSettings will be 0, LicensingType will be 5, and LicenseServers will be empty when accessing it for the first time.
Execute the command set-item UseCentralLicensingSettings 1 to enable the central management of licensing settings. If enabling central management for the first time, the licensing type also needs to be specified in this command: set-item UseCentralLicensingSettings 1 –LicensingType <value>, where <value> is the desired value of the licensing type.
Execute the command set-item LicensingType <value>, where <value> can be 2 (Per Device mode) or 4 (Per User mode).
Execute the command new-item .\LicenseServers <value>, where <value> is the name of the license server, for each of the license servers that you want to specify.
These settings will be propagated to the RD Session Host server in redirection mode and all the RemoteFX-enabled RD Virtualization Host servers that are added on the RD Connection Broker server.
The servers configured later will automatically inherit these licensing settings.

If these licensing settings need to be modified later, in an elevated Windows PowerShell window, execute import-module remotedesktopservices; cd RDS:\connectionbroker\VirtualDesktops\LicensingSettings; and update the licensing mode or the list of Remote Desktop license servers as desired. The modified settings will be applied on all the servers that are configured on the RD Connection Broker server.

If the administrator decides that the licensing settings should not be centrally managed and wants to specify different licensing settings manually on different RD Virtualization Host servers, he or she can simply execute set-item UseCentralLicensingSettings 0 and specify licensing settings separately on all the RD Virtualization Host servers that have RemoteFX enabled.

New Joint Citrix/Microsoft Facebook Forum

termserv — Wed, 17 Nov 2010 05:43:34 GMT

Got a virtualization issue?

Not sure if it’s a Microsoft or Citrix problem?

Jump on the new Facebook forum to discuss your issue, share ideas, opinions, and information related to Citrix and Microsoft Virtualization products.

http://www.facebook.com/pages/Citrix-and-Microsoft-Support/113004065426683?v=wall

Wrapping up “version 1” of Microsoft RemoteFX

termserv — Tue, 09 Nov 2010 22:44:00 GMT

Hi, my name is Chandra Shekaran, and I am the general manager for Remote Desktop Virtualization at Microsoft. In January 2008, I blogged about a new acquisition that we had just completed at that time, the acquisition of Calista Technologies. And while we weren’t able to tell you then when Calista would be shipping and in what form, we knew one thing: When it shipped, it would change how the industry thinks about deploying and managing a modern Windows desktop. In addition, it would change the perception of those who thought that server-hosted desktops and a rich, local-like user experience from remote clients anywhere were incompatible paradigms.

Today, at TechEd Europe 2010 in Berlin, I am delighted to say that we have almost completed our mission by wrapping up “V1” of Microsoft RemoteFX, our new name for Calista: we released the Release Candidate build of Windows Server 2008 R2 Service Pack 1 (SP1) late last month, of which RemoteFX is a key new feature.

With this release, Microsoft is enabling centralized Windows desktop deployments hosted by Hyper-V that can be accessed from anywhere by RemoteFX-powered clients to provide a rich, high-fidelity Windows user experience. RemoteFX supports scalable Virtual Desktop Infrastructure (VDI) deployments by tapping the power of graphics processing units (GPUs) through GPU virtualization. Hyper-V is the first hypervisor in the industry to support true multi-user GPU virtualization for VDI deployments.

The encoder and decoder aspects of RemoteFX are implementable in software or hardware, thereby providing opportunities for hardware partners to license the technology and add value. Server OEMs are showcasing the server models that support RemoteFX at TechEd Europe 2010. GPU vendors have already announced their active support for Remote FX, and thin client and system-on-a-chip vendors are showing their products that support RemoteFX. Over the last several months, Microsoft has released several overview guides and step-by-step guides for those of you who want to download and evaluate RemoteFX.

I want to take a moment and thank our teams at Microsoft and the Calista folks who are now part of the Remote Desktop Virtualization family, for the outstanding work they have done in integrating RemoteFX into Hyper-V and Remote Desktop Services in this release and for allowing our customers to deploy media-rich, virtual and session-based remote desktops while ensuring a full-fidelity, local-like user experience over the network.

Highlights from TechEd Europe 2010

But my appreciation reaches far beyond our own teams at Microsoft. In fact, those of you who have been following our RemoteFX blogs already know what an incredible amount of excitement and commitment we have seen from hardware and software partners since we acquired Calista to create the most compelling RemoteFX solutions for VDI and session virtualization. It’s impossible to do justice to every single partner in this one blog, and I wish to thank all of them for their support. While TechEd is in full swing in Berlin, I do want to mention some of the highlights that can be seen there as the result of our partners’ great work:

Yesterday, you could get a sneak peek of a first-of-its kind technology during the Brad Anderson keynote: HP has partnered with Texas Instruments (TI) for a technology demonstration of the power of future RemoteFX hardware-based thin clients. After the keynote, attendees were able to take the technology for a spin in the RemoteFX Pavilion at the HP demo area. By the way, please also check out the awesome, PC-like performance of HP’s software implementation of RemoteFX with the Windows Embedded 7-based HP t5740e Flexible Series Thin Clients.
Citrix was also an important part of yesterday’s keynote demo. XenDesktop provides management services at scale for VDI deployments while its Branch repeater products accelerate RDP with RemoteFX. You can find Citrix’s description of the highlights of the demo, which leveraged XenDesktop to launch a RemoteFX connection, at Natalie’s blog here. In her blog, Natalie states that XenDesktop will support RemoteFX within a quarter of the general availability of Windows Server 2008 R2 Service Pack 1, which is great news.
Dell has posted a blog about the testing they have done with Windows Server 2008 R2 Service Pack 1 on Dell hardware. Dell tested RemoteFX for VDI and session virtualization, and in their blog they also reported seeing up to 40% user density improvements with Dynamic Memory, another key feature in SP1. For more background on these user density improvements, please also check out Michael Kleef’s blog.
Ron from Texas Instruments has a blog on TI’s product to enable RemoteFX-supported thin clients; TI was the platform used in the HP thin client demonstrated at the keynote, so make sure you check out Ron’s blog for his thoughts.
Cloudium Systems is another RemoteFX licensee and is showing their first RemoteFX “zero client” at TechEd Europe 2010. According to Tommy’s blog, Cloudium Systems zero clients will provide customers with a high performance, low cost, low power consumption, and easy to use solution for RemoteFX.
Quest is one of the RemoteFX partners joining us again at TechEd Europe 2010. They provide a value added VDI solution on top of Remote Desktop Services and accelerate RDP with RemoteFX for use beyond LAN scenarios. Check out their blog as well as their demo in the RemoteFX partner pavilion.
Cisco is blogging about the testing they have done with the Cisco WAAS product for RDP 7.0 and RDP 7.1 (with RemoteFX) connections, focusing on the delivery of Windows 7 desktops over the WAN.
Riverbed is a WAN-accelerator vendor that is showcasing its upcoming support for RDP/RemoteFX acceleration. Check out their blog.

I hope this gives you a bit of a taste of the level of excitement and buzz around RemoteFX here at TechEd Europe in Berlin. We believe that in the future, RemoteFX will be extremely beneficial in allowing Microsoft to create a superior customer experience in other product areas, and we are just starting to imagine the potential. But today, the possibilities of desktop virtualization with RemoteFX is capturing people’s minds, so please stay tuned and come back here to read our blog every once in a while for more details about the latest product plans and accomplishments.

Chandra Shekaran
General Manager
Microsoft Remote Desktop Virtualization

Introducing Microsoft RemoteFX USB Redirection: Part 3

termserv — Tue, 09 Nov 2010 04:59:03 GMT

In Part 1 of our series on RemoteFX USB redirection, we looked at an overview of the feature and what it can do, and how to set up a basic deployment of the feature. In Part 2, we discussed publishing, deploying for rich and thin clients, RD Web Access, and server device security. Now, let’s take a look at your most frequently asked questions about RemoteFX USB redirection.

What are the requirements for RemoteFX USB redirection?

RemoteFX USB redirection is only available when connecting to a RemoteFX-enabled Windows 7 SP1 virtual machine (VM) running on a RemoteFX-enabled Remote Desktop Virtualization Host server. For information about the requirements for RemoteFX, see Beta testing RemoteFX in Service Pack 1.
RemoteFX USB redirection is not available for connections to a Remote Desktop Session Host server.
RemoteFX USB redirection is available for connections to VMs through RD Web Access and for RemoteApp programs running on RemoteFX-enabled Windows 7 SP1 VMs.
The Remote Desktop Protocol (RDP) 7.1 client must be installed, and the Group Policy setting enabled. See Part 1 of the blog. You must restart your client computer for RemoteFX USB redirection to be functional.
The USB devices that you would like to use in the remote session must be plugged in before starting Remote Desktop Connection; devices plugged in during the session will not be redirected.
RemoteFX USB redirection, like the rest of RemoteFX, has been designed for LAN connections (< 20 ms latency); on the WAN, some USB devices may not function properly, or the user experience may not suitable.
Due to USB limitations, a device redirected by using RemoteFX USB redirection can only be used in one RDP session at a time, and cannot be used locally while it is redirected to the VM.
If you add a new device to the client computer that you want to redirect, you must log off from your virtual desktop and then log back on.
Drivers for redirected USB devices will be installed on the VM by using the same process that a physical Windows computer uses when a device is plugged in. Please ensure that Windows Update is enabled on the VM or that drivers are available for the device in question.

What devices are supported by RDP with RemoteFX USB redirection?

Device	Support status	Redirection method
All-in-One Printer	Supported	RemoteFX USB redirection
Printer	Supported	Easy Print
Scanner	Supported	RemoteFX USB redirection
Biometric	Supported while in a session Not supported during logon	RemoteFX USB redirection
PTP Camera	Supported	Plug and Play device redirection
MTP Media Player	Supported	Plug and Play device redirection
Webcam	Supported (LAN only)	RemoteFX USB redirection
VoIP Telephone/Headset	Supported (LAN only)	RemoteFX USB redirection
Audio (not a USB composite device)	Supported	Audio redirection
CD or DVD drive	Supported for read operations	Drive redirection
Hard Drive or USB Flash Drive	Supported	Drive redirection
Smart Card Reader	Supported	Smart card redirection
USB-to-Serial	Supported	RemoteFX USB redirection
USB Network adapter (also includes some personal digital assistants)	Blocked	N/A
USB Display	Blocked	N/A
USB Keyboard or Mouse	Supported	Input redirection

The highlighted devices are supported by RemoteFX USB redirection. Other devices in this table are supported by high-level device redirection mechanisms.
Devices not listed in the table will be processed by using RemoteFX USB redirection; they may work, but are not considered officially supported.

How do audio devices work with RemoteFX USB redirection?

When redirecting a USB VoIP phone or other USB audio device to the remote session, you have a choice between high-level audio redirection and USB audio redirection:

High-level audio redirection allows you to use your default Windows audio playback and recording devices in the remote session. The devices can be used in both the local and remote session at the same time. This mode works on both LAN and WAN. However, extended VoIP phone functionality/call controls will not work in this mode.
USB audio redirection is the preferred mode for those who want to use USB phones in their remote session. USB audio redirection allows the use of all features of your USB VoIP devices in the remote session, including call controls. However the USB audio device can only be used by the remote session while it is redirected. This mode is LAN-only.

While high-level audio redirection is in use, USB audio redirection cannot be used, and vice-versa.

To adjust the audio settings for a remote session, in Remote Desktop Connection, go to the Local Resources tab, and in the Remote audio section, click Settings.

To use USB audio redirection: Set audio playback to Play on remote computer. On the Local Resources tab, in the Local devices and resources section, select the box to redirect the audio device over USB.

To use high-level audio redirection: Set audio playback to Play on this computer and audio recording to Record from this computer. On the Local Resources tab, in the Local devices and resources section, do not select the box to redirect the audio device over USB.

How can I verify that RemoteFX USB redirection was installed properly on the client?

In Device Manager, expand Universal Serial Bus controllers, and find any of the USB root hub, USB hub, or USB controller devices. Right-click the device, then click Properties. On the Driver tab, click Driver Details. If RemoteFX USB redirection is properly installed and enabled, tsusbflt.sys will appear in the list of driver files provided.

Notes on specific devices

Webcams/VoIP devices

Older LifeCam devices (VX6000) may not function in the remote session. Please use a newer LifeCam device.
Older LifeCam drivers may not start when the webcam is redirected. Please ensure you are using the latest LifeCam drivers.
In order for the LifeCam software to recognize the webcam, the webcam microphone must be redirected (follow the steps for USB audio redirection listed above). The webcam can be used in other applications even if the microphone is not redirected.
A USB webcam microphone cannot be used at the same time as the local non-USB speakers. Resolution: Install either an extra microphone or USB headset/speakers.
Some internal notebook webcams will not work with RemoteFX USB redirection.
Webcams and VoIP devices are not supported on WAN. Attempts to use these devices on high-latency networks may cause the VM to crash.
For best videoconference performance, please ensure the connection type in the Remote Desktop Connection client is set to LAN.
Office Communicator may need to be restarted to recognize newly added USB VoIP/webcam devices.
For best performance with Office Communicator* VoIP phones, please use Office Communicator 14 (“Lync”) in the VM, and ensure that the following registry key is set:
Path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator\EnableTJOCPairingRemoted
Type: REG_DWORD
Value: 1

* The usage of Office Communicator in a remote session is not officially supported at this time.

Mass storage devices (hard drives, CD/DVD drives, memory card readers, USB flash drives)

Mass storage devices are redirected via drive redirection, which provides file system level access to the device. These devices are not redirected via RemoteFX USB redirection. Exception: When an all-in-one printer is redirected, the memory card reader in the device will be redirected via RemoteFX USB redirection.
Drive redirection does not provide low-level access to the redirected drive. As such, the following are not supported in the remote session:

CD Burning (However, drive-letter access (DLA) using an appropriate DLA application installed on the client will function in the remote session.)
Audio extraction/CD “ripping”
Playback of encrypted DVDs
Copy-protected games
Managing BitLocker-encrypted USB storage

Portable devices

Some older Windows Mobile PDAs cannot be used with Windows Mobile Device Center in the remote session if the device appears as a network adapter. Workaround: On the Windows Mobile device, go to Settings > Connections > USB to PC (or equivalent) and clear the Enable faster data synchronization check box.
In order to use an Apple iPhone/iPod Touch in the remote session from a rich client, iTunes needs to be installed on the client, and the device must be redirected by using RemoteFX USB redirection. If the device does not appear in the list of “Other supported RemoteFX USB devices” but does appear in the list of “Other supported Plug and Play devices,” please uninstall the device in Device Manager and reinstall the device (Scan for Hardware Changes).

For more information

To learn more about RemoteFX USB redirection, see the “Configuring USB Device Redirection with Microsoft RemoteFX Step-by-Step Guide” on the Microsoft Technical Library: http://technet.microsoft.com/en-us/library/ff817581(WS.10).aspx .

I hope you’ve enjoyed our series of blogs on RemoteFX USB redirection. If you have any questions or comments, please post them to the blog. We look forward to hearing from you!