Note: this became kind of a long answer, so I tried to structure it so you could just read the bold text and still come away with the most important points.
It's about cost. It's always about cost.
As we go through here, remember that these numbers change all the time, and that it's been about two years since I looked at any of this. The cost calculation methodology/concerns and ratios at least tend to hold up over time, but pricing you see for any part of this at any given moment (especially software licensing) might be way off. Please feel free to challenge me in the comments for any pricing you feel is especially suspect.
Consider $700 workstations last 4 years, or $175/yr. For ease, we'll add $25 in average support costs, to get to $200/yr each for traditional desktops. Yes, there are keyboards, monitors, etc to worry about as well, but you have those same accessories with terminal services (thin clients), so for these purposes we can just ignore all of that.
For thin clients, I see products for as little as $50. However, whenever I look closer these cheaper devices need Multipoint server or only support linux desktops, which limits your deployment scope. Looking around more, any thin client device worth using still costs at least $220 or so, if not more. It's important to remember, though, that a big part of the thin-client model is to get a lot more life out of a thin client with lower support costs. Assuming 10 years (no moving parts so the hardware can last much longer, but tends to become obsolete before it wears out) and now estimating only $10/yr in support on average, that's only $32/year. I also see people re-purpose old desktops to PXE boot a thin client OS, but in this case you lose some of the life and support advantages and add new software licensing, so I don't see that plan as really any cheaper.
So far we're way ahead on thin clients. The problem is that we haven't provisioned any server resources yet. When I last looked at this (which was a while ago), I figured that $10K in server hardware could last six years and handle about 25 clients. That adds another $67 per year per device to the thin client side. I can also get the number of supported clients way up by adding special terminal services graphics cards to the server, but when I last looked the cost of the specialty cards vs the number of added clients was a wash. Also, the main advantage here is in supporting fewer servers, and we were too small for that to be a real advantage. You can still support more devices without the cards, but sometimes the responsiveness wasn't good.
Now we have to look at OS and licensing. Assuming you're pushing Windows desktops, the basic Windows Server licenses won't cut it. You need additional RDS licensing from Microsoft to make this work. Beyond that, most of the successful deployments I've seen have relied on a third party management tool of some kind (Citrix comes to mind, but they're not the only player). This is where it gets really tricky, because licensing costs can vary wildly from customer to customer. Suffice it to say that my rule of thumb tends to be that the software vendors want for your total software costs to come in roughly equal to your hardware costs. I know that's a HUGE hand-wave on this, but again: this area can vary so much I don't know any better way to get a good estimate (If there's a sysadmin out there with better numbers that can comment on this aspect, I'd love to see it in the comments). In this case, my "hardware costs" number does include the thin client hardware, but does not include the $10/yr estimated per-device support costs, meaning we need to add another $89/yr per device to the thin client costs.
Add all that up, and our total thin client cost estimates now end up at $188 per device per year. Hey, that's less than the traditional desktop model! It's not a lot less (only about 6% by this estimate), but it's a win when you spread it out to a lot of devices.
One thing to keep in mind here is I left of lot of room for flexibility in the software licensing. Larger organizations — the kind that have a LOT of vanilla desktops ripe for RDS conversion — can also often have a lot of leverage negotiating software pricing, such that truly large enterprises can make this a slam dunk on pricing. But that's not most of us. Most of us should expect something like that modest 6% savings.
Now, into the meat of your question. To my mind, there are still challenges with this model that must be weighed against the modest cost savings.
The first is that you need to sell it to your users and management. Not everyone is going to just quietly give up their desktop... not that they necessarily get a say in the issue, but enough discontent users can make life difficult.
Additionally, it will mean a significant IT effort to make the transition, and that first initial push to the new model can mean getting expensive licensing plus a LOT of new server hardware up front that busts your budget for the first year. Remember, a lot of savings for the thin client model aren't realized until you're able to skip what would have been that first round of PC refreshes. Until then, you're operating at a cost deficit vs traditional desktops.
A third challenge is that it takes a different skill set to support this model than it does to support traditional desktops. You may need to upgrade some of your support techs to server administrators. Generally I see this as a good thing. I generally prefer to spend the same dollars on people vs equipment to get the same result when I can. It's just worth noting that the transition can be difficult.
Another thing to consider is application licensing. This is a bit of a mess right now. On one hand, some applications that used to require expensive per seat licenses may suddenly only need a handful of seats. Other applications may require more expensive RDS licenses, or even lock out of RDS completely. The only way to know is to review every application you need to support. Every new application you want to bring in must be vetted for RDS suitability.
Finally — this to my mind is what really gets you — I've found that the percentage of users that need something special is often a LOT higher than you think it is up front. Engineers, artists, executives, anyone using a laptop... all of them often need a traditional client (or think they need one with enough clout to get it), and that's just the start. When it comes down to it, you have to support both models, at least to some extent.
But it doesn't have to be just about cost. Here's where I believe things get really interesting: I also want to consider the new things a shiny new RDS server infrastructure allows you to do.
The first example is you're suddenly positioned to easily support remote workers. This includes both full-time off-site staff or sales people, as well as provide access for staff that are normally on-site, but may just need to get some work done from a training conference that one day. RDS is better than a VPN for remote access, because workers can use their own device while still getting the benefits of having all their actions take place on a domain-joined, secured operating system that lives on the local network.
And let's talk more about your remote workers. Do they ever handle sensitive data? Have you ever lost a laptop? A good RDS deployment, where your remote workers use their laptop to connect to a virtual desktop hosted on your internal systems, means that a lost laptop never has to mean leaking data. While I'm here, it's also worth considering what kind of laptops you need to deploy now. Could a $200 chromebook with RDS access now do that same job as a $900 enterprise laptop? How would that feed into your risk costs (not just loss insurance/warranty for the laptop, but liability insurance for the data loss)? For that matter, you should consider whether a $200 chromebook can give you the same (or better, because mobility) results as a $220 thin client (hint: it can't. Those pesky support and life-cycle costs again. But it can be worth doing anyway because of the increased worker mobility).
One other thing to consider is availability. With thin clients, you're putting a lot of eggs in one basket (your servers), meaning you should never do a single-server RDS deployment (I suggest at least three per site. Get smaller servers for sites smaller than 75 users). With at least two servers you're suddenly a lot more resistant to failing machines, with fewer people ever completely down from a bad computer. Yes, a server can go down, but good planning will allow your users to stay in business, even through a server failure. Sure, some users may need to reset and log back in, but the service will still be up, ready, and waiting for them.
Another idea on new capabilities is to imagine a thin client vendor in the future offering a $40 tablet docking station, where connecting a tablet triggers the thin client kiosk app and mirrors it to a regular keyboard/mouse/display. You can get pretty nice tablets for $120 now. Add the cost of the docking station, and suddenly you're able to issue tablets to your users with no additional initial hardware investment. You do still need to consider life-cycle and support costs, so this is still far from cheap, but if you're thinking about a tablet initiative anyway, this could be more of a way to lower your thin client costs down the road and ultimately manage fewer devices rather than more.
Those are just a few examples of ways to get additional value of the change to an RDS-based workstation environment.
As context for all of this, I currently manage the desktop fleet at a small college. We don't use RDS here at all. This is in spite of the all the good things I've said about RDS, and that I'm in Higher Ed, where we have computer labs full of simple, stock machines that would be perfect for an RDS makeover.
Why not? Because I only compared to the traditional desktop funding model. Remember there's only a very narrow cost advantage here. If you're able to stretch things much on the desktop side at all, that model can suddenly be cheaper again. And as much as I'd like to use an RDS deployment for things like virtual labs for online students, or delivering department/major-specific applications to students on their own devices in their rooms, cost is king here, and I just can't justify any extra expense, especially that first-year server and licensing investment.
