This will be a multi-part series on implementing thin clients (or thick clients) with a kiosk mode connecting to an Remote Desktop Services (RDS) farm with Single Sign On (SSO). I hope to help consolidate 12+ hours of research, testing and configuration changes over the past few weeks, with most of that being this week as we began finalizing our implementation plan for 45 new thin clients. I hope this is helpful to someone who may be thinking about a similar project, or maybe implement items learned here for something completely different. I've spent quite a bit of time trying to find the solution to this problem for our thin client implementation, and only after several weeks of trial and error was I able to piece together multiple bits of knowledge to accomplish my goal.
Project: Deploying 45 new thin clients to two of our facilities.
Deliverables: Half of these would need to be in a "kiosk" mode, while the other half would need to have access to a local browser (IE), but nothing else. All of these thin clients would have Windows Embedded Standard 7 (WES) and we'd be connecting to a Microsoft Remote Desktop Server (formerly Terminal Server).
I have been comparing Wyse and HP since they both have solid products, and I was looking for my long term solution for my environment. I wanted something that could allow remote management and updates without having to physically touch each one. Both manufacturers offer a Device Manager application which allows this functionality. Both have minor differences but use the same basic technologies and provide basically the same functionality (at least for what I needed).
In my discussions with the sales reps, I wanted to come up with a way to provide this kiosk type of functionality with an RDP session. Ultimately, the session must resume if disconnected. It also must allow users to have a Single Sign On experience to our Remote Desktop Services farm.
HP provides a "Connection Manager" application which allows you to create RDP, Citrix, and VMWare sessions that will automatically launch if someone closes that session. This is a really nice feature, but it does have some limitations, which I'll get to later. Dell does not offer that type of application, but their engineers had published some ways to hijack the Windows shell to create this same scenario for a Citrix environment. Armed with this documentation, I started looking at ways to convert this to an RDP connection.
Challenges: - Persistent RDP connection to Windows 2008 R2 RDS Session Host (connection must reopen automatically if user closes the connection) - Single Sign-On for RDS (Terminal Server) users. Our users will float between stations and need to be able to resume their previous session. This is a must for us to be successful in implementation. - Single Sign On must be true SSO - without a proper configuration (as I learned the hard way), multiple RDS servers with a Connection Broker will let you resume your session, but you may get multiple login prompts.
Environment: - Windows Server 2008 R2 Connection Broker - 2x Windows Server 2008 R2 Remote Desktop Services Session Hosts (formerly called simply 'Terminal Servers') configured to a farm. - 60 total Windows Embedded Standard clients with the future expansion to introduce existing Windows 7 Professional clients into the RDS environment. - Single 'kiosk' user (already configured on thin clients) with autologon enabled.
During my research, I came across several different posts on various sites that helped get me to my final solution. I'll share those below, as those folks helped me through this arduous task and putting the pieces together is all I can claim as my own.
First, a post on Spiceworks' forum provided the "persistent" part of the RDP connection. Specifically, "Dustin M" posted this nugget:
i have been experimenting with this as well. in my case, it was statically map a PC to a virtual pc, so i created an RDP file on the thinclient to point to the virtual instance.
then i set the pc to logon automatically as a local user, and changed the shell value in:
the batch file contains:
echo off CLS :start echo DO NOT CLOSE THIS WINDOW. start /wait c:\windows\system32\mstsc.exe c:\connect.rdp goto start
so as long as the PC turns on, it automatically connects to the RDP session.
The only issue with this particular solution is that there's a command prompt window that someone may feel like they want to close, even though it says "DO NOT CLOSE THIS WINDOW." But it was definitely worth a shot. I added that to my string for the shell, and it worked! Sort of. On WES7 it only worked on the Admin user, and I'm fairly certain it was because when I was loading the registry hive for the 'kiosk' user, something was locked down (from the manufacturer's image) on their account that prevented them from accessing the batch file I had created.
As I continued looking through the registry to figure out what I was missing, I noticed the following string in another key:
The .bat file was simply a batch command to create temp folders on the RAM drive for the thin client, but that "hidewin" made me curious.
Turns out HideWin is awesome. Briefly, it hides windows of running applications from the UI.
I adjusted my string for the shell, and it worked! Batch file window was hidden, and RDP connection worked as promised - but again, only on the Admin user. More research led me to something that I've somehow overlooked in Group Policy for years now - "Custom User Interface."
Our friends at Microsoft offer a "Custom User Interface" that can be deployed via Group Policy - including local Group Policy. Simply open GPEDIT.MSC, target to your 'kiosk' user, and navigate to User Configuration -> Administrative Templates -> System -> Custom User Interface (http://bit.ly/Ae24Dt). This, I found, handles the hidewin c:\connect-rdp.bat command perfectly! So now, I have a batch file that opens an RDP connection (and re-opens that connection should a user close it), and something hiding that command prompt window. The beauty of the GPO solution is now my Administrator user has a normal Windows shell, and doesn't need to have anything special done when I need to log in for administration purposes in the future.
That's it for the configuring a kiosk mode to use an RDP connection. Check out part two to read about SSO for the Remote Desktop Services environment. Later in this series we'll look at getting the RDP file configured properly for this kiosk we just built.