0

I'm new to the Thin Client / VDI concept but it seems like my environment might be a good candidate for converting. Currently we run Windows 7, so I would like to investigate a TS/VDI solution with minimal change to our typical business applications and infrastructure.

I'm not looking for specific hardware or software recommendations. I'm simply new to the idea and trying to learn more. I'm looking for the place to start, pointers to the underlying technologies and places to learn more about them, limitations and benefits from such deployments.

For reference, my environment currently consists of just over 60 desktop users.

5
  • 2
    You are going to have to add a lot more information that just "what do I need". It would depend on a lot of factors, including number of users, estimated server load, and, naturally, budget.
    – tombull89
    Feb 29, 2012 at 13:08
  • Are you looking for client-side infrastructure (thin-clients), or server-side infrastructure (VDI stuff)?
    – sysadmin1138
    Feb 29, 2012 at 13:18
  • 3
    Memory-intensive and Thin Client are not happy bedfellows. PC hardware is cheap. GPO management is easy. Make the right choice. Thin Clients will bite you in the ass later. Feb 29, 2012 at 14:10
  • @TomO'Connor Without having the slightest clue what he means by "memory intensive" it's a bit reckless to make such recommendations.
    – Chris S
    Feb 29, 2012 at 14:38
  • You are right that my question was very rough but I was in a hurry to reach a start for this research. Many thanks to Chris S for retyping my question in a more meaningful way and of course for his answer.
    – fotag
    Feb 29, 2012 at 15:48

1 Answer 1

6

First thing you'll need to decide is if you want VDI or Terminal Services. VDI runs a whole "machine" for each user. Typically these "machines" are actually VMs on a ESX or Hyper-V host, but other solutions exist, including ones where they're connected to rack-mount workstation blades. For Terminal Services you'll have multiple users connecting to Terminal Servers (multiple people logging into the same OS). And there are of course multiple variations, combinations, and exceptions to the aforementioned (this is just the vanilla basics).

#1 - Decision: Everyone has their own OS they login to, or multiple people share common servers.

At 60+ users you're going to want to cluster things. Thin clients will connect to some sort of load balancing, sometimes referred to as a connection broker. Decision #1 will heavily impact what sort of hardware you'll need. Also, what capabilities you want at the thin client end will impact what sort of thin clients you need. This can range from about 3 beefy terminal servers in a cluster configuration with 60+ thin clients, to a dozen more specialized server/workstation blades with 60+ slim clients. You'll probably want some sort of SAN environment, though this will depend on the specifics of the aforementioned.

#2 - Task: Derive software requirements from #1 + LoB Application Requirements

#3 - Task: Derive hardware requirements from #1 + #2 + Redundancy/Availability Requirements

You'll need all the standard network gear. Do pay attention to your switching fabric (you'll need plenty), total throughput (especially at the servers and core), redundancy (everyone is going to be very dependent on the network's availability), and all the other normal stuff. If you don't have the slightest clue how to size this, you'll have to do a bit of experimentation and extrapolate from that.

#4 - Task: Derive networking requirements from extrapolating test results.

Some of the more popular systems to help you in the right direction: VMWare View, Microsoft Server RDS, and Citrix XenDesktop

You'll also want some serious buy-in from every player in the situation (management and end-users particularly). Make sure they're on-board with the benefits and problems this system will enact. I can't stress "training" enough. Make sure the users are trained on the differences between a fat-client (which most people are used to) and a thin client (which most people are very much not used to). Don't forget support personnel, administrators, documentation (which will need some drastic updating), etc.

#5 - Key to Success: Serious buy-in from all key players. Training, training, training.

If this all seems a bit overwhelming, well I is a bit. There's a lot to know. It may be completely appropriate for you to admit you don't know enough about this sort of deployment and request training, or the opportunity to learn on the clock. I've gone both routes multiple times before. If you're employer is serious about your professional development and growth they should support you wanting to learn technologies that have a good chance of saving them thousands. Once you've got a general idea of what direction this sort of project should head, figure out what learning resources will work for you (reading books, toying with software on old computers, classroom training, etc) and talk it over with your boss. If this is really a project that your business may complete they should support reasonable allowances for learning before diving into the deep end.

#6 - Learning: I mean you: Read Books/Online, Classroom Training, etc

A word about security and management operations (configuration, maintenance, monitoring, backup/DR, and automation): apply them liberally. The more complicated your infrastructure the more efficient it can be. But efficiency demands automation, security, and maintenance. If you don't have a configuration management system in place, you'll want to look at one (though not required for 60+ people, it's going to make life much easier, especially if you're a one man shop). If you don't have operational monitoring (and alerting), you'll want to look at that too. You should revisit you backup and disaster recovery plan when making any major changes, and on a regular basis (like yearly). Security will become much more important as mistakes that are relatively innocuous on independent workstation can snowball into disasters in multi-tenant shared system. Automation is about the only way you'll keep your sanity if you're a one man shop; scripting helps, but the aforementioned configuration management and monitoring systems should help keep everything humming along without constant human intervention.

#7 Learning: Really an extension of #6, know Security, Configuration Management, Monitoring and Alerting, general Automation.

Apologies if this seems preachy, I got a little carried away and didn't have a fix on your base knowledge.

This sort of deployment is not to be taken lightly. A meticulous plan should be put together and everything triple checked. If you have doubts, call in a local professional who has experience.

2
  • what a great answer! what about zero client?
    – KevinOelen
    Mar 2, 2012 at 7:10
  • I tend to shy away from zero clients still; support is pretty poor all around even with some large manufacturer jumping in. I expect new applications wouldn't have any trouble with those configurations, but would expect problems from legacy apps of just about any kind.
    – Chris S
    Mar 2, 2012 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .