So you’ve deployed ConfigMgr Asset Intelligence, maybe imported your licensing statement from the Volume Licensing Service Center, maybe some third party licenses and you’ve deployed Software Metering. You’ve got plenty of clients and you decide to delve in to the ConfigMgr built-in reports to see just what’s available and, hopefully, to ascertain just where you stand with regards to licence compliance in your organisation.
Shock horror. You discover that the in-built reports are probably not what you had hoped (I choose my words politely). You had probably hoped for a neat report detailing each product on your license statement, combined with a nice column saying how many licenses were used and maybe even a column giving you the difference (because no one wants to use calc.exe to do this for 100 different licenses!). You’ve probably found something which tries to be this, but fails miserably.
So having had your hopes dashed, you may have begun looking at various Software Asset Management tools available which plug in to SCCM. WAIT A MINUTE – Of course, while these can be fantastic tools with a valuable output, you should rightly expect more of your ConfigMgr solution – given that said licensing tools tend to pull the majority of their information from ConfigMgr anyway. And hey – we just want a rough idea of compliance, so let’s not use a sledgehammer to crack a nut.
You’ll be happy to know that there is hope. It’s a quirky solution, not clean and certainly not pretty – but it does work. It’ll not give you the level of insight that some of the asset management tools will give you, but for many, it’ll help give an executive summary of the licensing position in an organisation.
Firstly – lets look at he different licensing types we may have.
Per Device – the traditional model, you pay for a device per installation.
Per User – a newer model becoming increasingly common in our mobile work – you pay per unique user, which gives us the flexibility to install across multiple devices, but measure usage on the basis of unique users or concurrent users.
Per Processor – common in database technologies, we pay for an installation per processor in the server utilised for the installation.
Some products treat you like royalty and provide in-built licensing tools that manage the licensing situation for you – the majority however won’t do that.
ConfigMgr Limitations
Let’s get the caveats out of the way first – ConfigMgr provides you with the opportunity to import a General License Statement or a Volume License statement – in a nutshell this means, Non MS and MS based licenses.
What you will inevitably find in this process is the reports natively contained in ConfigMgr will still leave you with much manual work to do in reconciling your license situation. The inventoried data within Configuration Manager does not tend to align very well with the imported license information or the software metering data. In fact, even with Asset Intelligence synchronisation, the usefulness of the imported data in the native reporting tools is still called in to question.
It is also important to realise that, as with any system, GIGO applies. That is – Garbage In, Garbage Out. ConfigMgr relies on a healthy client being installed on all endpoints, and those clients communicating regularly and reliably with the ConfigMgr infrastructure.
Consider the laptop with no corporate connectivity that has some very expensive software installed – without regular connectivity with the ConfigMgr environment, this client may decide to disappear – and your license with it. Thus it is important to retain regular visibility of all clients – if you don’t have DirectAccess or a VPN solution that enables connected clients to call home, you should consider deploying Internet Based Client Management in your ConfigMgr infrastructure.
Thanks for that – now how do I measure my compliance?
The solution requires some intimate knowledge of the ConfigMgr database schema – but if you don’t have this, looking at the existing report datasources will give you all the knowledge you need on where to find the information you require (or.. read on). It’ll also require some somewhat decent SQL skills – nothing too complex, but different types of join, using built in functions, grouping and ordering are a must.
SCCM can give us just the amount of flexibility we need to get some useful licensing compliance data in a nice format. To achieve this, we will utilise the asset intelligence, software metering and general license ledger functionality. You could potentially also use the import of the Volume Licensing information, but in my experience it is easier to include the Microsoft data in your General License Ledger too (it requires a bit of work to get it in the correct format but it works quite well!). Natively, there is no link between the asset intelligence, software metering and licensing components. Whilst we could try to alter things to force a solution, the reality is there could be many different inventoried titles for a piece of software – for example, “Software A (x64)” and “Software A (x86)” could be under the same license umbrella – that we need to find a more generalised solution.
So – continuing the use of “Software A” as our example, identifying these two components in the Asset Intelligence Catalog, we need to find a way of categorsing both as “Software A” and treating them as a single item for invetory purposes – enter the use of Labels. You can add up to 3 labels to an inventoried item in the Asset Intelligence Inventory. Labels are defined in the Asset Intelligence Catalog. Select both “Software A (x64)” and “Software A (x86)” and assign a label of “Software A” in Label 1 for both of these items.
Now, let’s consider that I’m not overly concerned about the number of copies of Software A installed in my organisation as it’s a per user licensing model. Enter Software Metering. Software Metering enables you to monitor client devices for an executable being run. So let’s imagine that SoftwareA.exe is used for “Software A” we should define a software metering rule for this piece of software. I won’t delve into Metering in any more detail here, but there are plenty of resources available. The key item is that your metering rule (or rules, if necessary) must have a name which matches the Label you entered in Label 1 of the Asset Intelligence Catalog. You also need to identify this piece of softwarea as a piece of software which is licensed on a per user basis. To do this, I recommend adding a second label, added under Label 2 for “Software A (x64)” and “Software A (x86)” called ‘Per User License’.
While we’re at it – let’s also add one called ‘Per Device License’ and ‘Per Proc License’ and add these against any software which uses those licensing models in Label 2.
Now – there’s one more key piece of information I need to add to complete the jigsaw – licensing information. As mentioned previously, the built in reports for Microsoft Volume Licensing probably fall short of what you were looking for – they are designed to give you information to manually reconcile your licenses rather than provide a management summary report. For that reason, I would recommend placing all licenses into the general license ledger – the format of which is explained here – https://technet.microsoft.com/en-us/library/gg712322.aspx#BKMK_ImportSoftwareLicenseInformation. This will make the data extraction a little easier. Again, the key is that the Name column matches the entry in Label 1 and your Software Metering entries. Remember, you can make multiple entries of the same name in the license ledger – how you manage these will be down to your SQL skills.
Data Extraction & Reporting
So, we’ve got a data model defined in SCCM which we can now report on. Again, reporting is beyond the scope of this post, but there are many guides available and it is a very simple process to add reports to your ConfigMgr environment. Your limiting factor will generally be your imagination.
The key tables you will need to utilise for extracting the data are:
v_AI_NON_MS_LICENSE – this is your general license ledger
v_GS_INSTALLED_SOFTWARE_CATEGORIZED – this is the software installed on a per machine basis together with a reference entry for Labels
v_LU_CATEGORY_EDITABLE – this is the data for your labels
v_MONTHLYUSAGESUMMARY – this is the summarized data for software metering. ConfigMgr automatically summarizes this information in to a monthly usage format and you should configure maintenance tasks to define the retention and summarization frequency of this data.
v_METEREDPRODUCTRULE – this will give you the data on your sofware metering rules
v_GS_PROCESSOR – this will give you processor counts for devices which rely on software with a per processor licensng model.
In summary – your SQL should do the following –
1) Link Asset Intelligence Data (v_GS_INSTALLED_SOFTWARE_CATEGORIZED) with Licensing Data (v_AI_NON_MS_LICENSE)
2) For devices with a Per User Model – should link asset intelligence data with software metering data (v_MONTHLYUSAGESUMMARY) and (v_METEREDPRODUCTRULE)
3) For devices with a per processor model – should link asset intelligence data with hardware inventory information on the processor – (v_GS_PROCESSOR)
All in all this solution should provide you with a nicely crafted solution to gain an overall view of compliance across the organisation. It isn’t pretty and it requires some creativity in crafting metering rules, the license statement and managing the labels attached to inventoried software, but it is worth the time and effort to implement, even if it is a stepping stone to a full SAM solution.
Expanding the solution
Why stop? As I said – the limit with reporting in ConfigMgr is your imagination. We rarely see enough value extracted from ConfigMgr through reporting because in all honesty it tends to be used as a technical tool rather than one which may provide important Management Information. However, here are some examples of how you could expand on the above
– Measure usage in individual business units – use the power of collections to create groups of machines and/or users to be used in your mini-SAM solution – v_gs_installed_sofware and v_gs_installed_software_categorized provide data on a per machine basis, software metering data provides data on a per user basis.
– Colour code your report to show where license usage indicates an excess or shortages of licenses
– OR – and this is where the real value of the System Center stack lives – automation – For usage in excess of the purchased license (or maybe for all installations), identify machines where software has not been used in X days and automate the removal of software to free up those licenses.
– Create reports looking at external data – maybe financial data for your software – cost per license, maintenance information etc. From these you could derive reports to influence budgeting and financials. I would recommend you utilise a separate database for this and leave the ConfigMgr database untouched, but SQL Server Reporting Services will happpily amalgamate data from multiple data sources. At this point, it may be worth begining to look at SAM solutions, because far from using a sledgehammer to crack a nut, you may be trying to use the nut to crack the sledgehammer.
In Summary
Hopefully you have seen that you don’t have to use the out of box experience in ConfigMgr and it is a highly extensible solution. The above doesn’t replicate the functionality of a SAM solution and neither is it intended to. It is designed to show you that, with a little creativity, you can tame the ConfigMgr beast and get important MI from which your business can extract real value.
Until next time…
