I have a large number of Manual Enpoint CIs. What should I do with them?

[Mason Angus]

I have a large number of these "Manual Endpoint" CIs in my CMDB. They all have the same name "Manual Endpoint" and don't appear on dependency maps. The also all have the discovery source of "Service Watch". These look like junk to me. I have a couple questions related to this:

1) What is a "Manual Endpoint"

2) Why would a CI not appear on a dependency map? I do not have any filters turned on when displaying the map

3) What is "Service Watch"? Is this an old name for service mapping? And if we don't have that module enabled why would that be a data source?

4) How do I disable a CI class/find the probes that are being used to discover a particular CI class

Thanks!

[Kieran Anson]

Hi Mason,

Service Watch (created by Neebula) is the predecessor of Service Mapping. This makes me believe the CI's your referencing to be old demo data. If this is part of an enterprise environment you could raise a request on HI for demo data to be removed from one of your non-prod instances and see if these CI's are removed. 

Note: the demo data removal request removes all demo data which you may or not be utilising, it is best to test this in a non-prod environment first and validate before requesting in a production instance.

Remove Demo Data HI Support

Also check on whether the CI's have a similar created / updated / last discovered time as that help allude to whether or not it is in fact demo data

[DaveHertel · Accepted solution]

Hi - 

 Q #1: manual endpoints are manually-created (i.e. entered manually be humans).  these are sometimes needed when automation won't work for various reasons.

 Q #2: The basic requirement for a CI to show on the dependency map is a relationship between 2 CI's with a relationship type of something like Depends On.. or Used By... etc.   
Note, service maps are not the same as a dependency map (just in case that is part of your question... I'm not sure).   The dependency map reveals various CI's that have some kind of relationship/dependency to each other.  The CI's found in a dependency map are not exclusive to a service as they can span a lot of needs/uses.  But a service map is generally focused on the CIs for SPECIFIC service (of course there are exceptions, but this is a easy way to think about it)

Q #3: the discovery source name: Service Watch is what a CI is assigned to when it was found via Service Mapping.  This name, while a confusing reference to a product SNOW bought (7?) years ago, its not indicative of demo data... rather, its expected when Service Mapping discovered the CI.  A better source name would have been something more intuitive... (and didn't refer to a legacy product... ugh).

Q4: Generally classifiers (found under Discovery) are responsible for triggering probes or patterns to classify XYZ type of things and record them as CIs.  If you really don't want X CI being discovered, the classifiers can either be deactivated or modified. .. just be sure you really want this because if you touch OOB stuff, future updates to these objects will be ignored during upgrades.

Hope this helps?

[Mason Angus]

Thanks Dave. Related to the 4th question, I have a follow up question. I have several CI classes that I wanted to view their classifier. For instance, I have a class "Storage Volume" which extends the "Configuration Item" class. I have searched the probes, patterns, and classifiers tables for a "Storage Volume" classifier with various queries (name contains "storage volume", table name contains "cmdb_ci_storage_volume") and have come up blank. Is there a more efficient way to discover what classifier is responsible for a given class? 

[DaveHertel]

Hi - not really, nothing i can think of... other than starting with the "All" filter under classifiers and then doing wild-card * searches on the table column, for the class you seek.

Hope this helps?