Troubleshooting ServiceNow Software License Optimization: A Practical Guide

This guide helps a software asset manager trace a bad license figure back to the stage that caused it, whether that is discovery, license data, compliance rules or reporting. It sets out the common complaints in the order to check them, and says when to stop troubleshooting and rebuild a stage instead.

Symptom 1: Software Not Being Discovered (False Negatives)

If software is installed on computers but SAM does not detect it, diagnosis starts with discovery. Is Discovery reaching the computers in question? Check that the MID Server covering each one is running and that the scan credentials are valid there. Have computers reported discovery data recently? If a computer has not checked in for months, its software is not current in SAM. Are computers behind corporate firewalls that block discovery communication? Some environments block the MID Server connection to the instance, so Discovery reports nothing from those hosts. The MID Server that covers each network needs outbound connectivity to the instance, so check the firewall rules on that route. Check firewall rules. Test with a manual installation: install known software and confirm SAM detects it. If manual installation is detected but production installations are not, the issue might be in how the software is deployed (some deployment methods might hide the software from discovery).

Symptom 2: License Count Not Matching Actual Installations

If SAM shows you have more or fewer licenses than you actually do, the issue is in license data. Are all licenses imported? Check that license acquisition data is complete and accurate. Are legacy licenses tracked? If you acquired a company, are their old licenses in the system? Are trial licenses tracked separately from production licenses? The gap between what SAM says and reality often indicates incomplete license data. Import all license data, including old licenses and trials.

Symptom 3: Compliance Reports Showing High Non-Compliance

If compliance suddenly shows many violations where previously it was clean, investigate what changed. Did new software get deployed without licenses? Did discovery improve and find previously unknown installations? Did licenses expire and no one noticed? Check if discovery agents were recently updated and are now detecting software they previously missed. This can show historical non-compliance that was always there but invisible. Investigate each major non-compliance and determine if it is a real violation or a detection artifact.

Symptom 4: Cost Data Being Wrong

If cost reports do not match your invoices from vendors, cost data might be wrong. Verify that license prices are entered correctly in SAM. Some vendors give different prices for different quantities or terms; confirm that SAM is using the right price. Check if discounts are reflected. Some organizations get volume discounts that should be factored into cost calculations. If cost data is wrong, all financial analysis is wrong.

Symptom 5: Overlapping or Conflicting Licenses

If a computer has multiple licenses for the same software, this is waste. Where to look: run a report of computers with duplicate installations. Determine if both licenses are necessary or if one can be removed. This often happens when merging licenses from different vendors or different business units. Consolidate licenses to eliminate waste.

Symptom 6: False Negatives in Compliance Reporting

If SAM reports that all software is compliant, but you know there are unlicensed installations, the issue is false negatives: SAM is not detecting non-compliance. Where to look: is discovery running on all computers or only a subset? Computers not reporting discovery data are not in SAM, so their non-compliant software is not detected. Are discovery agents up to date? Older agents might not detect newer software. Are compliance rules configured correctly? If rules are checking the wrong field or using wrong criteria, they will not flag non-compliance. Test compliance rules against known non-compliant installations to confirm they work.

Symptom 7: Slow SAM Performance and Scalability Issues

If SAM is slow to run discovery, slow to generate reports, or slow to respond to queries, performance is the issue. Where to look: is the SAM infrastructure over-utilized? Check CPU, memory, and disk space on the SAM server. Is discovery hitting rate limits on client computers? Discovery scans can consume resources, slowing down productivity. Is network bandwidth saturated? Large data transfers from thousands of computers can saturate networks. Solutions include adding server resources, tuning discovery parameters to reduce load, or running discovery during off-hours.

Preventing Common SAM Implementation Mistakes

Prevention is better than troubleshooting. Do not deploy SAM without planning for discovery: scope the effort, estimate timelines, allocate resources. Do not assume license data is complete before importing into SAM: audit license data, remove duplicates, reconcile versions. Do not expect SAM to solve license compliance issues alone: SAM finds problems, but solving them requires process changes (approvals before deployment) and enforcement (removing non-compliant software). Treat SAM as one tool in a comprehensive license optimization program, not as a silver bullet.

Establishing Effective Support and Escalation

When SAM problems occur, who do you contact? Define escalation paths: frontline support can handle simple questions, but who handles performance issues or discovery failures? Ensure that escalation paths reach people with expertise in SAM, in your infrastructure, and in your organization’s software licensing policies. Create a runbook documenting common SAM problems and troubleshooting steps. This runbook dramatically speeds up resolution when issues occur and reduces vendor escalations.

Following the data from the device to the report

Many license optimization problems look like reporting problems, and many of them originate further upstream. A compliance figure that looks wrong has passed through at least four stages: a device reports what it has installed, that installation is matched to a software product, the product is matched to an entitlement and the report applies a rule to the result. A fix applied at the report stage will hide the fault without removing it. Written for the administrator tracing a bad figure back to its origin, this part gives a method that works whichever stage raised the complaint.

A diagnostic table for the most common complaints

When a complaint arrives, classify it by what the person actually observed, then check the stages in the order shown. The second and third columns are the checks; the last column is when to stop and escalate instead of continuing.

A method that avoids chasing the symptom

1. Write down exactly what the person saw, including the report, the date and the filter applied.
2. Reproduce it on the same report, not on a fresh export that may behave differently.
3. Pick the record that best represents the problem and follow it upstream through each stage in the table.
4. Note the first stage where the record disagrees with what you know to be true. That stage is the cause to fix.
5. Correct the source record or the matching rule, not the report output.
6. Re-run the original report and the test cases that touch the same stage, so that the fix does not move the fault elsewhere.

Errors that repeat after they appear fixed

Three patterns cause repeat tickets. The first is a manual correction on a record that the next discovery run overwrites, so the error returns each cycle. The fix is to correct the upstream source or a matching rule, and to log the override so it can be reviewed. The second is a rule that matches a product name too broadly, catching an unrelated product with a similar label. The third is a scheduled import that runs after a manual change and quietly reverts it. Check the job order before blaming the data. The discovery planning post covers how to keep scope tight enough that these collisions are less frequent.

Credentials and coverage gaps that look like license faults

Discovery that cannot log in to a device will often record less than the device holds, and the license report will then look as if the product is under-deployed. Before concluding that a product is unused, confirm that the credentials used for discovery were valid on the devices in question and that the scan reached them. Credential governance, including who may change those credentials and how rotation is handled, is covered in the discovery credential governance post. A coverage gap of this kind should be recorded as a known limitation on the report, so that readers do not treat an absence as evidence of non-use.

When to stop troubleshooting and rebuild a stage

Some faults are not worth diagnosing record by record. If the matching rules have accumulated years of exceptions, if the product catalog contains many near-duplicate names, or if the entitlement records were loaded from three different spreadsheets with no common key, repeated fixes will cost more than a controlled rebuild of that stage. Rebuild in the order the data flows: catalog first, then matching, then entitlements, then reporting. Rebuilding the report alone will not help, because the report is only as correct as the stages beneath it.

Frequently asked questions about troubleshooting

How do we know whether a fault is in the data or in the report?

Take one record and read it at each stage. If the record is correct in the source but wrong in the report, the fault is in the report logic. If the source is already wrong, the fault is upstream.

Should we keep a log of every correction?

Yes, and the log should record the record, the stage, the previous value, the reason and the person who made the change. A log of corrections is often the quickest way to find a rule that is systematically wrong.

Who should be called in first when the fault is unclear?

The person who maintains the matching rules, because many unclear faults turn out to be a rule applying to a case its author did not anticipate. Involve the discovery administrator when coverage is in doubt.

Is it safe to correct compliance figures before an audit?

Only if each correction is traceable to a source document and the original figure is preserved. A correction that cannot be explained will look worse to an auditor than the original fault.

What should be done when the vendor’s own data disagrees with ours?

Record the disagreement with both figures and their sources, then raise it through the vendor manager. Do not silently adjust the internal record to match the vendor’s figure until the difference is understood.

Next step

A recurring fault is cheaper to fix at the stage where it starts than at the report that displays it.