Thin Clients for RDS

[azureusnation]

So... I have a major awesome project that I am going to be implementing in the near future. Lets just say this cluster will have 192 cores over 3 nodes

 

I've been looking at ThinStation but I wasn't it installed on each machines hard drive and not have to rely on PXE/TFTP server. OpenThinClient is also out. What solutions have you guys come up with to turn old computers to thin clients... Bare in ind I have 450 computers I would need to convert so I need something that is extremely automated. By that I mean just really easy to run around all machines over summer and use a pendrive to install.

 

Thanks

 

Ashley

[FN-GM]

I have seen this solution work really well.

 

1. Setup https://guacamole.apache.org/ - it is a HTML 5 client for RDS. However Microsoft have one now so might we worth looking at that but I don't think the MS solution will automatically start the session.

2. Buy or convert devices to Chromebooks / Chrome desktop. Set them in kiosk mode to launch the above - it will present the login for the HTML 5 client and auto launch the RDS session when they login. It will be full screen and the kids won't be able to get into other parts of the browser. You can convert existing devices with Neverware cloudready.

 

They are fully manageable and any changes can be pushed out ages. The clients will need little software maintenance.

Edited May 16, 2018 by FN-GM

[PotNoodleTech]

Make sure you do a lot of testing first before you roll out 450. I suggest doing an IT suite and seeing how well it works. You may find, like most thin client deployments that it's not actually as darned amazingly good as you first though it to be!

 

I've gone entirely back to fat clients now.

[box_l]

https://ryanmangansitblog.com/2013/0...c-thin-client/

 

Try this ^

 

We have repurposed over 90 atom netbooks this way.

It may require a couple of tweaks for your environment

But it works really well.

[azureusnation]

Thank you all. I wanted to try and stay away from windows at the client end as its just tedious, not as bad as macs though. I wanted just something simple that no one in the community seems to have made. A PXE bootable linux distro that will install on to the client, prompts fora host name and the RDS server/broker and away you go.

 

I'm dabbling in ubuntu trying to get that to PXE boot the desktop version but this is a can of worms... why cant anything free be simple...

 

Please keep the ideas coming though

 

Thanks

 

Ashley

[PotNoodleTech]

Well gotta admit Rolling out windows 7 or above with WDS/MDT and then all settings policies via group policy is not really tedious at all. They just work day in day out most of the time.

 

Trying to fault find why performance has nosedived on your RDP farm and it turns out to be a new version of flash or an MS patch - now that's tedious.

 

Any problems with fat clients tend to only affect one client and one user. Problems with RDP farms tend to affect tens or hundreds of clients/users and is a lot more stressful.

 

Just saying be careful before you magic the whole school into thin clients, there are many schools who have gone back to fat clients after being on the thick end of trying to make thin clients perform with ever varying user requirements and ever varying software.

 

[FN-GM]

Well gotta admit Rolling out windows 7 or above with WDS/MDT and then all settings policies via group policy is not really tedious at all. They just work day in day out most of the time.

 

With less that 2 years support left I would be looking at building new solutions that are not using Windows 7.

[Smokebomb]

We used Celeron/Pentium NUCs with Windows 10 LTSC 1607 and a freebie product called ThinKiosk. PCs autologon and launch ThinKiosk which loads up our RD web login page. You can get it to bypass Explorer all together, although we recently re-enabled that to facilitate Bitlocker to Go.

 

Working well, we use our existing ConfigMgr management for deployment and lock everything down with Group Policy. You can use this type of solution on old PCs and just convert them. If you then ever decided to have a VDI collection instead of session-host you don’t need a VDA license for the endpoint.

[Smokebomb]

Also, in regards to your RDS infrastructure I’ll pass on our experience over the last 18 month. May help with your setup (although every environment is different).

 

We started off with several RDS host VMs with 8 vCPU and 48GB RAM, targeting about 40 users a box. As the rollout has progressed our experience is that you are better off with more VMs on the host to spread the load rather than having Uber RDS hosts. For example, we have around 200 concurrent staff users logged in at once (we have approaching 400 thin client endpoints). The hosts specced as above could get bogged down at between 30-40 users.

 

Sweet spot for us is 15-20 users per VM. We’ve dropped vCPU to 6 per VM and my SysAdmin (who’s a ConfigMgr genius guru - you know who you are if you’re reading this!) has built us a Task Sequence for deploying new 2016 RDS hosts. We now have 14 in the pool which gives us loads of room for growth and allows us to take hosts out for maintenance without affecting users.

[azureusnation]

Also, in regards to your RDS infrastructure I’ll pass on our experience over the last 18 month. May help with your setup (although every environment is different).

 

We started off with several RDS host VMs with 8 vCPU and 48GB RAM, targeting about 40 users a box. As the rollout has progressed our experience is that you are better off with more VMs on the host to spread the load rather than having Uber RDS hosts. For example, we have around 200 concurrent staff users logged in at once (we have approaching 400 thin client endpoints). The hosts specced as above could get bogged down at between 30-40 users.

 

Sweet spot for us is 15-20 users per VM. We’ve dropped vCPU to 6 per VM and my SysAdmin (who’s a ConfigMgr genius guru - you know who you are if you’re reading this!) has built us a Task Sequence for deploying new 2016 RDS hosts. We now have 14 in the pool which gives us loads of room for growth and allows us to take hosts out for maintenance without affecting users.

 

Interesting. I've been working with Broadberry on the hardware and they are saying to just have one VM per host. Each host has 64 cores/128 threads with AMD's EPYC. we are also putting infrastructure vms like print servers and other bits as well. One thing I do wonder though @Smokebomb is we are having the remote connector licenses so are the remote licenseds per vm or per host? this could be an issue with costings I have proposed if it is per vm...

[Smokebomb]

Interesting. I've been working with Broadberry on the hardware and they are saying to just have one VM per host. Each host has 64 cores/128 threads with AMD's EPYC. we are also putting infrastructure vms like print servers and other bits as well. One thing I do wonder though @Smokebomb is we are having the remote connector licenses so are the remote licenseds per vm or per host? this could be an issue with costings I have proposed if it is per vm...

 

I would imagine the licenses are per VM, but speak to your Microsoft reseller for clarification. You should be fine putting a few infrastructure VMs in your cluster, we do that too.

 

We’ve been doing desktop virtualisation since 2011, starting with VMware Horizon View, and if you have fast storage and lots of RAM your bottleneck will always be CPU. We went with AMD for the View VDI solution with 64 core boxes but found the performance to be poor, Xeon boxes were a lot better even with fewer cores. Granted this was a while ago so I’m sure AMD have improved.

 

IE and Chrome processes can eat CPU, and don’t even think about putting something like the Impero classroom management app on there. It can eat 5-15% of CPU per user session.

 

There is nothing wrong with Broadberry’s proposed model, but you risk the all “eggs in one basket“ scenario - over the last few months we’ve had various issues with our RDS farm caused by Microsoft bugs. One issue was caused by a botched cumulative update which would prevent users logging on after a random period of time, we’ve also had “black screen of death” at login which turned out to be a bug in Microsoft Firewall creating over 100,000 firewall rules on each host (acknowledged by Microsoft, no fix yet and bodge fixed by us with a nightly powershell script), we also have intermittent issues with Start Menu not working (still waiting on a fix from Microsoft on that one)

 

So as you can see, if you come across an issue like this that Microsoft introduce in a cumulative update you could potentially have a third or two thirds of your provision down by no fault of your own. Spreading the load over more VMs means you can easily isolate and contain issues that arise. Something to think about.

[Mic_Impero]

Hi all,

I can't add a lot to this but wanted to drop a note in that we're working with a couple of large RDS environments at the moment to reduce our footprint in the kind of deployment, with some great success, and continue to work with others to try and gain as much optimisation across various types of RDS environments covering as many variations as possible.

 

Mic @ Impero

[AJWhite1970]

On a similar theme there is also Thinstuff VS which works really well as a RDS server for Windows

 

http://www.thinstuff.com/products/xpvs-server/