In a previous blog post entitled, “Total Usage for All Metered Software Programs Query Matches the Executable Name,” I talked about my surprise when I found out that disabled metering rules were being displayed in the software metering (SWM) reports. I closed off that blog post by saying that this was in fact a good thing, so let me explain why it is a good thing and then I will go into more detail about each point below.
1. Fewer active rules needed.
2. Capture new versions or languages without the need for a new rule.
3. You can get creative with your reporting.
Fewer Active Rules Needed
I do a lot of work for international clients. They generally worry about multiple versions of software which could include several different language versions. In the past, if I wanted to ensure that I collected details for Microsoft Project from a client who uses both English and French language versions, I would need to create a separate rule for each version and language. For example:
· Microsoft Project 2007 English
· Microsoft Project 2007 French
· Microsoft Project 2010 English
· Microsoft Project 2010 French
You can imagine how many rules I would need to create if an organization used more than two languages, and employed several versions of a diverse group of products. However, without creating these rules, I would not be able to report on each version and the version’s language. It is estimated that you can only have ~100 SWM rules within the SWM policy. Therefore if you write one rule per version and / or language you will be restricted about the number of products that you can obtain software metering data on. By using only one active generic rule for all versions and languages then you could create reports about 100 different products.
Capture New Versions or Languages Without the Need for a New Rule
In my example above, I would only see results for English and French versions of Microsoft Project 2007 and 2010. Therefore, if a Greek version of Microsoft Project was installed, none of the rules would apply and there would be no way of knowing the SWM details for the Greek version. However, by using a generic SWM rule that ignores versions and languages everything is collected. This is a good thing as it means we could create a disabled rule for Microsoft Project Greek and be able to report on it right away, instead of waiting to get results! The same is also true if Microsoft Project 2013 was installed. You could gather results right away instead of waiting until you noticed the new version.
You Can Get Creative With Your Reporting
In both examples above there is no need for extra SWM rules, however when it comes to reporting, disabled SWM rules truly shine.
· You can use the disabled rules to display data from the built-in reports. Similar to what I did within my first blog post. Since you are collecting data for all versions and all languages, if a new version or language is installed in your environment you can quickly create a disabled rule for the data and report on the results immediately by using the existing generic rule data.
· You can leverage the disabled rules within your own custom reports.
· By creating disabled rules and leveraging them within reports, you reduce the need for Managers and Asset Managers to manually gather data about individual versions and languages on each product for their own reporting purposes.
I hope that you see how using disabled SWM rules can be an advantage to you and your organization!