Troubles with CI Identification?

[DanLevin]

Greetings all,

I am trying to have Discovery update some Configuration Items that were created manually at my organization over the years. I'm unable to "hide" or delete these CIs for audit purposes.

The default Identifiers seem to do the trick for the vast majority of our "infrastructure" CIs, as they "Apply To" the cmdb_ci_hardware table. However, I've run in to a snag for the CIs that reside in tables that are not extended off of cmdb_ci_hardware; such as the Microsoft SQL Database Instance table (cmdb_ci_db_mssql_instance).

If I populate the fields used by the default Identifiers on a manually-created Database Instance CI, Discovery will still create a duplicate, even if the information added is exactly the same as Discovery would find it. The only way I can get Discovery to update these CIs is by adding the "correlation_id" from the duplicate created by Discovery to the manually created CI, deleting the discovered duplicate, and then re-running Discovery.

I tried to experiment around with the default Identifiers by changing the "Applies To" to the cmdb_ci_mssql_db_instance table, and so on — but with no luck. Is there something I'm missing?

Default Identifiers:

Example:

I'm trying to get the "Name & Class Name" Identifier to work here. I've already updated the manually-created Configuration Item to have the same name that Discovery uses when it creates a duplicate of this CI.

Before Discovery (Manually created CI renamed by me):

After Discovery - Manually-created CI on top, Discovery-created duplicate below:

Here's the Discovery Schedule:

I've attached a .txt file of the input from "WMI: Active Processes (nodes: 62)" in the ECC Queue.

Any help would be GREATLY appreciated, thanks!

Dan

[DanLevin · Accepted solution]

I figured I'd reply to my own post to share some knowledge that I've found.

After researching this question further, I feel confident in saying that the approach I was looking to implement above will not work. Though the "Applies To" table can be changed on the Identifiers, they simply do not apply beyond the "Infrastructure" layer, as the Discovery tool finds CIs in these classes during the "Exploration" phase.

This realization was a tough one for me to come to, and I'm sure that others have found themselves in the same pair of shoes. However, my "workaround" DOES WORK consistently. I figured that I would reiterate it here so that other members of the Community may benefit from it.

CIs that have been manually-created that are not on the "Infrastructure" can be updated by Discovery, but it requires a few steps.

1) Run Discovery and identify the manually-created CI, and the duplicate created by Discovery.

2) Obtain the "correlation_id" from the Discovery-created duplicate CI. The "correlation_id" is created when a CI is imported to Service-Now, via Discovery, import set, or an integration.

3) Add the "correlation_id" from step 2 to the "correlation_id" field on the manually-created CI.

4) Delete the Discovery-created duplicate CI.

5) Re-run Discovery. The manually created-CI will now be updated.

I'm sure this process could be partially or entirely automated in some way, but I'll be the first to admit that such a task is outside of my realm of knowledge. I'd welcome any assistance there!

While this method does work, it requires that close attention be paid to the comparison of existing manually-created data to Discovered data. It is disappointing that updates to manually-created CIs will require an initial duplication of the record, even if they are only present for a a brief amount of time.

[thomas81]

hi,

can across the very same issue with SQL instance in Jakarta.

Unfortunately, the 'correlation id' field for the auto discovered entries are empty - so not sure if this process no longer applies to later editions.

For the SQL Instances - I found that by matching the identifier requirements (ie name and instance fields need to match the discovered data) then it work.  This meant we changed the our SQL instances to match the auto discovered ones, ie;

CI name = SQL_instance@server_name

Instance = SQL_instance

Once this was done - discovery updated the required CI.

Hope this helps.

Thomas

[Runjay Patel]

Check out this video, it will clear all your doubts and help you to understand Discovery queries in details.

Link: https://www.youtube.com/watch?v=30JbWVsusyE&t=10s&ab_channel=ServiceNowHelpdesk

It help you to understand below points.

• Discovery Overview
• Discovery prerequisite
• Understanding Discovery Phases in details
• Discovery credentials and IP Affinity
• Mid Server Management with Cluster and Load Balancer
• Schedule jobs
• Set up discovery from scratch to end
• Live implementation with real world data.
• Troubleshooting on various aspects
• Many more other issue related to mid server, CIs
• Cloud discovery
• Service Mapping

Please mark reply as Helpful/Correct, if applicable. Thanks!!