Servers and Virtual Machines
About This Series
ITOM over-spending rarely begins at renewal. It begins at implementation, when the team making architecture decisions does not realize those decisions are also licensing decisions. This six-part series breaks down how ServiceNow ITOM Subscription Units are triggered across each resource category – Servers and VMs, PaaS Resources, Containers, FaaS Resources, End User Computing Devices, and Unresolved Monitored Objects.
Each part covers one category in full: how SUs are triggered, which ingestion paths are available, what real-world exposure looks like, and where teams most reliably get it wrong. The goal is not a licensing overview. It is an architecture guide – the decisions that determine what you pay, made before anyone thought to ask.
Part 1 starts with Servers and VMs. They are typically the largest SU driver in enterprise environments and the category where the gap between Discovery scope and ITOM scope is most often invisible until renewal.
One framework note that applies across all six parts: a resource can exist in the CMDB without consuming a Subscription Unit. Three conditions must all be true before a CI counts – it is in a table mapped to a licensable category, it is in scope for an ITOM product, and any category-specific requirements are satisfied. Unresolved Monitored Objects are the exception to this framework: a UMO is counted when ITOM Health receives an event or metric that cannot be resolved to any CI in CMDB, independent of CMDB table mappings or ITOM scope configuration. Note that certain connector types – specifically endpoint-oriented Service Graph Connectors – may affect SU consumption even for resources not yet in full ITOM management scope. Confirm connector-specific behavior with your ServiceNow account team before relying on scope exclusions as a licensing control.
The Core Distinction
A server consumes one Subscription Unit when two conditions are both met: its CI type is configured as licensable for the relevant ITOM subscription, and it falls within the scope of that ITOM application as evaluated by the ITOM Licensing module.
Servers that reside in the CMDB on CI types not configured as licensable, or that are excluded from ITOM application scope, do not consume Server SUs. This is the distinction most implementations miss – and it is not subtle. It is the entire cost model.
The two primary levers that determine Server SU count are:
CI type mappings – which CI types are designated as licensable
ITOM application scope – which CIs are actively counted by the Licensing module
Defining these deliberately before Discovery runs is the core licensing discipline for the Server category.
What This Means in Practice
Both agentless Discovery and ACC-V produce Server CIs at the same 1:1 ratio. Collection method has no effect on the SU count.
Discovery and ACC-V can each provide rich runtime context including dependencies, software, and interfaces. This does not alter the SU ratio.
The scoping question is not how to ingest servers – it is which servers should be in ITOM scope before Discovery runs.
Under default platform configuration, a server discovered and classified into a standard server CI type will consume an SU. Assume every server Discovery finds will be included in the next daily CI count unless you have taken deliberate action to prevent it – either by placing it in a CI type not mapped as licensable or by defining an explicit exclusion in the ITOM Licensing module. That configuration should happen before Discovery sweeps, not after.
Ingestion Paths
The table below covers the two primary ways Server CIs enter the CMDB and their SU implications. The ratio does not change based on ingestion method. The only variables are CI type mapping and ITOM scope configuration.
Ratios in this series reflect the ServiceNow ITOM Subscription Unit Overview effective February 1, 2024. Customers contracted prior to that date may be subject to different ratios. Confirm which version governs your executed agreement before using these figures for planning or renewal modeling.
|
Ingestion Path
|
How It Works
|
Example Tools
|
SU Ratio
|
Counts?
|
|---|---|---|---|---|
|
IP-Based Discovery / Agentless, MID Server-driven
|
Network scans using credentials and classification patterns via MID Servers
|
MID Servers, Discovery patterns
|
1:1
|
YES - by default, any server classified into a standard server CI type will consume an SU
|
|
ACC-V Agent / Agent-based, push-based
|
ACC-V agent installed on servers; pushes data on schedule or event trigger
|
ACC-V on servers
|
1:1
|
YES - same ratio, same default behavior
|
|
Architecture Note
|
ACC-V is the right path for servers hard to reach via agentless scans, including segmented networks, hardened operating systems, and VDI environments. The SU outcome is identical to agentless Discovery. The choice between methods is an operational one, not a licensing one.
|
|||
Real-World Scenario: Server Scoping
A mid-size enterprise runs Discovery across a broad IP range to build CMDB completeness. Their network contains 800 servers: 400 are production systems actively managed by ITOM applications, 250 are dev/test systems the platform team tracks for asset purposes only, and 150 are decommission-pending systems with no active workloads. The Discovery schedule sweeps all 800.
|
Approach
|
Servers Discovered
|
ITOM-Managed
|
Server SUs
|
Unintended SUs
|
|---|---|---|---|---|
|
Undifferentiated Discovery - no exclusions configured
|
800
|
800 - all classified into standard server CI types, no exclusions defined
|
800
|
400 unintended - dev/test and decommission-pending servers consuming SUs with no operational return
|
|
Intentional ITOM Scoping - exclusions configured before Discovery runs
|
800
|
400 - production only; dev/test and decommission-pending excluded via CI type mappings or ITOM Licensing module configuration
|
400
|
None - excluded servers remain in CMDB for asset tracking but do not consume SUs
|
|
Key Takeaway
|
Both approaches produce identical CMDB coverage. The difference is 400 Server SUs, eliminated not by changing the discovery tool or method, but by configuring which servers should count before Discovery runs.
|
|||
Common Misconceptions
“Using ACC-V instead of agentless Discovery reduces our server SU count.”
Both agentless Discovery and ACC-V produce Server CIs at 1:1. Collection method has no effect on the ratio. Server SU count is determined by which CI types are mapped as licensable and which servers have been excluded in the ITOM Licensing module – not by how the data was collected.
“We can avoid Server SUs by classifying production servers into non-licensable CI types.”
Using separate CI types to keep genuinely out-of-scope servers outside ITOM licensing is valid and intentional design. Deliberately misclassifying production servers that are actively managed by ITOM applications simply to suppress SU counts is a license-evasion pattern that creates significant audit exposure. The distinction between intentional scoping and evasion is whether the classification reflects operational reality.
Scoping Pitfall to Address Before Discovery Runs
Under default platform configuration, every server Discovery finds and classifies into a standard server CI type will consume an SU. There is no automatic separation between what Discovery sweeps and what ITOM counts.
If you intend to exclude dev/test, decommission-pending, or otherwise out-of-scope servers, that exclusion must be configured in the ITOM Licensing module before Discovery runs – not after those CIs are already in CMDB. Retroactive cleanup reduces future exposure but do not assume it eliminates the SUs already captured in prior daily counts. Validate the effect in the ITOM Licensing dashboard and with your account team.
Closing: What to Check Before the Next Discovery Run
If any of the following questions produce uncertainty, that uncertainty has a dollar value attached to it.
- Are dev/test, decommission-pending, and non-production servers excluded from ITOM scope in the Licensing module, or do they exist in the CMDB with no exclusions defined?
- Were CI type mappings reviewed before the first Discovery schedule ran? Has that review been repeated as the environment has changed?
- Is there a documented process for adding servers to ITOM scope that treats the scoping decision as a licensing decision – not just an infrastructure one?
None of this requires a licensing audit. It requires one structured look at the ITOM Licensing dashboard, CI type configuration, and Discovery scope definitions. In most environments, the largest reduction opportunities are visible within the first few hours of examining the right data.
Up Next: Part 2 – When Cloud Speed Erases the Math
Part 2 covers PaaS resources – the category where the more favorable 1:3 ratio creates a false sense of security. Cloud environments provision at a velocity that no ratio advantage can offset at scale, and unlike servers there is no architectural workaround that reduces exposure without reducing what you manage. The only lever is deciding which resources should be in ITOM scope before the Service Graph Connector goes live.
