CMDB reconciliation

They describe the same estate and they do not agree, and by the fifth business day one of those counts has to become the driver for the Compute Tower allocation. Most programs resolve this with a spreadsheet and a judgment call. This post walks through a CMDB reconciliation run the other way: as a pipeline with defined inputs, a matching step, five variance classes, and one validated count as the output. The run is described for the Servers Sub-Tower because that is where the sources are richest, but the shape holds for storage and network.

Step 1: Pull the populations, not the counts

The first mistake in most reconciliation efforts is comparing totals. The CMDB says 4,200, the hypervisor says 4,050, someone declares a 150-server problem, and the investigation starts from the wrong end. Totals hide offsetting errors. Fifty ghosts and fifty orphans net to zero and look like a clean CMDB.

Pull full populations instead, with the identifying fields each source carries. From the CMDB: CI name, class, serial number, environment, operational status, last discovered timestamp, and the discovery source that last updated the record. From the hypervisor: VM inventory name, host, power state, guest hostname if the tools report it. From the endpoint agent: hostname, last check-in, operating system, hardware serial where the agent captures it. Add the ITAM hardware list for physical hosts, with serial and disposal status. Four populations, four key schemes, one estate.

Step 2: Resolve identity before you compare anything

The hard engineering problem in CMDB reconciliation is that the same server has a different name in every system. The CMDB carries the short hostname in uppercase. The endpoint agent carries the fully qualified domain name in lowercase. The hypervisor carries an inventory label someone typed in 2019. The ITAM record carries a serial number and nothing else.

Identity resolution is the step that turns those into one entity. In practice it is a cascade: match on serial number where both sides have it; fall back to normalized hostname (lowercased, domain suffix stripped, known prefixes handled); fall back to a composite of MAC address or hardware UUID where an agent exposes it; and only then to fuzzy matching on name, with a confidence score and a human review threshold. Every match records which rule made it, because a match made by rule four will be disputed and you will need to show your work.

ServiceNow's own CMDB does a version of this on the way in. Its Identification and Reconciliation Engine uses identification rules to prevent duplicate CIs and reconciliation rules to restrict which data source may write which attribute. That governs data entering the CMDB. The reconciliation run described here sits outside the CMDB and asks a different question: does the CMDB population, as it stands today, agree with what the other systems can see?

FogLifter's ontology is the mechanism for this step in our platform. It normalizes naming conventions across sources, reconciles overlapping keys, and records the authoritative source per attribute, so a server known three ways resolves to one correlated entity before any count is taken. The same approach handles storage, where the identity chain runs from array LUN to datastore to virtual disk to VM, and where FogLifter validates 27 PB of storage in one deployment. That is a single deployment figure, not a typical result, and the storage identity chain is a separate post; it is mentioned here because the principle is identical.

Step 3: Classify every CMDB reconciliation variance into one of five classes

Once identity is resolved, the comparison produces one row per entity with a presence flag per source. The rows that are present everywhere and agree on attributes are done. The rest fall into five classes, and the class determines the owner and the Tower effect.

Ghost: present in the CMDB, absent from the hypervisor and the endpoint agent, no check-in past the staleness window. The server almost certainly no longer exists. Tower effect: the Servers Sub-Tower count is inflated and the hardware maintenance allocation is spread across assets that consume nothing.

Orphan: present in the hypervisor or the endpoint agent, absent from the CMDB. The server exists and was never registered or was registered under a class the export did not include.

Tower effect: consumption with no CI to carry cost; the allocation either ignores it or dumps it into a default Sub-Tower.

Duplicate: two or more CMDB CIs resolved to one physical or virtual entity. Usually two discovery sources each created a record under its own key. Tower effect: the count is overstated and any showback built on it bills the consumer twice.

Stale attribute: present everywhere, but the CMDB's environment, owner, location, or operational status disagrees with what discovery reports. Tower effect: cost routed to the wrong Sub-Tower Element (production versus non-production) and downstream to the wrong Solution.

Unclassified: present and matched, but the CI class or Sub-Tower tag maps to nothing in the Taxonomy. Tower effect: cost accumulates under a generic label where nobody looks.

The classification is mechanical once the rules are written, which is the point. Two engineers running the same rules on the same inputs get the same five lists. Judgment enters at disposition, not at classification.

Step 4: Route each class to its owner and record the disposition

Ghosts go to the infrastructure or platform team that owns decommissioning, with a proposed action: retire the CI, or prove the host is alive. Orphans go to the CMDB steward with the discovery evidence attached: register the CI, or explain why it should be excluded. Duplicates go to whoever owns identification rules, because a duplicate is a rule failure before it is a data failure. Stale attributes go to the CI owner named on the record, and if that owner has left the company, that is its own finding. Unclassified rows go to the TBM office, because a class the Taxonomy cannot place is a mapping decision, not a data fix.

In FogLifter this routing happens in the Validation View, where each side of a variance sees the same evidence and the disposition is written back with the reason and the authoritative source. The write-back matters more than it sounds. A disposition recorded in a spreadsheet cell is gone by next month's run. A disposition recorded against the entity persists, so next month's run starts by checking whether last month's ghosts were actually retired, not by rediscovering them.

Step 5: Publish one count with lineage

The output of the run is not a cleaned CMDB. It is one Servers Sub-Tower count, per environment, with the following attached: the sources consulted, the matching rules applied, the number of entities in each variance class, the dispositions applied, and the residual variances still open with their owners. That is the number that goes into the Compute Tower allocation. When a business unit disputes its share of Compute in showback, the answer is the lineage, not an analyst's recollection.

The run then recurs at the cadence of the close. The first run is large. The third run is mostly new provisioning and new decommissioning, because the standing defects were dispositioned on the record and stayed dispositioned.

Conclusion

Before the next close, pull the four populations for one environment and run the matching cascade, even in a spreadsheet, recording which rule matched each row. Classify the residue into the five classes and count each class. That count is your first honest picture of what the Compute Tower allocation has been inheriting. Then assign each class an owner who is not the TBM analyst and get one class fully dispositioned before the run repeats. Cleanup fixes records. Reconciliation fixes the count, and the count is what the model consumes.

To see a reconciliation run on your own CMDB, hypervisor, and endpoint data, book a demo.

Frequently asked questions