I need help consolidating 2 sources of my CMDB

AVIC
Kilo Contributor

I have 2 data sources bringing the same CI but one is more complete than the other.  For example...

 

Service Graph Connector for Intune brings Server-01 with some Data

ServiceNow Discovery Job brings Server-01 with All the Remaining Data

 

The problem is, the Service Graph Connector brings it over as Class: Windows Server (which is not correct it should be a Virtual Machine) and ServiceNow Discovery DOES bring it as a Class: Virtual Machine, which is the correct. 

What is the best way to consolidate this? Have you encountered a Similar issue? I'd appreciate any guidance. 

Right now We're thinking of coding some steps in the Import Set of the Service Graph connector to force any Windows Server to become a VM (Since we know that source should only bring that, but it isn't as dynamic as I feel it should be)

 

Please and Thank  you for your time

2 REPLIES 2

VijayaMannapura
Tera Guru

@AVIC This is expected behavior as a Virtual Machine instantiated might be running with 'Windows Server' as the operating system.

In my experience, they both will have the same name in different case for different class. Similar question was posted yesterday. 

Re: Need to Consolidate 2 Data Sources - ServiceNow Community

Matthew_13
Mega Sage

Hi Buddy,

Yes, I’ve run into this exact situation before, and it’s a pretty common issue when Service Graph connectors and Discovery are both feeding the CMDB.

What’s happening is that Intune is identifying the CI as a Windows Server based on OS data, while Discovery has better visibility and correctly identifies it as a Virtual Machine. When two sources classify the same CI differently, you’ll usually see class conflicts, duplicates, or the record “flipping” depending on which source runs last.

The best long-term fix isn’t to force the class in the import set. That works as a quick workaround, but it’s brittle and can cause problems later. Instead, the goal should be to make sure both sources are updating the same CI and that Discovery is authoritative for the class.

A few things that have worked well for me:

  • Make sure identification is not based on name alone. Use a stable identifier both sources have (UUID, instance ID, serial number, etc.) so Intune updates the CI Discovery already created.

  • Let Discovery own sys_class_name and other classification fields, since it has the strongest evidence for VM vs physical.

  • Allow the Intune Service Graph connector to enrich management and compliance data, but not override the class.

  • If possible, adjust the Service Graph mapping so Intune lands these records in a more appropriate or generic class, and let Discovery refine it.

I’d avoid hard-coding “Windows Server → Virtual Machine” in the transform unless you have a very strong and reliable indicator. Fixing identification and reconciliation will give you a cleaner, more supportable solution long-term.

Hope that helps, and happy to compare notes if you want to dig deeper into the setup.

 

@AVIC - Please mark Accepted Solution and Thumbs Up if you found Helpful 🙂