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".

ldms_client 2.4.9 hits the web today. This is a major revision, because it moves the inventory locations of several attributes, and it provides an optional ability to model data for those attributes. The affected inventory items are Battery, NetStat, Mapped Drives, and User Profile Size.

What does that mean? From the manual:

A database schema is the map of the database; it's how programs know where to read and write data from. LANDesk's database has an extremely clever trick available to it, which allows it to extend that map on the fly. If you send it data that it doesn't know how to map, it will figure out what you wanted and make it happen. For instance, if you add "Foo"."Bar" = "Baz" to an inventory scan, it will reason that you must want to assign Baz to a value named Bar, which is under an object named Foo. So it takes the data, puts together a attribute relationship, and stores it all in the UNMODELEDDATA tables.

By default, much of the data that ldms_client provides is unmodeled... after all, if it were modeled that would mean that LDMS was already gathering it, and ldms_client wouldn't need to. If you just need ldms_client temporarily, this is fine. For example, if you're just trying to quickly ascertain license compliance or force Dell WoL into a known state, you probably don't want to make a permanent change to your database.

On the other hand, performance of unmodeled data is potentially very poor, especially as the number of nodes reporting it goes up. That means that if you're using some of ldms_client's features as a permanent part of your inventory, you'll want to model the data.

This is still optional because it's potentially risky, but the benefits are worth pursuing.

Thanks to some questions from Jim Hysell, I found a bug in ldms_core yesterday, which has been fixed in 3.6.4. The bug was in the listing of detected vulns and autofix vulns by severity, which are then added together to make the detected and autofix lines in the Vulnerabiltiy Statistics graph. Prior to 3.6.4, the number is only accurate if you haven't created overlapping scopes. Of course, since everything's covered by the default "All machines" scope, that effectively means that all scopes overlap at least little. This caused the vulns on the machines that are in overlap to be counted once per scope that the machine was in, which is probably not what anyone wants.

Net result: For some LDSS admins, upgrading to ldms_core 3.6.4 or greater will cause a precipitous drop in the number of detected and autofix vulnerabilities. The new number is more accurate than the older one.

So, in figuring that out I also realized that I could delineate between vulns detected, and machines with vulns, which wasn't very clear in the text report. There's a big difference between "you've got six critical vulns in the environment" and "you've got six machines with critical vulns on them"... These values are now clarified:

Detected vulnerability counts by severity:
Critical - 68 vulnerabilities found on 8 machines.
High - 45 vulnerabilities found on 7 machines.
Low - 12 vulnerabilities found on 9 machines.
Medium - 48 vulnerabilities found on 10 machines.
N/A - 129 vulnerabilities found on 11 machines.
Service Pack - 10 vulnerabilities found on 3 machines.
Unknown - 11 vulnerabilities found on 9 machines.

Detected vulnerabilities set to autofix by severity:
Critical - 64 vulnerabilities found on 7 machines.
High - 40 vulnerabilities found on 5 machines.
Low - 4 vulnerabilities found on 4 machines.
Medium - 12 vulnerabilities found on 7 machines.
N/A - 47 vulnerabilities found on 7 machines.
Service Pack - 1 vulnerability found on 1 machine.
Unknown - 5 vulnerabilities found on 7 machines.

By the way, I've also posted ldms_core to google code, so anyone so inclined can use the source code more easily. I'll do the same for my other projects as time permits.

ldms_client has picked up a few new tricks, particularly for the Dell shops. Version 2.4.5 adds code to detect the system hardware, so that DCCU will not be run on non-Dell machines. This version also reports on the number of crashes a workstation has enjoyed over the last seven days, so you can get some early warning (or refute your user's claim that it's crashed a dozen times since Friday... see? only 11 crashes).

I'm also splitting Mac support back out of the main package, so that everyone doesn't have to download it. This is preparatory to removing Macintosh support altogether... I just don't like working on Macs, and I haven't updated ldms_client_mac since July of 2008. If anyone would like to take over this section of ldms_client or wants some help doing their own inventory extension, you know where to find me.

The ldms_client_core UI is getting unwieldy and will be using tabs in the near future. I'm also starting to toy with a wild-card-capable registry reader, which would allow for some of those recursive tricks like mounted PSTs and mapped network printers.

I just posted ldms_core 3.4.7, which integrates some of the feedback and discoveries of the last few weeks... thanks for all the help, folks. Debugging help and feature suggestions from LANDesk admins around the world are making this utility into a very useful tool indeed.

Here's a few notes about where it might (or might not) go next:

• Scheduled Tasks
•   
   
  •  
   
  • Check scheduled tasks and policies for RRD stats -- jobs without start times, jobs in success-level buckets, duplicated jobs...   
        
   
  •  
   
  • Delete ghost devices from scheduled tasks (stuck in active because they reported status). If they were from a query they should be deleted from the list, but if they were from a static targeting they should be moved to pending. http://community.landesk.com/support/message/17222#17222   
        
   
  •  
• Import   ldms_delete_users, auto-reassign to single user or delete objects, give the user an option to decide what should be done. Alternatively, rewrite ldms_delete_users as a standalone tool...
• NMAP as an XDD client add-on instead of a core-side piece... this implies some command-channel use and data-passing which are non-trivial, but entirely possible. On the plus side, it will also produce a much higher level of accuracy in OS fingerprinting.
• Email
•   
   
  •  
   
  • Be smart about hysteresis... maybe it could not send another email within a day unless the new email it wants to send is more urgent than the last email that it had to send? Users going from daily runs to hourly runs are having challenges sorting the important emails from the repetitive info.
   
  •  
   
  • Maybe it's email worthy that unmanaged nodes isn't fresh...   
        
   
  •  
• Web pages and reports
•   
   
  •  
   
  • In RRD pages, give textual data supporting the graph. That'll probably push it over the edge to needing templated data instead of straight html.   
        
   
  •  
   
  • Support proxy servers (nice to have for update check, will need for geo-location)   
        
   
  •  
   
  • Give links to non-RFC1918 addresses on maps: GeoIP2Location   
        
   
  •  
   
  • Drill-down from topology map with per subnet listings of computers, including inventory and remote control links for them   
        
   
  •  
• Auto-import email from domain controller into ConsoleUser table. If UserName is like Directory and Email is blank, then import from AD. Requires AD credential input in UI.
  
• Count duplicate serial number records and show a count before the number... e.g. "34 machines with serial number SystemSerialNumb, 2 machines with LYAC12"
• More options, more smarts, more feedback, more efficiency...
  
• Find why McAfee silently stops it from working properly when it's run as a scheduled task (error 0x9 in Windows scheduled task, immediate "success" as a LANDesk scheduled task, works great when run interactively from the start menu).

How to work under the hood with the ldms_* utilities.

• ActiveState Perl. I still use 5.8, but I've been preparing for a move to 5.10. This is the language distribution; with it and the right modules (loaded by using the Perl Package Manager) you can run the programs in source code form. There are a lot of modules you'll need to run the programs with; for developing, you'll want to grab Perl::Critic and Perl::Tidy, and maybe Devel::SmallProf or Devel::NYTProf.
•  
    
  • Perl::Critic analyzes your source code for maintainability
    
  • Perl::Tidy reformats your source code for readability. Both of these are based on Damian Conway's    Perl Best Practices  
      
   
• ActiveState Perl Dev Kit. I use this, version 7.3, instead of the full studio for two reasons. It's cheaper, and I don't use the IDE. If you're more familiar with Microsoft Visual Studio and want something similar, that's the ActivePerl Pro Studio. The PDK's main job is to compile Perl code into a Windows executable file (.exe).
  
• Instead, I use  vim. It may be arcane, but I know how to use it, it's available on every computer operating system, and it includes all sorts of handy tools for development support. If you don't know vi and don't want to learn it, ActiveState provides a free source code editor called  Komodo Edit. Using some sort of source code editor is crucial, if only for syntax highlighting. You'll also want the  taglist plugin and the  perl support plugin. Compare the readability of these two screenshots, and imagine trying to find a subtle typo in notepad.

• Nullsoft Installer System. Packaging is complex, and I've barely scratched the surface of NSIS, but it's free and functional. There are also a lot of examples out there to follow.
  

Version 3.2.6 is now uploaded to http://www.droppedpackets.org/scripts/ldms_core.

As the next step in its ongoing quest to delete data that was automatically gathered and then left to rot, ldms_core will now delete automatically gathered SLM products that have no installations (note that this is not USAGE, but INSTALLS).

It is possible that this can produce churn in situations where products are being installed and uninstalled in rapid succession; this should be a minor problem compared to the database performance degradation that results from thousands of junk product definitions.

As is usual with new features, this needs testing; please give it a whirl on your test server before trying it on production. At the very least, have a database backup handy.