Discovery is a flexible and powerful tool for building a robust and trustworthy CMDB. If you've spent any time troubleshooting or enhancing Discovery, you may share my impression that Discovery Logs take a while to get used to reading. You may have Run network Discovery to add your IP Ranges, or you may have chosen to Import IP ranges into Discovery schedules with import sets . In either case, you probably have IP Addresses in your Discovery Schedules for devices that you cannot authenticate to.
There are many reasons you would see these in your Discovery Logs:
| Created | Level | Short Message | Source | Device |
| 2016-06-17 23:59:29 | Warning | SSH authentication or connection failure | UNIX Classify | 172.21.120.12 |
| 2016-06-17 23:58:35 | Warning | Authentication failure with the local MID server service credential. | Windows Classify | 172.21.120.132 |
In my case, these devices - and thousands more - are things like workstations or network devices that I already have in my CMDB through an integration source like SCCM or CiscoWorks. Sometimes they are Security appliances that Discovery isn't allowed to have Credentials for. On rare occasions they are devices where authentication is failing even though Discovery should have access. With 30k+ of these authentication failures happening daily, a few issues can be observed:
- Security and Systems Administrators take issue with something failing to authenticate to these devices every day. Especially if more than one credential is attempted. (rightfully so!)
- Configuration Management and Service Now Administrators have messy logs to comb through when working with Discovery.
- Discovery Schedules take longer than needed and they can already take all night to run if you have a large CMDB.
Out of the box, excludes can be done manually but it's a tedious process to do it and then later maintain them. The question was asked I decided to work on it and the attached Update Set is what I came up with.
Discovery Status Here is an example Discovery Status where upon completion, a Business Rule has processed the Discovery Logs looking for Authentication Failures. If authentication failures exist, QuickExcludes will query the CMDB looking for Hardware Configuration Items matching those IP Addresses which have Discovery Sources other than Service-Now. When a match is found, an Exclude Parent for the Discovery Source is created within the Discovery IP Range. Any matching IP Addresses with the same Discovery Source will be added to that Exclude Parent. |  |
Discovery Schedule Here is the resulting Discovery Schedule with Excludes added as a Related List to the form view. Note that the Discovery Source "MS SMS" (SCCM) appears multiple times, as does CiscoWorks. This is because the Discovery Schedule is comprised of multiple IP Ranges. Each of these Ranges must have an Exclude Parent to hold any IP Address Excludes within that IP Range. To logically separate the Excludes, an Exclude Parent for each integration source holds all the Exclude Range Item IP's for that Discovery Source. |  |
Manual Excludes From time to time it may be required that IP Addresses should be excluded for reasons other than their presence in the CMDB through another Data Source. In this case, a person with the cmdb_admin role can list select the IP in the Discovery Logs to Manually Exclude those IP addresses. These Excludes will be contained as the others, with the Exclude Parent being the UID of the user who excluded them. |  |
Maintenance Once we exclude an IP Address from Discovery, it becomes necessary to know when to expire that exclusion so that if the IP Address is re-assigned, we will again Discover any device using that IP Address. A scheduled job can be ran nightly to verify that each Exclude still has an Operational Hardware Configuration Item that matches.
Note: Manual QuickExcludes are not checked for hardware records before creation and not removed by the scheduled job. |  |
9 Comments
