sabell2012
Mega Sage
Mega Sage

This is the second, and probably final, installment of a two-part article on our implementation of Discovery. Part 2 describes things to watch out for, and recommended best practices with implementation.




[*]DANGER: If you have manually entered information in CMDB_CI, or any of the underlying hierarchy, Discovery may (and probably will) overwrite the data. You absolutely do NOT want this to wipe out all your hard-won data (and the AM team will probably hunt you down and hurt you if you do). AM needs to be inputting their data into the Asset Management application anyway. If you do have a significant amount of CMDB_CI data you will need to look at migrating BEFORE you turn Discovery on.

[list=a]
[*]Discovery looks at Serial Numbers. There is a Serial Number table that is created. Get familiar with this as well! If you ever have to reset a particular discoverable CI you will need to delete serial number, IP, and other records that are used by Discovery to restore the data. This may require some playing around with to understand how it all works. Before implementing to production you will need to become familiar with how to cause Discovery to reset a CI.

[*]If you have fast expire IP address leases you will probably need to really watch this during the discovery process as IP addresses are used for identification as well.


[*]There are a significant number of devices that will return a DNS, but fail to classify. You will spend a lot of time with network and system engineering chasing these down.

[*]I advise staying away from activating Asset Management / Discovery AND Software Asset Management (SAM) at the same time. Roll SAM out later. The data will still be collected by Discovery, but it will be a full-time position for someone on the AM team, and will require work from the Discovery administrator as well. Focus on hardware and VMs to begin with.

[*]Get familiar with the MID Server installation Wiki. It will be your friend for a while. Focus on the problems section at the end. You will eventually have the entire article memorized! (and you will be able to quote from it extensively to your management, software engineers, and network engineers to prove you are right on a particular communication failure, and more importantly that they were wrong!)

[*]With Calgary Patch 2 there were a lot of fixes to Discovery. Several issues were corrected. An especially nasty one was the "Shazzam SLP scanner error on input records: "ArrayIndexOutOfBoundsException - 1" error that kept a number of network devices from being completely discovered.

[*]WARNING: ServiceNow does NOT do SNMPv3 (and probably won't until the F-release in 4Q2014; at least that is what we have been told...I hope it is much sooner than that). You will need to contact a company that integrates to ServiceNow. We currently have everything v2c, but will need v3 in the future.

[*]WARNING: Lack of data normalization WILL bite you. Your Model and Manufacturer tables will fill up with garbage. Example: HP, Hew. Pack., Hewlett Packard, Hewlett Packard, Inc., etc. Garbage-In (at the factory) Garbage-Out from Discovery into your tables! This will need to be dealt with or you will drive you and your Asset Management group crazy! Get familiar with Normalization! With a little bit work you should be able to reduce this by, oh, 50%. Probably.

[*]WARNING: Running multiple jobs simultaneously (greater than three) from a single instance can and probably will cause that instance to drop in performance (knocks it to its knees!). My advice: Keep the number of jobs running at the same time to three or less. Especially if they are tapping on things with the IP B-level.

[*]We have implemented Help-the-Help-Desk for all laptops (and desktops now) that link in via VPN. This was necessary as the work-from-home and sales/marketing crowds often are not online when the scans run. The HtHD script helps keep everything current, and I highly recommend implementing this in conjunction with Discovery. See the HtHD wiki for details on implementation.


Be aware that after (or even during) your implementation of Discovery you will find that you need to track more data than what is provided OOtB. This is normal. You WILL find things that you need. Since ServiceNow is a PaaS (Platform-as-a-Service) it is designed to be modified to fit your business needs.

I hope this helps those of you considering implementation of Discovery at your workplace.

End of part 2, end of article.

Enjoy!

Steven Bell
Santander Consumer USA, inc.
Dallas, TX

3 Comments