Software Metering–Checks and balances

Software Metering is a very interesting concept, however after been hit with quite a few issues of ensuring that we can depend on the reliable information within Configuration Manager – here comes an appendix to a great blog-post series provided by Microsoft

Software Metering Deep Dive and Automation Part 1: Use It Or Lose It – The Basics

Software Metering Deep Dive and Automation Part 2: Use It Or Lose It – The Collections

What is the issue?

For many reasons a few perfect storms essentially gave clients that from a far looked OK, but we could not consider their metering data accurate. Either it was blank (not the same as NULL), or it wasn’t good enough for only specific periods which caused them to inaccurately fall in-scope of not using a software at all. All of the reasons are of course part of the ongoing operations to ensure client health. However, users still had software removed and felt the frustration.

Checks and balances

We felt very confident in removing software, deploying accurately to devices which hadn’t use the software – apart from users being impacted by general issues of reporting metering data.

A check is to verify that there is metering data for the period that we want to ensure is software is used within. The following benefits are identified;

• New devices wouldn’t be targeted until they have metering for the entire period
• Devices which have black-out periods and fail to report any metering data for an extended period of time are excluded
• Devices which are plain broken are excluded

Collections

Structure is to create a collection for each time period (month based) that you want to check. The specific example will use the following sample scenario;

• A device will have the software removed if not used for 3 months (90 days)
• We will verify that the device have metering data for period 0-30 days, 30-60 days and 60-90 days
• The most efficient way to run the collection update is actually to have three separate collections
• Each collection can be limited to the previous one
• The collection with the deployment targeted can be limited to the final collection

Collection queries;

Metering check day 0 – 30

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System  INNER JOIN SMS_MonthlyUsageSummary on SMS_R_SYSTEM.ResourceID = SMS_MonthlyUsageSummary.ResourceID
WHERE (DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) < 30
and DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) > 0)

Metering check day 30 – 60

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System  INNER JOIN SMS_MonthlyUsageSummary on SMS_R_SYSTEM.ResourceID = SMS_MonthlyUsageSummary.ResourceID
WHERE (DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) < 60
and DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) > 30)

Metering check day 60 – 90

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System  INNER JOIN SMS_MonthlyUsageSummary on SMS_R_SYSTEM.ResourceID = SMS_MonthlyUsageSummary.ResourceID
WHERE (DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) < 90
and DATEDIFF(day,SMS_MonthlyUsageSummary.LastUsage, GETDATE()) > 60)