View RSS Feed

TheScarfedOne

Remote Desktop for Thin Client… Part 2!

Rating: 2 votes, 5.00 average.
by , 30th December 2011 at 04:31 PM (30803 Views)
Introduction
This article is a continuation, and update on the changes made since the original article published earlier in the year.

A bit of background to start with… in Summer 2011, I started a big modernisation project at the Academy I took over at. When I started, we were still on Windows XP across the desktops. To take us to Windows 7 presented a problem – the specs of some machines prevented it. I had a significant number of Celeron 1.6’s and 1.9’s. Although I tested Windows 7 on these successfully, the performance once loaded with software was poor. Rethink time.

The Client End
Following some early work with Microsoft – we got access to Windows Thin PC (Windows 7 Lite). This was perfect for our Celerons – and gave them a new lease of life. Being based on Windows 7, it didn’t take much to have these deployed via System Centre Config Manager.

I also needed a new solution for the Admin machines – which I had just stolen to refresh an IT suite. Here – we used a Wyse terminal solution based on Linux.

The Server End
The solution… a Remote Desktop environment. This was built from the same Server platform as I used for the rest of my new network. There will be another post on the new network architecture in full. It was summarised in an article here, and more to be published over on the Microsoft Schools Blog (link to follow). This would be the “actual machine” that the users of the Windows Thin PC and Wyse terminals would see.

How is it laid out then? We start with our main HyperV Host server (known as HV3). This contains 4 Windows Server 2008 R2 installs. The virtual machines were stored on my SAN, meaing I could user Clustering. The next step was configuring them to be Remote Desktop Session Hosts, done by adding the Remote Desktop Role from the wizard, and choosing the role service Session Host.

http://technet.microsoft.com/en-us/l...39(WS.10).aspx
http://technet.microsoft.com/en-us/l...34(WS.10).aspx

Then, I added that HyperV server to the HyperV cluster – which was made up of the other two main HyperV servers for the system (see separate article). This would mean that in case I lost one of the HyperV Cluster Servers, the individual virtual machines could move between the Cluster Servers. The virtual machines were setup to use the HV3 as their preferred server, that way they would move back there if it went offline and came back – and to prevent them moving to the other HVs to often.


On its own, this doesn’t give me the Remote Desktop environment. What I wanted is a Pool, so that I can use one name – and the system will work out which of the Session Host servers can handle the load. To do this, I need a Connection Broker. Again, there is a great guide to setting this up here – so I wont repeat it. Essentially – as per the Session Hosts – you choose the service role Connection Broker. Then you add the Session Host servers to the “farm”. You also need a Web Access server – which is incredibly handy, when you think about the VLE needs of a School. Nothing speaks true “anywhere, anytime” like being able to login to Remote Desktop and get exactly the same experience and programs at home as you do at School.
More great links for this here....

http://technet.microsoft.com/en-us/l...62(WS.10).aspx
http://technet.microsoft.com/en-us/l...48(WS.10).aspx
http://aaronwalrath.wordpress.com/20...ection-broker/
http://www.techotopia.com/index.php/...nection_Broker

Connecting the two
So…that was the core of the Remote Desktop system setup. Next – how to get the clients to connect to it. Well, the Session Hosts were called Site-RDSH, and the farm Site-RDS. Using a locally installed certificate authority, I created a signed Remote Desktop connection for Site-RDS. This had all the options for the sessions themselves in – such as the desktop background, animation, printer and client drive redirection etc.

You may remember from the first article (here) that the Windows Thin PC clients connected to the RDS system via a pre-determined single username. This username auto logged on to the Windows terminal, then triggered the RDS session prompting for the actual username to use the machine. This was OK to a point, except I found some problems mainly around printers. We use PaperCut – and all print jobs would show as my “communal” user rather than the actual user. Hmmm.

Next problem - logon stats were distorted, and it meant that there was always a connection to the system from these machines. Final problem, from the netbooks I had also setup for this system – they would always be triggering the remote desktop before the network was truly ready.
Rethink time.

What I did was change one of the settings available in Group Policy and on the Session Host servers to take the actual machine logon, and auto logon this username to the Remote Desktop. So – the Windows Thin PC machines would now present a standard Windows logon (and it looks exactly the same as the Windows 7 one) – which the user would enter their details. The same shell replacement as described in the first article is still used – so the RDP file is still triggered. The difference now – it is automatically logged in as the user. Technically, the user logs in twice (once to the physical machine, and once automatically to the RDS) – which you must account for if using any logon restrictors.

The next stages were the printers, which back to front I covered in this article (here)

Any questions or comments, please let me know. Site visits are also possible – I am based in the South West. You can follow me @TheScarfedOne on Twitter too.
Categories
Software

Comments

  1. SwedishChef's Avatar
    Hey pal, do you notice any issues with logging on twice, ie performance related to group policy processing on the thin pc's and then again on the rds session hosts? (or did you make use of any loopback processing)
  2. TheScarfedOne's Avatar
    Not really no. The only issue I sometimes see is a failed launch of the Rdp file resulting in a blank screen. Loopback is used to prevent the full user settings applying to the thin pc. It doesn't need to, as the Rdp session is what they actually use. I will be posting the actual group policy exports next week
  3. SwedishChef's Avatar
    Look forward to the exports then, I'm at this
    stage but had issues with the shell and how to log off cleanly.
  4. FN-GM's Avatar
    How do you prevent the connection bar appearing for those few seconds even if you have set it to not show? Also there is a box that shows saying connecting and the user has the option to cancel this. How did you deal with that?

    Thanks
  5. FN-GM's Avatar
    Hi, Just found this might be handy for people who are doing this type of project: ThinWin | Free software downloads at SourceForge.net
  6. TheScarfedOne's Avatar
    It always appears for the first few seconds (the bar that is), and the connection dialog disappears so quickly that I had never thought about removing it. Im not sure that you can - but Ill ask the RDP team...
  7. cyr0n_k0r's Avatar
    I'd like to hear how you handle this kind of setup for mobile workstations. Teachers and students that would take a laptop home.
    Also, what if they don't have an internet connection at home. How would they still be able to work at home with Word, Excel, etc.
  8. x_faz's Avatar
    Hi Excellent post.

    Can you please post a link to download your new script that now allows for SSO instead of prompting users for their username and password.
    Thanks

Trackbacks

Total Trackbacks 0
Trackback URL: