Azure SQL Resources Reclassified from cmdb_ci_database to cmdb_ci_cmp_resource Causing Duplicate CI
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
We are investigating an issue in our CMDB related to Azure SQL resource onboarding through the Azure Service Graph Connector.
Current Behaviour
We have observed that Azure SQL resources (Microsoft.Sql/servers/databases) are initially created in the cmdb_ci_database.
However, after some time (typically during a subsequent connector run), the same CI is reclassified to cmdb_ci_cmp_resource.
When the next import occurs, the connector appears unable to identify the previously reclassified record and creates a new CI, resulting in duplicate Cloud Resource records.
Example Flow
- Azure SQL Database imported.
- CI created under cmdb_ci_database.
- Later the CI class changes to cmdb_ci_cmp_resource.
- Next Azure import runs.
- Identification process does not match the existing reclassified CI.
- New CI is created.
- Duplicates continue to accumulate over time.
Investigation Performed
- Verified duplicate records exist in cmdb_ci_cmp_resource.
- Reviewed Identification Rules for affected classes.
- Analysed Identification Simulation results.
- Checked CI audit history.
- Investigated Azure Service Graph Connector configuration.
- Reviewed Robust Transform Engine related configurations.
- Verified that records originally existed under database classes before being moved.
Questions
- During CI class reclassification, are Identification Rules evaluated?
- What mechanism performs the class switch from cmdb_ci_database to cmdb_ci_cmp_resource?
- IRE?
- Service Graph Connector Entity Operations?
- Robust Transform Engine?
- Class Switching Framework (glide.class.switch.enabled)?
- Where can the reclassification logic be traced?
- Has anyone seen Azure SQL resources automatically reclassified from database classes to cloud resource classes?
- What is the best way to identify which process or transform performed the class change if audit history does not clearly show the source?
Additional Context
- Source: Azure Service Graph Connector
- Affected Resources: Microsoft.Sql/servers/databases
- Duplicates are created daily after reclassification occurs.
- Looking to understand the exact point where target class determination and class switching happen.
Any guidance on where to trace this behaviour or similar experiences would be greatly appreciated.
Thank you.
0 REPLIES 0
