Discovery and Usage data for Software License Management – Is Microsoft SCCM the Best Solution?

By Sumin Tchen

Many organizations use Microsoft’s SCCM product as their primary software discovery method. Because SCCM is already used by operations, it comes at little or no additional cost to the Software License Management (SLM) group. But, is it a wise decision for software licensing to use SCCM data as the primary data source? We suggest that this decision should be reconsidered because of the extra costs and missed savings opportunities that come with using SCCM for discovery and usage.

Typical Scenario

You may recognize this scenario in your organization. A business line manager needs an instance of SQL Server or Oracle stood up immediately. The operations people are happy to comply, but say that they first need to get the software licensing group involved and that may take a month. The business line manager says to stand up the server now and he will inform SLM and take the flack. Sometime later in the year an audit and true up is done and surprise, there are additional VMs with SQL Server or Oracle Enterprise Editions in use, and the organization now owes the vendor a lot more money.

Sound familiar? Software licensing was using SCCM data, which was out of date and never picked up those new VMs. In fact, if it was an Oracle database, SCCM never discovered it at all. Similar scenarios can occur within engineering and production groups, when they need to add new CAD tools or new features onto their existing software.

What can be done to avoid these scenarios? SLM needs a discovery system that automatically discovers all new and existing VM guests and hosts; new instances of software on the VMs; and the associated CPU types and cores on those VMs. The discovery system also needs to run on a continual basis, not just once every few months. In addition, software licensing should have immediate access to the discovery data and not have to rely on operations to do a data call and wait weeks for the results.

Software Usage

It is one thing to discover that a software package or suite is installed, but it is equally important to discover whether the software package has been used or not. Why pay for more licenses if the organization has ones that are unused? Why pay for ongoing maintenance or SA on software that is not being used? Knowing whether a software package has been used and when is very important to better managing software and maintenance, an increasingly large part of most IT outlays.

Have you tried using SCCM for software usage reporting? SCCM calls this software metering, and it requires the administrator to specify the file(s) to be monitored and then wait for six, nine or twelve months to see the results for that file. This is hardly encouraging when you need an answer today.

Why not consider using a system that automatically discovers when all software packages have been last used so that software can be either reused or removed?

License Keys and IDs

SCCM does not automatically discover license keys and IDs. Even if your SCCM admin writes special scripts to make an attempt, the results are probably incomplete. Why are license keys important? If you have OEM licenses on some desktops, you need to treat those differently than those covered in your enterprise agreement. The same holds true for licenses purchased from third parties not part of your EA agreement. If your organization has multiple groups purchasing software, it will be very useful to have license keys to be able to true up those agreements.

Non-Microsoft Software

SCCM does software discovery by first setting the file types to be discovered, i.e. exes or dlls, for example. It then joins these discovered files to the SCCM Asset Intelligence Catalog to try to determine the correct software package and version that is actually installed. There will be an enormous number of files returned for each host machine, but this will be relatively meaningless unless the exact file is also in the Asset Intelligence Catalog downloaded from Microsoft. This is unlikely to be the case for any custom or GOTS (Government Off The Shelf) software, so these packages will be very difficult to identify.

Some common software, such as Oracle databases and applications, are not discovered by file types. In this case, SCCM does not discover this software or any details about it. This can lead to very costly licensing errors, such as when the software licensing group has licensed Standard Editions and the vendor audit finds that Enterprise Editions have been installed. This same situation applies to some expensive CAD or graphic design tools.

It’s Not Just Software

Licensing needs data on all Virtual Machines and how they map to the physical servers. This is required for most server software, such as SQL Server and Oracle databases and many CAD packages. In addition, for licensing these products you will need the CPU type (for core factor calculations) and the number of cores assigned to each VM guest and VM host. Many organizations have VMs which run on Linux and other Unix operating systems. Although SCCM 2012 supports these operating systems, the non-Microsoft clients are not an “out of the box” experience.

For ITAM purposes you also want to know about all of the network attached devices, such as network printers, IP phones, etc. and get details such as make, model and serial numbers of those devices. Although SCCM has a network discovery feature, you can only run one discovery rule, i.e. for printers, at a time, and they are very complex to set up. In addition, the network discovery only returns the IP and MAC address and does not discover the device’s details such as make, model or serial number, making it less than useful for ITAM purposes.

Access to the data

What about giving the software licensing group direct access to SCCM inventory data so they can view it on a regular basis? This is unlikely to happen. SCCM data is typically only available to the SCCM administrators. If software licensing needs access to this data they must ask the SCCM administrators to supply it.

SCCM reports are based on SQL Server report builder, and although there are a fair number of standard reports, it helps to know SQL to modify or link additional information to these reports. In addition, the reports can only be opened on a computer that has SQL Server reporting services and the proper rights.

An alternative system publishes its information on the server as Web based reports. This architecture also allows for easy sharing and access to the information by both local administrators and regional and headquarters IT staff. The contents of the reports are automatically tailored based on each user’s login, so that the user will only see information relevant to their area of responsibility.


We started the discussion by showing a common scenario where software had been installed without the software licensing group being made aware of it. The SCCM data was either out of date or did not discover the software at all. This is what happens when the discovery system runs only occasionally and the data is not readily available to the software licensing group.

The need for continual monitoring of installed software and changes cannot be over-emphasized. The system needs to automatically update the detailed discovery of all software, hardware and security configurations on a daily basis and create a central repository with the data.


Many software licensing groups use Microsoft’s SCCM as their primary source of installed and usage data, but is this the best choice? We suggest that this decision be reviewed by each organization’s software licensing group for the following reasons:

  • License management needs up to date data on all software installs and changes to be able to automatically track authorized and unauthorized changes that occur throughout the organization. Common mistakes such as installing the wrong version of an expensive software package can result in large adverse audit findings
  • Software usage data is important to be able to reassign or remove unused software packages and to help in re-negotiating SA and maintenance agreements. This usage data should be available immediately, not in nine to twelve months’ time
  • Detailed discovery of all software packages is important, particularly expensive server, engineering and design software. This naturally includes non-Microsoft software
  • Automatic discovery and dependency mapping of virtual guests and hosts is required. This includes non-Microsoft VMs, running on Linux, Solaris and ESX systems
  • The software licensing group should have direct access to the data, and not have to wait weeks for the data call results
  • And last, but not least, the data should always be up to date

About the Author

Sumin Tchen

Sumin Tchen is the CEO of Belarc, Inc.