Trustworthy data tips & tricks in ServiceNow SAM

Our trustworthy data tips & tricks in ServiceNow SAM allow you and your organization to get valuable information about the software installed. To learn why it’s so important, you can read one of our recent posts where we take a closer look at the trustworthy data in ServiceNow SAM.

While implementing ServiceNow Software Asset Management Professional (SAMP), your first step is to start getting reliable information on the software you installed within your environment and/versus entitlements you possess. This is the most difficult and time-consuming part of SAMP deployment. But if done well, it’s a one-off activity.

Software installation sources
in ServiceNow SAM Professional

There’s a recommendation to use (in parallel) 2 sources of software installation data in ServiceNow SAM Professional. These are:

  1. ServiceNow Discovery – to gather information about the software installed on your servers,
  2. SCCM – to gather information about software installed on your desktops.

To ensure that those 2 sources do not interfere with each other, you have to switch only 1 plugin.

ServiceNow Discovery & File-based Discovery plugin

ServiceNow Discovery and ServiceNow SAMP communicate with each other, requiring (almost) no additional configuration. The tricky part is if you want SAMP to know about the software uninstalled from your servers. ServiceNow Discovery doesn’t track software uninstallation and doesn’t provide any “direct” way to achieve it. Nevertheless, while preparing some workaround, in the majority of cases such functionality can be implemented and brings huge value. At any point in time, you consider only software installed at that very point in time.

Enabling the File-based Discovery plugin enhances ServiceNow Discovery, providing even more accurate and configurable data on the software installed on your servers. The plugin is available from the New York release on.. Although it’s easy to enable it, remember that the plugin activation is not enough. The biggest value of File-based Discovery is that you can easily track any software you like and you can ignore any software you (don’t) like.

Microsoft SCCM integration

The first rule of Microsoft SCCM-ServiceNow SAMP integration is “Have a solid SCCM manager”. SCCM is a complex tool that (among others) independently stores the records of particular software installed on a particular device and particular software uninstalled from a particular device.

Moreover, depending on some SCCM configuration, different SCCM tables store those records (and these tables might change over time). What you need in SAMP, is a delta of those pieces of information, i.e. information about the software currently installed on all devices (software ever installed minus software ever uninstalled). To achieve this, you have to know:

  1. Which SCCM tables to query?
  2. What to query them about?
  3. What timestamp(s) and unique keys to use?

However, in many cases, the ready-made ServiceNow configuration (SQL statements) requires changes as well.


What if I forgot to migrate software installations and refresh processor definition at the beginning of the SAMP implementation?

If you already configured ServiceNow Discovery or SCCM, before you enable SAMP in the ServiceNow instance, the records of software installations are stored in a different ServiceNow table than after SAMP enablement. ServiceNow recommends migrating those records into that new table just after enabling SAMP. We, as ServiceNow consultants, say “It depends”.

In a number of cases, this approach will be good and for sure the fastest. Yet, you have to keep in mind that:

  • By doing so, you’ll end up with information on the software installed at any point in time (since you started using Discovery/SCCM) and such old data might bring more noise than value.
  • In the table from which you are migrating, most probably some records represent installations already uninstalled. As a result, taking them into account during reconciliation will lead to over-licensing.

Instead, you can start over from scratch, carefully configuring Discovery and SCCM. And as for refreshing processor definition, you can run it any time, and most likely it’ll impact less than 10% of your CIs.

I’m still getting multiple software installations of the same software on the same device and information on software installed on the retired/stolen computers.

The second problem is easy to fix, the first one – not. Multiple software installations of the same software (product) on the same device are a serious problem. They cause licenses over-consumption. You can fix it after you:

  1. Install/upgrade to the ServiceNow New York or higher (and just here you have 80% of cases resolved),
  2. Very carefully configure your ServiceNow Discovery,
  3. Very carefully configure your SCCM Integration,
  4. Write quite a lot of code…

To stop getting information about the software installations on the retired or stolen computers, you have to only enable a single Schedule Job. For some reason, disabled by default.

How can I revert the manually normalized discovery model?

In fact – you can’t. When you manually normalize a discovery model (either “really manually” or creating custom Pattern Normalization Rule), you can’t revert it. To enable such functionality, you have to change some values in some OOB records in [sys_dictionary] table. But it’s not recommended. That’s why you should be very careful with manual normalization of discovery models, especially using custom Pattern Normalization Rules which impact multiple discovery models at once.

Data clean-up

By “data clean-up” we mean the removal of all records from the Software Installation [cmdb_sam_sw_install] table and from the Software Discovery Model [cmdb_sam_sw_discovery_model] table. Once you do it, you re-feed only the Software Installation table (with data from ServiceNow Discovery and/or SCCM). The records in the Software Discovery Model table appear automatically on the insert.

ServiceNow does not take a particular stand on that approach, advising neither for nor against it. Our experience proves it’s very handy, especially at the beginning of SAMP implementation, i.e. while configuring trustworthy data. What you have to take special care of here is:

  1. Deleting those records in batches,
  2. Re-feeding the Software Installation table in batches, so that neither you kill the instance nor the source(s).

Though implementation-driven, these are only high-level trustworthy data tips & tricks. For a deep dive into the topic, we provide both SAM training as well as the implementation itself.

Software Asset Management in ServiceNow

Software Asset Management – suggested phased approach

objectives of software asset management servicenow by spoc

The primary goals of the Software Asset Management process (abbr. SAM process) is to:

  • Reduce IT costs (optimize spend),
  • Limit operational, financial, and legal risks related to the ownership and use of software (ensure compliance and support software audits).

Both are achievable through management and optimization of software assets across their lifecycle (launch through to retirement).

SAM process objectives

Holistically, the objectives of the SAM process are:

  • To reduce/eliminate unnecessary purchases by requests execution with the use of available entitlements,
  • To identify and record all purchased software entitlements and associated allocations within the organization,
  • To assign correct license metrics and supporting software contracts to the software entitlements,
  • To create and maintain accurate software models, client access records, and software discovery models – these enable the establishment of entitlement compliance positions,
  • To proactively identify cost saving opportunities through removal and re-use of unused software (where terms and conditions allow),
  • To capture purchase order information that allow record cost of software entitlement,
  • To accurately allocate available and acquired entitlements to users and devices,
  • To ensure blacklisted or unlicensed software is not used to strengthen compliance posture against publisher rules and regulations,
  • To expedite audit response and to avoid non-compliance fines and financial penalties,
  • To provide accurate software asset information to other enterprise processes (e.g. Change Management), which enables business and financial decision making,
  • To eliminate human system integration via email, spreadsheets, and tribal knowledge.

How to start optimizing your SAM

Recommended approach is to start by working with the publisher that represents the largest software spend in your organization. You should shift the focus towards the normalization of software products that are licensable.

SAM and Capability Blueprint

software asset management servicenow best practices

Capability blueprint is a good practice for implementation and development of Software Asset Management program:

  • Tier 1 – Trustworthy Data
    Know what you have, so you can manage your assets.
  • Tier 2 – Practical Management
    Improve management controls and drive immediate benefits.
  • Tier 3 – Operational Integration
    Improve efficiency and effectiveness through integration with other process such as request procurement.
  • Tier 4 – Strategic Conformance
    Achieve best in-class.

To ensure the expected benefits of the ‘improved’ Software Asset Management process are achieved:

  1. Articulate the expected benefits before the ‘improved’ process is defined,
  2. List down all the audit findings you should focus on in terms of the remediation,
  3. Translate the expected benefits into performance measures,
  4. Define metrics for each performance measure,
  5. While designing the improved process, ensure that the data needed to calculate each metric are captured during the execution of the process,
  6. Document the requirements for each metric,
  7. If possible, capture ‘as is’ performance metrics as a baseline for measuring improvements/benefits realized.

What KPIs and metrics to consider

  • % of application installations which have not be used within the last 90 days,
  • Number of installations of application which are unauthorized (blacklisted) for use,
  • Value of unlicensed software identified and remediated,
  • Cost paid arising from software licence audit findings per year,

SPOC can always support you in your in endeavour in setting the E2E Software Asset Management Process.