Migrating from Cisco Intersight ITSM Plugin to Service Graph Connector
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi everyone,
We are currently encountering an issue with duplicate CIs in our CMDB after migrating from the deprecated Cisco Intersight ITSM Plugin to the Service Graph Connector for Cisco Intersight, and I would like to ask for recommendations on the best remediation approach.
Current Situation:
Previously, we were using the Cisco Intersight ITSM Plugin for discovery/integration. Since the plugin is already deprecated, we replaced it with the Service Graph Connector for Cisco Intersight.
After installing and configuring the Service Graph Connector, it imported all Cisco devices from Intersight into the CMDB. However, most of these devices already existed in our CMDB from the previous plugin integration.
Issue
The newly imported CIs were created as new records instead of updating or reconciling with the existing ones, resulting in duplicate CIs.
One thing we noticed is that:
- In the previous plugin, most Cisco devices were classified under generic classes such as Cisco Servers.
- In the Service Graph Connector, devices are now being created under more specific and different CMDB classes.
Because of this class mismatch:
- Identification and Reconciliation Engine (IRE) did not match them correctly.
- No duplicate CI remediation tasks were created.
- Existing CIs and newly imported CIs are now coexisting in different classes.
Questions
- What is the recommended approach for remediating these duplicate CIs?
- Has anyone encountered a similar issue when migrating from the legacy Cisco Intersight ITSM Plugin to the Service Graph Connector?
- Are there any best practices for preserving relationships, history, and dependent records during remediation?
Any recommendations, migration experiences, or best practices would be greatly appreciated.
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @pr8172510
I am currently encountering another issue related to the Service Graph Connector for Cisco Intersight.
Previously, I was able to successfully retrieve all devices from Cisco Intersight using the Service Graph Connector. However, I started facing duplicate CI issues because we were previously using the deprecated Cisco Intersight ITSM Plugin.
To provide context, I performed some testing in our environment:
- We originally had 3 existing CIs under the Cisco Server class created by the previous plugin.
- After implementing the Service Graph Connector (SGC), another 3 duplicate CIs were created, but this time under the Cisco UCS Blade class.
To remediate the duplicates, what I did was:
- Deleted the 3 CIs created by the Service Graph Connector.
- Changed the class of the 3 old CIs (created by the previous plugin) from Cisco Server to Cisco UCS Blade.
My expectation was that after changing the class, the next execution of the scheduled import (SG-Cisco Intersight Data) would recognize and update the existing CIs using the same IRE identification rules instead of creating duplicates.
However, after doing this, the scheduled data import stopped working completely, and I am now encountering connection/import errors.
As part of troubleshooting:
- I already re-entered the API Key and API Secret Key.
- I am still using the exact same credentials that previously worked when I was able to successfully retrieve all devices.
Despite this, it now seems that the connection between ServiceNow and Cisco Intersight is no longer working.
Has anyone encountered a similar issue after modifying CI classes or remediating duplicate CIs during migration from the legacy plugin to the Service Graph Connector? Any recommendations or best practices would be greatly appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @pr8172510
I am currently encountering another issue related to the Service Graph Connector for Cisco Intersight.
Previously, I was able to successfully retrieve all devices from Cisco Intersight using the Service Graph Connector. However, I started facing duplicate CI issues because we were previously using the deprecated Cisco Intersight ITSM Plugin.
To provide context, I performed some testing in our environment:
- We originally had 3 existing CIs under the Cisco Server class created by the previous plugin.
- After implementing the Service Graph Connector (SGC), another 3 duplicate CIs were created, but this time under the Cisco UCS Blade class.
To remediate the duplicates, what I did was:
- Deleted the 3 CIs created by the Service Graph Connector.
- Changed the class of the 3 old CIs (created by the previous plugin) from Cisco Server to Cisco UCS Blade.
My expectation was that after changing the class, the next execution of the scheduled import (SG-Cisco Intersight Data) would recognize and update the existing CIs using the same IRE identification rules instead of creating duplicates.
However, after doing this, the scheduled data import stopped working completely, and I am now encountering connection/import errors.
As part of troubleshooting:
- I already re-entered the API Key and API Secret Key.
- I am still using the exact same credentials that previously worked when I was able to successfully retrieve all devices.
Despite this, it now seems that the connection between ServiceNow and Cisco Intersight is no longer working.
Has anyone encountered a similar issue after modifying CI classes or remediating duplicate CIs during migration from the legacy plugin to the Service Graph Connector? Any recommendations or best practices would be greatly appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi All,
I am currently encountering another issue related to the Service Graph Connector for Cisco Intersight.
Previously, I was able to successfully retrieve all devices from Cisco Intersight using the Service Graph Connector. However, I started facing duplicate CI issues because we were previously using the deprecated Cisco Intersight ITSM Plugin.
To provide context, I performed some testing in our environment:
- We originally had 3 existing CIs under the Cisco Server class created by the previous plugin.
- After implementing the Service Graph Connector (SGC), another 3 duplicate CIs were created, but this time under the Cisco UCS Blade class.
To remediate the duplicates, what I did was:
- Deleted the 3 CIs created by the Service Graph Connector.
- Changed the class of the 3 old CIs (created by the previous plugin) from Cisco Server to Cisco UCS Blade.
My expectation was that after changing the class, the next execution of the scheduled import (SG-Cisco Intersight Data) would recognize and update the existing CIs using the same IRE identification rules instead of creating duplicates.
However, after doing this, the scheduled data import stopped working completely, and I am now encountering connection/import errors.
As part of troubleshooting:
- I already re-entered the API Key and API Secret Key.
- I am still using the exact same credentials that previously worked when I was able to successfully retrieve all devices.
Despite this, it now seems that the connection between ServiceNow and Cisco Intersight is no longer working.
Has anyone encountered a similar issue after modifying CI classes or remediating duplicate CIs during migration from the legacy plugin to the Service Graph Connector? Any recommendations or best practices would be greatly appreciated.
