Remember the late 90's, when it was going to be a thin client world? The only doubt was whether we'd be using Citrix WinFrame or Microsoft Terminal Server, right? Or how about the IBM 3270 green screen? A lot of money was made in terminal emulation software so those things could run on your fat clients.

Any minute now, if they haven't already, someone will come to you and ask about getting rid of all your desktops and laptops. After all, Vista bombed, 7 and OSX are still awfully scary, and XP is unfashionably old. Why not switch to something like VDI?

Well, I'm going to assume that if you're reading this, your job is pretty dependent on thin clients not getting anywhere, so let's talk about how to fight back for the fat client... with logic, and politics.

The Logical Discussion: VDI is actually increasing complexity, not reducing it. Unless you replace all your workstations with thin clients, you're now maintaining two images per user instead of one. Everyone hopes that  the image in the VMWare cloud will be a single image shared by all  users; if that were true, why do products that solve the problem exist? Here's a couple of excellent articles. Why are there so  many vendors at VMWorld, selling solutions to all the problems that  crop up? Where's the integrated management tool that takes care of all these solutions? The answer is, it doesn't exist... and if it did exist, it would cost MORE THAN your existing systems management solution.

More, you ask? Why? Simple. It would cost more because it would be doing all the same things, but it must implement new ways of doing them; partially for technical reasons inherent in virtualized platforms, and partially for legal reasons; LANDesk has certainly patented important parts of its solution, and you'd better believe our competitors have as well. So if you're getting cheaper quotes, it means you're being sold a loss leader... and caveat emptor.

You'll recognize that as the classic LANDesk Yet Another Console argument, and it must be presented carefully. Here's what's really happening here:

The Political Discussion: The IT Department is  an 80/20 space just like everything else; 20 percent of the resources  go to 80 percent of the problem (desktops), and 80 percent of the  resources go to 20 percent of the problem (data center). When they get  budget pressure, the data center guys see their slice of pie shrinking. Some of them will just defend their own stuff, but the smart ones will make a power grab for the  remaining 20 percent of the resources -- your slice of pie. In order to defend yourself, you must find their weak point. Luckily, it's not hard... They don't understand what  happens in the 80 percent of the problem, and they think that desktop  management is an easy problem to solve. They're presenting VDI and  thin clients to the CIO as a weekend project, and that's how you can defend your budget. Here's some points to focus on:

Your job is to make the CIO realize that the data center people don't know what they're talking about when it comes to desktop management. This is akin to making Daddy realize that his favorite kid's cheating  on tests.

Data entry people will do okay with thin clients, but knowledge workers will not put up with it because it's designed for thin clients  on a fast pipe. Hello? Ask your Dell or Lenovo rep how many laptops  they sell these days versus desktops. If the end users are demanding  mobility and flexibility, but the data center guys are demanding cloud  computing, you've got an opportunity to present VDI as a more  expensive, more complex offering than the status quo.

If they're still listening to you at this point, the coup de grace  is to talk hardware. Sure, those thin client workstation replacement's  only $300 a pop... But the ESX servers and the SAN to back them is  some very pricy stuff. Ask how many clients per server they're  thinking of, and tell them they're getting snowed if it's greater than 20.

This is all so much spitting in the wind if you're too late; the only  way to really stave off a pendulum swing is to be there putting sand in the gears before  it actually start to move. Otherwise, you'll be left saying "I told you so".

LANDesk is like Perl... There's More Than One Way To Do It, and consequently it's the power tool of choice for many intractable problems. Sometimes, maybe even a lot of the time, an out-of-the-box solution is required. Here's some thoughts to help guide your choice of solution:

1) Is the solution elegant?

• Many computer professionals are familiar with this concept, but just as many confuse it with "easy". An elegant solution is one that leverages the infrastructure, is economical with resources, and simple in design. Meeting those criteria may well mean spending days on the design or writing a thousand lines of code, but it's still preferable to build elegant solutions to easy solutions.

• An elegant solution is a lot more likely to be a long-term solution. It's less likely to be broken by later changes to the environment, and it's easier to understand.

2) Is the solution self-documenting?

• Let's say we want to extend the inventory on all devices, and we're doing the initial installation of LANDesk. We'll need to modify ldscnhlp.ini and include a binary on every agent. Do we:

• Use a software distribution policy? This means we're putting the files into a package and distributing it via required once policy to all machines. The solution is self-documenting because it's in the scheduled task, but it's also easy to accidentally break by deleting the task or query or package.

• Use a custom vulnerability? This means we're putting more effort into the initial distribution, but we're also producing a self-documenting process that's easily turned on and off. It's also simple to audit what's happened, at a high level in the Security & Patch Manager or at a low level via vulscan.log.

• Modify the agent installation process? This can be done via Advanced Edit of the agent or ORCA editing of the Agent MSI or bundling in another packaging tool, or probably a few other ways. Some of them are self-documenting, others aren't... but in no way is this an elegant or long-term solution.

3) Is the solution long-term?

• What happens to the solution when LDMS gets patched or upgraded? An automated agent rebuild will wipe out changes to the agent, and it'll be quite a while before anyone realizes what happened.

• Will you remember how it worked next month? How about next year? Will it even be you who needs to remember? The average American worker changes jobs every five years. The easy solution needs to be legible to someone else, and in LANDesk terms that means it needs to be visible in the console.

Breaking those guidelines is certainly possible, and at times necessary, but realize that it's just making things a little worse if you have to go there.