Friday, June 21, 2013

RD Connection Broker Redirection Timeout (ConnectionRedirectTimeout) and Sysinternals

 

I was working on a VDI project for a customer this week.  The solution was for a public library, the software used by the library added a custom GINA to Windows, that is to say it replaced the default logon screen, like so:

image

A VDI solution was proposed using the pooled desktop scenario, whereby a connection broker was used to distribute the connections amongst several RD virtualisation hosts, all using a template ‘gold’ image.

Problem…

Now, because of the custom GINA, the RD connection broker would correctly redirect the connection to the Windows 7 VMs, but… would disconnect the session after around 6 minutes as there had been no login activity.  This was a problem in this scenario as the library terminals spent most of their time at the login screen, wanting for a member of the public to come up and use them.  The problem source was identified as the RD connection broker, not the VM itself by two methods:  First, RD connections directly to the Win 7 VM stayed active for ever, secondly, the following log entries were spotted on the RD connection broker:

image

What could be the solution to this problem?  I like to think I know MS products pretty well and thought that there must be a parameter for this.

Diagnostics…

I first identified the RD connection broker as the TSSDIS service (tssdis.exe).  I then looked at a Process Monitor trace of tssdis.exe during start-up so that I could identify any configuration files or registry keys that were read.  This revealed that the service evaluated the HKLM\System\CurrentControlSet\Services\tssdis\parameters key.  Great, I thought.

image

These were the settings that I came across.  There is some documentation as to the purpose of these settings available in this thread.  No matter what I played with I could not beat the 6 minute timeout.

Solution???

For one last throw of the dice, in order to try an identify any hidden configuration parameters, I resorted to another Sysinternals tool; Strings.  This tool dumps ANSI and UNICODE strings that it finds to stdout.  I redirected the output of the strings command to a text file for analysis.

strings.exe c:\windows\system32\tssdis.exe > tssdis.txt

I then opened this file in Notepad++ (a fantastic FOSS txt and code editor) and searched for the word ‘timeout’ (just a guess!).

image

Hmmm…

That ConnectionRedirectTimeout looks pretty useful.  I then made an educated guess that this was a registry parameter and that it belonged with the other registry parameters where I had previously been looking.  I added it as a DWORD value and assumed (again) that the data was the number of seconds.

image

I have now had a session open at the login screen, through the connection broker for over an hour!

To be honest, I am not sure that I have the units completely correct, as it’s been going for 1 hour 15 minutes nearly.  Still, I am pretty pleased with the result.

---UPDATE---

There seems to be a factor of 1.5 in the value entered in the registry key and the actual number of seconds before the session is disconnected.  After further testing we have held the session open for over three hours, with the hope of reaching ten (the opening hours of the library).

Thanks to Mark Russinovich and Sysinternals for the amazing tools, without which none of this would have been possible.

Smile

No comments:

Post a Comment