Reconciliation rule not working on Windows server table

[venkram]

Hello Everyone,

Recently we have created a reconciliation rule on Windows Server table and we keep first priority is ServiceNow and second priority is SG-SCCM ad third priority is SG-Intune and we have selected apply to all attributes.

the issue is SG-Intune is still updating Operating System, OS Version and Disk Spaces fields even though SG-SCCM is already updated. Could someone please help me.

@Ankur Bawiskar 

@Dr Atul G- LNG 

@AJ_TechTrek 

[ayushraj7012933]

Hi @venkram ,

This kind of issue is usually related to how reconciliation and data source tracking are working in CMDB.

Even though you’ve set the priority as:

• ServiceNow

• SG-SCCM

• SG-Intune

and applied it to all attributes, a lower priority source like SG-Intune can still update fields if a few things are not configured properly.

First, check the discovery_source on the CI record. Reconciliation depends heavily on this field. If SG-SCCM is not correctly setting discovery_source = SG-SCCM, the system won’t treat it as a higher priority source, and SG-Intune may overwrite those values.

Next, make sure the data is going through the Identification and Reconciliation Engine (IRE). Reconciliation rules are only enforced when IRE is used. If updates are coming through transform maps without enabling “Use IRE”, or via scripts/direct updates, then these rules can be skipped. So it’s important to ensure that “Use IRE” is enabled and the correct data_source is mapped.

You should also check the sys_object_source table. Each CI should have proper entries for both SG-SCCM and SG-Intune. If these entries are missing, ServiceNow may treat incoming data as new or unmanaged, which allows overwrites.

Additionally, review your reconciliation rule again. Make sure there are no conflicting rules. If the issue continues, you can create attribute-level rules for specific fields like Operating System, OS Version, and Disk Space. This gives you better control compared to applying the rule to all attributes.

Finally, I’d recommend enabling IRE debug logs by setting:
cmdb.ire.debug = true

Then run updates from both sources and check the logs. They will clearly show which source is updating the fields and why the system is allowing it.

[IanCox]

Short version: Intune isn't "beating" reconciliation — your rule almost certainly isn't being evaluated in the first place. That's a multisource data-governance gap more than a platform bug. Check three things, in order:

1. Class match. Reconciliation definitions are evaluated against the CI's actual class. If Intune's payload lands at a different level than where your rule sits (cmdb_ci_win_server vs. cmdb_ci_computer/hardware), the rule never fires. Confirm the definition is on the exact class Intune writes to.
2. Source stamping. Precedence only protects a value when the prior write is recorded in sys_object_source with a recognized discovery_source. If SCCM's update isn't flowing through IRE (createOrUpdateCIEnhanced) — e.g., a transform map writing the CI table directly — there's no authoritative source on record, so Intune wins by default. Every integration has to go through IRE or precedence is meaningless.
3. Rule specificity. An attribute-level reconciliation definition always beats your "apply to all attributes" rule. Look for a competing definition on OS / OS Version / Disk.

Turn on IRE debug logging and re-run one Intune update — the log tells you exactly why it allowed the write. Nine times out of ten the real fix is process: define source-of-truth per attribute per class, and force all sources through IRE.

If you want a structured way to tackle this, multisource reconciliation cleanup is exactly what we do at Four Dragons: