Blog Post

Ask The Performance Team
6 MIN READ

Walkthrough on Session hint / TSVUrl on Windows Server 2012

CraigMarcho's avatar
CraigMarcho
Icon for Microsoft rankMicrosoft
Mar 16, 2019
First published on TECHNET on Jun 11, 2015

Hello Askperf, my name is Naresh and today we are going to discuss how we can connect to a Windows 2012 Remote desktop collection from thin clients or other clients that are not session hints aware.

You might be thinking what are “Session hints”, so let us right away dig into the need for session hints. The connection broker in Windows 2012/R2 has changed the way clients connect to a group of RDSH/RDVH servers – earlier called farms but now we have them grouped as ‘collections’ in Windows 2012/R2. With Windows 2012, we brought changes in the way how the GUI looks, how we install different roles and how these different roles interact with each other. With all this the flow of remote desktop connections and how a client connects to the endpoint servers, changed as well.

Classical way of connecting to Remoteapps-windows server 2008 r2

In Windows 2008 R2 we deployed RemoteApps as:

  1. MSI files
  2. RDP files
  3. Connect through RDWeb

To explain the connection flow I will walk you through the RDP file content of a RemoteApp in Windows 2008/R2 vs. Windows 2012/R2.

This is how a RDP file for a RemoteApp would look like in a 2008 R2 RDS environment:

  1. The client reads the full address (of the farm) and the RDGateway properties.
  2. If the client finds the RDGateway, it will authenticate against the gateway and based on the CAP and RAP policy the connection would be passed on.
  3. The Client would then do a DNS query for the full address (of the farm) – assuming this is a DNS Round Robin or the farm name is pointing to a NLB – and would try to connect to the RDSH server. (If there is a dedicated redirector, then one of them will receive this connection.)
  4. The RDSH (or the redirector) server receiving the connection would then contact the connection broker and if there is an existing disconnected session available for this user on an RDSH, the connection broker would send the details of the RDSH server back to the redirector. If there is no disconnected session, the connection broker would determine the best suited server as per the load balancing algorithms and would send the details of that server to the redirector.
  5. Redirector would in turn pass those details to the client and the client would then directly logon to the application on the assigned server. Session established.

Change in the way we connect in 2012 -Session Hint / TSVUrl

In a 2012/R2 environment the RDP file looks like this:

  1. In Windows 2012 the concept of Farms has been deprecated and replaced by collections. However, unlike Farms, collections do not have an entry in the DNS. Therefore the client reads the full address (which is for connection broker which hosts the RDS deployment and collections) and the RDGateway properties.
  2. If the client finds the RDGateway, it will authenticate against the gateway and based on the CAP and RAP policy the connection would be passed on.
  3. The Client would then do a DNS query for the full address, i.e. the connection broker for windows 2012 and would try to connect to the RD Connection broker. The term redirector is no longer used in Windows 2012 and instead connection broker does the redirection, but how?

What are session hints/TSVUrls ?

If you see the above RDP file, I have also highlighted the loadbalanceinfo which consists of the TSVUrl. A TSVUrl or session hints suggests which collection in the deployment the client should connect to. So along with the Full Address and gateway information, the client also reads the loadbalancerinfo and sends that over to the connection broker.

4. The connection broker then reads the TSVUrl to determine the collection name and then suggests which RD Session host participating in the collection should take the session based on whether there is an already existing session or not.

5. If there is an existing session available for this user on an RDSH in that collection, the connection broker would send the details of the RDSH server back to the client. If there is no disconnected session, the connection broker would determine the best suited server within the collection as per the load balancing algorithms and would send the details of that server to the client.

6. The client would then directly logon to the application on that assigned server. Session established.

DefaultTsvUrl: workaround for incompatible RDClient

However, what would happen if the RD client does not understand the TSVURLs? Yes, the client would directly logon to the connection broker but since the application is not hosted there, it would error out.

We have seen a lot of customers not wanting to move over to Windows 2012 Remote desktop services because they have Clients like, old thin clients with old RD clients and some non-windows clients or some of the old Windows clients that might not understand TSVURLs. I would highly recommend upgrading the clients to the latest by getting in touch with the OEM vendor/manufacturer for getting the latest RD client for these devices (in case of old Windows fat cients either install RDC 8 or later or else upgrade to the operating system that supports RDC 8) making sure they are tsvurl aware, given the so many other benefits and features the latest RD client would bring along. However, we do understand that some of our customers would have genuine reasons to keep these clients and also while planning and implementing an upgrade, one would need to run the show in the meantime with the non-compatible clients.

For such cases, we can use the below registry key on the connection broker hosting the deployment.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base 322756 How to back up and restore the registry in Windows.

The following tuning recommendation has been helpful in alleviating the problem:

1. Start Registry Editor (Regedit.exe).

2. Locate and then click the following key in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings

3. On the Edit menu, click Add Value , and then add the following registry value:

Value name: DefaultTsvUrl
Data type: REG_SZ
Value data: tsv://<TSVURL>

This registry would provide the connection broker with the default loadbalanceinfo in case the client was unable to read the loadbalanceinfo provided in the remoteapp.

To find the TSVUrl to be set in DefaultTsvUrl , you can go to the following registry on the connection broker:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<CollectionName>\Applications\<RemoteApp>\

RDPFileContents REG_SZ

You can find the tsvurl in the RDPFilecontents of the collection you would like to set as your default. Then configure it as your DefaultTsvUrl . You can then keep the show running while you upgrade to newer compatible clients.

NOTE: This is being suggested as an alternate/workaround when you do not have upgrading the client as an option. It has the following caveats that one should be aware of:

  1. This would only be read when the client is unable to understand the tsvurl sent in the RDP file (from the remote app) and thus does not present the tsvurl to connection broker.
  2. Whenever such a client comes the DefaultTsvUrl sends it to one single collection as specified in the registry value. DefaultTsvUrl can only point to one single collection only and thus you may want to plan and create a single collection for non compatible clients that has all their required apps in it. There is no provision of defining multiple collections in this registry so if you want to use incompatible clients over multiple collections then it won't be possible.
  3. In case you change that collection, you will have to change the defauDefaultTsvUrl lttsvurl registry value as well.
  4. This registry is only a workaround for tsvurls and will not work if the clients are not compatible with remoteapps itself. It is only for providing a workaround for clients that were able to access remoteapps earlier in Windows 2008/R2 but cannot access them through collections as explained in the section " Change in the way we connect in 2012 -Session Hint / TSVUrl" .

-Naresh

Updated Mar 16, 2019
Version 2.0
No CommentsBe the first to comment