_
_
When it comes to populating the CMDB via ServiceNow Discovery, the expectation is it will just work. We all desperately want to “set it and forget it.” However, the reality is that while ServiceNow Discovery is a fantastic solution for populating the CMDB, if it cannot login to an IP then the failures are going to start piling up. And. . . they will keep repeating with every run of the Discovery schedule. It’s better to have a plan to reduce the load or else your job will soon be taken up by managing the pile up.
Anyone who has attempted to address the various reasons of why ServiceNow Discovery is not able to classify, A.K.A login to, any number of targets, can put together a short list of legitimate reasons to add each IP to a blacklist. Some of the top reasons are Domain Controllers, vendor proprietary appliances, VIPs, or the device is discovered via another method rather than IP (e.g. ESX hosts). For a long time managing such a blacklist has been an administrative headache because Exclusion records (discovery_range_item_exclude) had to be created for every subnet that the IP was included in. It’s easy to imagine the administrative overhead each audit of the exclusion table takes.
One of the underrated features released in Rome is the Global Exclusion List. In fact, I’m still geeking out about it. Here’s the breakdown. The related list is available by default on every Discovery schedule.
The Global Exclusion List is a table of IP Exclusions records. These records are the highest organizational element to the solution. This is where you get to manage the “excluded” IP Collection record. I really appreciate the thought behind this design element. It’s easy to determine which exclusions are active and provide a report to auditors that contains a described reason.
Once an IP Collection record is created, one of three lists can be created: IP Address List, IP Range, or Subnet.
Table Schema
As you can see it’s easy to create an exclusion (detailed instructions). The real beauty of the solution is how it works. It is as simple as it should be. The active Global IP Exclusions are applied to EVERY discovery schedule. That’s it. Botta-bing. Botta-boom! You are DONE!
Well, ok, you can be done, but I am not. Now the fun can begin. Let’s get to where process design meets efficiency and remove the administrative overhead of managing this list from the hands of the Discovery Admins. Why? If you were to stop here, Discovery Admins would be forced to triage discovery failures AFTER they happen. To make the headache worse, tracking down the responsible group can prove to be quite difficult when there is no CI in the CMDB yet 😳. What a time suck! Now, take it one step further and consider blacklist maintenance. IP addresses get recycled, and someone has to own the responsibility to remove the IP from the blacklist when that happens. Let’s cut the fat out of this forsaken process and get the work to the right people - the ones with all the answers and can benefit the most from such a list. Infrastructure Ops teams often have various reasons to maintain a list of appliances, be it patching, PCI, or another reason. Active Directory teams need to keep a list of DCs. The list goes on and you get the idea, so put the power to solve multiple operational issues into the Managed By Group’s hands. The solution has two parts:
An IP can only be added/removed to the Discovery Blacklist by a member of the asset’s “Managed By Group.”
There you have it. These non-discoverable CIs are organically maintained in the CMDB by the team that manages their lifecycle. The same teams can get ahead of Discovery failures (no more Discovery failure escalations!) by adding the CI during the build process. Finally, these otherwise individually maintained lists have been consolidated to the CMDB for all to access and report on. Hot dog! Now that’s some lean process engineering. I think this is when I can drop the mic. Peace out.
