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:
- ServiceNow Discovery – to gather information about the software installed on your servers,
- 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:
- Which SCCM tables to query?
- What to query them about?
- What timestamp(s) and unique keys to use?
However, in many cases, the ready-made ServiceNow configuration (SQL statements) requires changes as well.
Challenges
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:
- Install/upgrade to the ServiceNow New York or higher (and just here you have 80% of cases resolved),
- Very carefully configure your ServiceNow Discovery,
- Very carefully configure your SCCM Integration,
- 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:
- Deleting those records in batches,
- 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.
