Overview

There's this consulting client I've worked with in the past. They're a big engineering firm, with nearly everyone working as a software developer. Being a for-profit company, cutting unnecessary costs where possible is always a good thing. But cutting costs for services that employees actually need is another thing entirely.

This firm had a problem recently where IT needed to cut annual software costs by a small percentage. Realizing that most software developers don't need Microsoft Project, they analyzed their software inventory to find people who probably didn't need the software.

They weren't prepared for the backlash that erupted a day later.

'Give us back this tool! Its removal prevents us from meeting our deadlines,' they cried. Removing Microsoft Project from even a small number of software developer computers quickly brought IT into the spotlight, 'Our developers are slipping schedule! We'll be late!'

It was software metering that ultimately vindicated IT's decision. With a cursory look through IT's software metering reports, the shouting managers slinked back to their offices realizing they were wrong.

They learned, much to their chagrin, that only three software developers on the entire project had even used Microsoft Project in over three months. With quantitative data, IT wins again.

Understanding Software Metering

Microsoft Windows is notoriously deficient when it comes to managing applications. Rapidly installing or uninstalling applications isn't easy without external tools. Inventorying those applications isn't a task that's particularly easy when you want to create nice reports across dozens or hundreds of machines.

Those limitations highlight why you won't find software metering tools as part of Windows' native operating system. Software metering represents a superset of information over just a basic software inventory report. While a software inventory report might tell you which software packages are installed, when they were installed, and by whom, software metering adds one additional piece of information: How much that software was actually used.

This is terrifically useful information when cutting software costs is important. If your head is on the chopping block for removing installed applications, you want quantitative data that proves your 'you haven't used it' assertions. With the right solution you could easily determine:

• How many instances of an application are installed on computers, along with how many users actually ran the application.
• Whether users are still using instances of an application that you no longer want to keep under software maintenance.
• How many instances of the application are being used regularly and how many instances are only rarely being used, which can help reduce the number of licenses you're paying for.
• Which dates, days, and times of day are instances of an application being used, to help determine if hosting (rather than directly installing) the application and using a concurrent licensing model might save costs.

Reports that contain the information above arm your IT organization with quantitative information. That information documents which users are actively using which applications. As with my engineering firm story, exactly that quantitative information is helpful when it comes time to start the uninstallations.

Creating Your Own Software Metering Solution

Any software metering solution starts first with a software inventory. Before such a solution can begin measuring use, that inventory is necessary to determine which applications to monitor.

It's also necessary because software metering isn't an activity you'll want to turn on for every application. Measuring the use of every application on a computer could have deleterious effects on its performance. More importantly, and as you'll discover in a minute, measuring everything just gives you too much information. Thus, most organizations limit it to just their apps of interest.

To accomplish this, most software metering solutions look at the instantiation of individual executables. For example, if you wanted to measure the use of Microsoft Word on a system, you would instruct your software metering solution to monitor the starting or stopping of the winword.exe process. Measuring only that piece of information it becomes possible (with some creative calculations) to determine how important an application is to its user.

Gathering this information doesn't necessarily require an external solution. You could collect it with Windows PowerShell alone. For example, the Get-Process cmdlet includes a property called StartTime that contains the last time the executable was instantiated. Running the following series of cmdlets will extract that information for winword.exe:

Get-Process | Where-Object { $_.name -eq 'winword' } | Select-Object StartTime

Figure 1 ' PowerShell Get-Process Command

The resulting output from this command might look like this:

StartTime
---------
3/27/2011 4:08:45 PM

There's a shorthand PowerShell notation you can use to gather StartTime from a process. The shorthand uses dotted notation rather than piping Get-Process to the Select-Object command. In doing so, it reports the StartTime information in a format that can be easily subtracted from the current time. First, the shorthand:

(Get-Process winword).StartTime

Using this syntax gives you a slightly different result, one that's more easily consumable by the step you're about to take. Use the Subtract method associated with the Get-Date cmdlet to subtract the current date/time from the StartTime of the winword process. That command looks like this:

(Get-Date).Subtract((Get-Process winword).StartTime)

The results from this command look something like this:

Days''''''''''''' : 0
Hours'''''''''''' : 0
Minutes'''''''''' : 51
Seconds'''''''''' : 57
Milliseconds''''' : 397
Ticks'''''''''''' : 31173970000
TotalDays'''''''' : 0.0360809837962963
TotalHours''''''' : 0.865943611111111
TotalMinutes''''' : 51.9566166666667
TotalSeconds''''' : 3117.397
TotalMilliseconds : 3117397

Notice how the current user has used Microsoft Word for 51 minutes during this period. That's useful information for metering their Microsoft Word over the long haul.

You can take this script one step even further and extend it to all the applications (or, technically, their processes) on a system. In this final version, I'll assume that you want just the number of minutes that each process has been running along with the process' name. Accomplishing this requires some extra effort with a ForEach loop and a couple of variables.

The syntax looks like this:

ForEach ($Proc in (Get-Process)) {
$ElapsedTime = (Get-Date).Subtract($Proc.StartTime) ;
Write-Host $Proc.Name,$ElapsedTime.Minutes }

Figure 2 ' PowerShell cmdlet to pull run time for all processes

While I've wrapped it for readability, this final command still functions within a single line. Being a single-line command makes it easy to schedule. The command uses ForEach to loop through all the results of Get-Process. Each resulting process gets its StartTime subtracted from the current time and recorded to the variable $ElapsedTime. Once measured, the final Write-Host is used to output the process name ($Proc.Name) and the elapsed time in minutes ($ElapsedTime.Minutes) to give you a list, a piece of which looks like this:

'
iexplore 13
inetinfo 14
iPodService 46
ipoint 16
ISUSPM 16
iTunes 47
iTunesHelper 46
'

Figure 3 ' Results from process run time

The list goes is much larger than what you see here, obviously, because it represents every process currently running on the system. That list includes system processes like svchost, system, and others that you don't care about for metering. But it does give you a usable list of processes and their quantity of runtime.

Now, as you can surely see, this little command only highlights the current use of each process. And it only reports usage if those processes are actually up and running. Outputting its information requires running the script repeatedly and reporting each run's information to a file. Doing that is relatively easy.

The hard part is in consolidating the data, and turning that data into something that's useable. Once sent to that file, you're going to need some other kind of script that cleans up the data and generates a report of useful information. That part isn't something that's easy to discuss in a short article, and probably isn't something that you want to manage across dozens or hundreds of computers at once.

In the end, building a software metering solution is probably a task that's best left to the professionals. Companies that sell software metering solutions can easily add their functionality into whatever service they've already designed. Can you imagine how difficult it would be to manage installing your own PowerShell scripts all around your network? PowerShell itself isn't well designed to be constantly running against every computer, and managing such a system will only get more complex over time.

Integrating Metering with Whitelisting

Software metering is really only the start. There is another administrative function that goes hand-in-hand with it that you might like running inside your network. That function is application whitelisting. There are other articles on this website that discuss the activities associated with application whitelisting. For our purposes, know that whitelisting provides a mechanism to control which applications are allowed to run on your network.

Consider how metering and whitelisting could work well together. Once you've begun metering, you will immediately know which applications are not being used on your network. Since they are no longer being used, you can safely eliminate the costs associated with their licenses.

When you eliminate those costs and relinquish their licenses, you need some follow-on mechanism to ensure that users don't attempt to reinstall the application. A software whitelisting solution can be instructed to prevent the application from running on configured computers.

The all-or-nothing approach is admittedly relatively rare. Occurring much more often is when software metering discovers which users need the application most. In the Microsoft Project example, only three software developers were found to actually use the application. Thus, removing Microsoft Project from the other users makes budgetary sense. Restricting the application from the other users with a whitelisting solution then makes administrative sense. It prevents them from later using the application and invalidating your new software license terms.

Software Metering is a $mart Idea

Dollars are important to every business. So is software. But software that's been purchased and left unused is a waste of exactly those dollars. Implementing a solution that seeks out unused software so it can be removed is a smart move for any cost-cutting business. Take a look through the solutions on the market today to find one that meets your needs.

Who knows? You might find that the money you saved is well worth the cost of metering solution you purchased.