Hardware models created by Service Graph Connectors do not match existing hardware modelsIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } When Service Graph Connectors (SGCs) insert or update configuration items (CIs), the hardware models selected by the platform do not match hardware models that already exist in the CMDB. This can result in multiple hardware models that appear to describe the same device family, each with its own set of related CIs and assets. The connectors are working as designed, but their output does not align with pre-existing hardware models that were created outside the SGC flows. Symptoms<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } You may be experiencing this issue if: You already maintain hardware models in cmdb_hardware_product_model (for example, manually created, imported, or created through other processes such as catalog loads or ASN) with names that include commercial or ordering context, such as: Display name: Dell Inc. Latitude 5000 Series 210-BLSTName: Latitude 5350 (210-BLST) After onboarding Service Graph Connectors (for example, Microsoft SCCM or Microsoft Intune), newly discovered CIs are linked to hardware models with simpler names based on the discovery source data, such as: Display name: Dell Inc. Latitude 5350Name: Latitude 5350 The CMDB now contains more than one hardware model that you consider to represent the same device family, but: CIs discovered through SGC consistently attach to the SGC-created model, andAssets or CIs coming from other processes remain attached to the pre-existing model. Removing or merging the "extra" hardware model appears to help temporarily, but new hardware models continue to be created or re-used by subsequent SGC runs.SGC runs show no errors in the staging tables, Robust Transform Engine (RTE), or Identification and Reconciliation Engine (IRE) logs; the only visible concern is the proliferation of hardware models. Facts<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The following points describe what is happening from a Service Graph Connector and CMDB perspective: Hardware models are stored in cmdb_hardware_product_model, which extends the product model hierarchy and is the target for model_id on CIs and assets.SGCs such as the Service Graph Connector for Microsoft SCCM and Service Graph Connector for Microsoft Intune load device data into staging tables (for example, sn_sccm_integrate_sccm_2019_computer_id for SCCM computer identity), including manufacturer and model values.During transformation, the SGC flows use hardware model resolution logic based on the manufacturer and model strings from the source data. Out of box, this is implemented with the MakeAndModelJS script include (and helpers) to either: Find an existing hardware model that matches the given manufacturer/model combination, orCreate a new hardware model record when no match is found. SGCs do not evaluate or understand why a pre-existing hardware model was created (for example, catalog, ASN, earlier discovery, or manual creation). They simply pass manufacturer/model values into the model resolution logic and then attach the CI to whatever hardware model MakeAndModelJS returns. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All releases of Service Graph Connector for Microsoft Intune Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This behavior occurs when there is a mismatch between how pre-existing hardware models were defined and how Service Graph Connectors resolve hardware models from discovery data. Pre-existing hardware models Hardware models already exist in cmdb_hardware_product_model, often with naming that reflects ordering SKUs, series names, or internal catalog conventions (for example, Latitude 5000 Series 210-BLST). Discovery data from SGC sources SGC staging records coming from SCCM, Intune, or other sources carry manufacturer and model values that reflect what the endpoint or inventory system reports (for example, Dell Inc. and Latitude 5350). Model resolution behavior The SGC transform passes these manufacturer and model values into MakeAndModelJS (often through a "cleanse model" or similar operation).If MakeAndModelJS finds an existing hardware model that matches the manufacturer/model combination, it reuses that model.If no matching hardware model is found, MakeAndModelJS creates a new hardware model using those strings (for example, Dell Inc. Latitude 5350). Resulting additional model creation From the platform's perspective, both the pre-existing curated model and the SGC-resolved model are valid entries in cmdb_hardware_product_model.From a process perspective, they appear as duplicates because they both represent the same device family but with different naming or metadata.SGC will continue to use the model selected by the resolution logic as long as the manufacturer/model strings from the source remain the same. The Service Graph Connectors are working as expected and designed in this scenario. If the pre-existing model and the potential SGC-created model resolved to the same string, the additional model would not have been created due to a match. However, the incoming data from the source environment results in a different model name format than the pre-existing model. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } There is no OOB solution to this issue from the Service Graph Connector perspective. Customization would be required to force a specific model name, rather than the current behavior of concatenating the manufacturer + model ID as they are received from the connector's source environment. Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } N/A