I'm looking to migrate about 20 in-house researchers from their current XP workstations to thin-clients which connect to a VM running within our LAN. I'm planning on using HP thin-clients which use a linux based client os and the backend would be a dell rack server running Server 2008 Std. with Hyper-V. After talking to our software guy it seems as though I would have to purchase RDS cals for our users and VECD licenses on the client side. We currently have XP licenses for everyone and I'd hate to just throw those away. Can I not just set up 20 XP virtual machines (using our existing XP licenses) or is using RDS that much better? This licensing model is new to me so any and all help is greatly appreciated.
SnapOverflow
This entirely depends on what you're doing with your users. 20 VM's is going to be HARD on the server. A lot of memory, a lot of disk use, a lot of network use...I'd not try doing that.
Terminal services are something we used to use. We could support on decent hardware about 15 to 20 sessions at a time. Problems...multimedia was crap, Office needs special consideration when installing on terminal services, and certain applications would spike the processor so that one user could hog the server and bog everyone down. This can be mitigated through resource provisioning, but still it's a management concern.
We also had cases that were annoying to track down...we had a user that left a web browser open to a weather map loop, animated. There was some memory leak where that session BALLOONED until the server started thrashing. Users were disconnecting and reconnecting, sessions were abandoned with apps running, making the situation worse.
When moving to a thin client solution you need to have some way of increasing availability. We had systems set up with Windows IP clustering, but that still had it's problems. And people would corrupt profiles because they don't understand that they're using a REMOTE system. Turning off their computer wasn't rebooting it. Multiple logins on different servers didn't help with this. And worse, we had one server that started rebooting with no rhyme or reason. Turned out someone was trying to run an intensive app that triggered a but in Windows that in turn rebooted the system and booted a dozen users off.
You need to figure out if the applications are going to be compatible with this model of usage. Terminal services can do some weird things. Executables made from Director (a lot of shovelware comes like this for schools) ran like molasses on our terminals. Special niche software didn't like terminal services sometimes.
For resources, you should definitely go terminal services. I think 20 VM's are hard unless you have multiple servers and have vmotion/vsphere/etc., plus you'd be essentially remodeling your environment to have an in-company cloud of sorts. I don't see the benefits to doing that over just having local desktops since you're essentially replicating your user desktops on a few big servers, minus the benefits of having local hardware to isolate issues and giving yourself a central point of failure. To have a really effective VM solution you need to invest quite a bit in the infrastructure so your users have enough reliability and availability to get their work done.
Terminal services aren't a panacea either and you really need to test your applications to see if you're going to have a benefit. Also keep in mind that this is going to really push your network more.
Terminal services may have improved since we used them many years ago. But if it tells you anything, we now use regular desktop machines for our users and use Deep Freeze to keep them intact and malware-free, especially after having to keep making "exceptions" for special software until it was useless to have terminal servers as people were more and more needing special case exceptions.
One extra thing to look out for on top of Bart's answer. It may not be possible for you to use your XP licenses in the VM. Some of these OEM copies of XP are locked onto specific vendor hardware and you may have some problems activating the VM. This problem won't exist with full retail versions of XP.