Using SCCM with Software Asset Management

In working with a client recently, we came across a problem that exists when trying to incorporate System Center Configuration Manager (SCCM) software installations with Software Asset Management. It turns out that SCCM does not actually pull Software Edition information for software installed on the systems that SCCM manages out of the box. It can pull that information, but to do so requires a lot of work that will need to be done by someone who not only has access to all of the SCCM managed systems but someone who also knows how to write code in Powershell. If you are asking yourself, “What is Software Edition?”, let me give you a brief example and then tell you why it makes a big difference when it comes to Software Asset Management.

I’ll use Adobe Acrobat as an example because a lot of people will be familiar with it. In this example, Edition is the difference between Acrobat Standard and Acrobat Professional. “Standard” and “Professional” would be your editions. It makes a difference because in order to link the installations on a given system to your pool of Software Entitlements or Licenses, ServiceNow will need to know the edition. 

Checking the ServiceNow documentation for configuring Software Asset Management with SCCM here, you can find the following statement under the Normalization heading: “The normalization process compares the discovered publisher, discovered product, and discovered version and edition values against the ServiceNow repository of normalized equivalents.” If you look around on the same page, you will find no mention of that fact that to get the edition information, further configuration within SCCM is needed.

You’ll find the information for SCCM to get software editions in a Servicenow Knowledge Base(KB) article titled “Custom solution to gather editions in SCCM”. If you have a Servicenow HI account, you can find that article here. The solution proposed in the KB article is a lengthy 25 step process that needs to be performed on the SCCM server, and it only gets SCCM ready to pull that information and then pass it over to ServiceNow. To actually get the software edition information, you will need to write out some Powershell code that SCCM will run against the systems it’s managing and on top of that, you will more than likely need a custom section of code for each and every software package you would like to get the edition information for. 

ServiceNow actually provides some examples of what is needed for three different software packages (Adobe Acrobat, MS SQL Server and Exchange Server) and I’ll put those examples below.

To understand what’s happening, you don’t need to be able to read Powershell coding, all you need to notice is that the text you see in each example is different and that means that each software package you need to get the edition for, will need to have it’s own custom code created.

Here are the examples ServiceNow provides:

Now, this isn’t a fault of ServiceNow or SCCM; I actually appreciate the fact that ServiceNow shows a way to fix the problem. However, this comes back to the fact that there’s no standard way that software manufacturers store this information on a system. 

Where I think ServiceNow could improve on this is to make it much more obvious to their customers, both in their documentation as well as in the instance, that extra work outside of ServiceNow is needed. For example, if Software Asset Management is activated in an instance and a SCCM plugin is also active, ServiceNow adds a new Data Source to the existing SCCM data sources specifically for Software Edition. Servicenow could put a form message on the Software Edition data source that links to the KB article.

Hopefully, this will save you a lot of troubleshooting or searching trying to find a solution. The solution exists, ServiceNow just doesn’t make it very obvious or easy to find.