TheScarfedOne

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.