Java Software Metering with CM - Java 7 End of Life

It is almost that time, another Java runtime will go end of life in just over a month.  This means we have only a month left to finish the Java upgrade we have already started, right?  Well I have lived through a few of these Java events over the years and they really don't seem to get any easier, or even ever really end.  In fact I am seriously considering removing Java from users systems.  The one only issue is, who is actually using it for work related purposes?  That has always been the million dollar question to me.

Turns out if you pay for Java support there are some tools that can help you determine this sort of thing.  So where does that leave the rest of us that maybe are not as fortunate as the aforementioned minority?  Well fortunately for us, Oracle did us all a small favor late last year and built-in some usage tracking mechanisms into the JRE's we are already be using.  Turns out "Usage Tracker is available in Oracle Java SE Advanced and Oracle Java SE Suite versions 1.4.2_35 and later, 5.0u33 and later, 6u25 and later, 7 and later, and 8 and later.".  (http://docs.oracle.com/javacomponents/usage-tracker/overview/index.html)  Think of this as software metering for Java plug-ins and VMs which run on your systems, it logs each users data into a log file in their user profile.

I just had to try this so I followed the instructions, dropped the usagetracker.properties file in the correct directory and then fired up a browser and ran a few Java plugins.  All of the data was right there, in a little txt file in my user profile.  So now what?  Turns out there are a few catches to all of this logs.

• A properties file must be in the appropriate directory for each JRE if you want to log data.  For better or worse, maybe some machines have more than one JRE installed.
• The default delimiter in their tracking file was a comma.  Typically this is great, until I noticed there are no text qualifiers in the data elements. Formatting nightmares.
• The log files are stored in the user's profiles by default.  Typically a system should only have one user, but this is not always the case either.  So we need to aggregate the data together.

So based on my own initial assessment I came up with a few functional requirements on how I would want a data collection to work for this.

• Enabling logging for all JRE's installed on the system.
• Use a delimiter character that would be less likely to show up in the command line options very often, I chose a carrot '^' for this.
• Enumerate all of the user profiles and centrally store the data on the system.

Based on how Java usage tracking works, and how I wanted to see it work, I setup a PowerShell compliance script that performs the following actions.

• Logs all data associated to the script to the CM client logs directory (CM_JavaUsageLogging.log) when logging is enabled.  This is the default, this can be disabled by changing $LoggingEnable to $false at the top of the compliance script.
• Query the registry for installed JRE's and creates the usagetracking.properties file in the lib/management folder to enabled logging for all instances.
• Merge all of the data from all of the tracking logs on the system and add the user which executed the vm or plug-in to the dataset.
• Creates a CM_JavaUsageTracking WMI class to store the data centrally on the system.  Then we can pull it off with hardware inventory!
• Only add the new entries on subsequent executions.  The data in WMI can be inventoried.  (MOF below)

The cab located here can be downloaded, tested, and used to get you started on your way.  Please note this is a work in progress, so I will update this file with the new changes once they are ready.  If you have any feedback (it is welcome) on the compliance script please let me know at This email address is being protected from spambots. You need JavaScript enabled to view it..  This has been tested with PowerShell 2.0 and above, but as always test it first to veriy everything works in your environment.

The data in WMI can be inventoried!  So after running this script on a system, connect to it and add the CM_JavaUsageTracking to hardware inventory in CM, now you have Java software metering in a sense.  This is still a work in progress, here are a few more items I still want to add and cleanup.

• The compliance rule is stating non-compliant even though the script appears to complete.
• Add a day count rolling history feature so data older than 'x' number of days is removed from WMI and not edited.  This would allow a limit per system on the collected data.
• Test and validate support for 64-bit JREs, I have 99% 32-bit so this was my priority.

For those of you concerned about how much space this will require in your cm database, I checked and in my case 30 days of data from approximately 2500 systems was a table around 50 MB.  This will vary greatly depending on how much Java plugins are in use in your environment.  Data is now being collected and I can sit back and see which sites users are using and determine what I am going to do about it. 

Happy data spelunking!