/ BLOG / Automagically configuring Wyse thin clients running "blazer"
It’s probably no secret to some people who read this that I do a fair bit of work with terminal servers and thin clients (dumb, low power machines that connect to a terminal or citrix server). However, most deployments I’ve been involved with at work at relatively small, our largest of which has recently gone up to a load balanced set of 5 Windows Terminal Servers, a few weekends ago.
In the past we’ve always manually configured the thin clients, as they’ve always been rolled out over a long period, typically in very small quanities (no more than one or two); slowly replacing aging computers. However, this project is effectively a new cluster of terminal servers (replacing some aging hardware it was decided that it would be a good opportunity to do things properly). Personally I didn’t really like the prospect of going to each one in the building and manually fixing the config, or using a CNAME in the local DNS, as many probably need firmware updating and altering in other ways to bring them inline with the rest.
In the past I knew that the Wyse S10’s (which is the model we’ve mostly got deployed with this client) were administratively configurable (by this I mean en-mass from a single point, Ã¡ la group policy), but I had never really gone hunting for some decent docs until three-four weeks ago.
I stumbled across freewysemonkeys.com, an absolute gold mine of documentation for anything Wyse thin client related without having to wade through all the other “user guides” from Wyse themselves. Whilst the docs weren’t always 100% accurate for our model they did give me enough of a leg up to get everything we needed working perfectly on all but the oldest S10’s (unfortunately getting a firmware update from Wyse currently requires a support contract, according to their site).
A few days prior to this project I had tested it on another, much smaller client, as I was on-site virtualising part of their systems, and it worked awesomely well. Based on the configuration we will now beable to tell if a thin client has a proper network connection by simply asking what colour the background of the thin client is, setup various remote connections, wallpapers and icons, automatically reflash the firmware if there’s a newer version available, etc. all of which is picked from some basic DHCP scope options and a FTP server.
There are other solutions for the various thin client’s out there, so if you’re still manually configuring stuff by hand before shipping out to a customer, I recommend investigating for your chosen make and model, no matter how small your deployment is. It’ll make your life as an administrator, and the life of your users, much easier.