CMDB Data Mismatch Report Showing OS Mismatch Between Discovery Payload and CI Record

[Deebika]

Hi Team,

I am seeing a mismatch in the OOTB CMDB Data Mismatch Report and would like to understand the best approach to resolve it.

CI Details
CI Name: bp-rtr-test03

Actual CI Record
OS: Windows Server 2019 Standard

Discovery Source: ServiceNow

Discovery Payload for this ci bp-rtr-test03
OS: Windows 2019 Standard

CMDB Data Mismatch Report:
For the same CI, the report shows:
1.Discovery Source: ServiceNow
OS Value: Windows 2019 Standard
2.Discovery source:Tanium
OS Value: Windows Server 2019 Standard

As a result, the CI is appearing in the data mismatch report.

Reconciliation Configuration:
Tanium Priority = 1
ServiceNow Priority = 1
Tanium owns the OS attribute for the Computer class.
ServiceNow does not own the OS attribute (OS is not present in the available slush bucket for ServiceNow on cmdb_ci).

Requirement
The business requirement is to have 0 records in the CMDB Data Mismatch Report while still using the OOTB report.

Questions
1.Since ServiceNow does not own the OS attribute, is this expected behavior?
2.What is the recommended approach to achieve zero mismatches?
3.How to Normalize the OS values between Discovery and Tanium? (Give me step by step instructions to do it)
4.Use identification/reconciliation rules differently?
5.Any OOTB-supported solution?

[ayushraj7012933]

Hi @Deebika ,

Yes, this can be expected behavior.

The important thing here is that reconciliation determines which source is allowed to update the CI, while the CMDB Data Mismatch report is comparing values coming from different data sources. So even if Tanium has ownership of the OS attribute, Discovery can still have a different OS value in its payload, which can be reported as a mismatch.

In your example:

• ServiceNow Discovery → Windows 2019 Standard
• Tanium → Windows Server 2019 Standard
• Tanium owns the OS attribute
• ServiceNow does not own the OS attribute

I would not change the reconciliation priority just to make the mismatch report reach zero.

Recommended approach

I would first normalize the OS value coming from both sources.

For example, decide on one canonical value:

Windows Server 2019 Standard

Then make sure both Discovery and Tanium ultimately provide/resolve the OS information to the same normalized value.

How I would troubleshoot it

1. Check the actual OS value generated by Discovery

Run Discovery for bp-rtr-test03 and check the Discovery status/payload.

Confirm exactly what Discovery is sending for:

os

If Discovery is sending:

Windows 2019 Standard

then the difference is already present before reconciliation.

2. Check the Tanium source

Verify the value being sent by Tanium for the same CI.

In your case:

Windows Server 2019 Standard

Also verify that both sources are identifying the same CI. This is important because an identification issue can sometimes look like a reconciliation issue.

3. Check the OS normalization configuration

Go to:

CMDB Workspace → Data Manager / Data Foundations → Identification and Reconciliation

and review the relevant identification/reconciliation configuration for the Computer class.

Also check the normalization configuration for the OS field. The goal is to map variations such as:

Windows 2019 Standard

and

Windows Server 2019 Standard

to the same normalized OS value.

If you have CMDB Data Manager / normalization capabilities available in your release, use the OOB normalization functionality rather than creating a custom script to update cmdb_ci.os.

4. Verify the normalized value on the CI

After normalization runs, check the CI and verify that the OS is represented consistently.

Then run the Discovery again and allow the Tanium integration to process the CI.

5. Recheck the mismatch report

Once both source values are represented consistently, allow the CMDB Health/Data Mismatch calculation to run again and verify whether the mismatch is cleared.

Should you change IRE/reconciliation rules?

I would say no, not for this problem alone.

Reconciliation priority answers:

"Which source is allowed to update this attribute?"

It does not answer:

"Are the values from different sources semantically the same?"

Therefore, changing:

Tanium Priority = 1

or

ServiceNow Priority = 1

will not necessarily solve the mismatch.

If Tanium is the authoritative source for OS, I would keep that ownership and focus on getting the source values normalized consistently.

One more thing to check

I would also verify whether the mismatch report is comparing the raw source value or the normalized CMDB value in your particular release/configuration.

If the report is intentionally showing raw source values, then having:

Windows 2019 Standard

versus

Windows Server 2019 Standard

may still appear as a source-level mismatch even though the CI's normalized OS is correct.

So I would not recommend trying to achieve "0" by manipulating discovery_source, reconciliation priority, or manually updating the CI.

The preferred flow should be:

Discovery/Tanium → Identification → Normalization → Reconciliation → CMDB

rather than:

Discovery/Tanium → different raw values → custom script to force the CI value

If the business requirement is specifically that the OOTB CMDB Data Mismatch Report itself must show 0, I would first confirm exactly which table/fields the report is using in your release, because the solution can differ depending on whether the report is evaluating source payload values or normalized CMDB values.