Blog

Discover How to Keep Your CMDB Current with ServiceNow Discovery

Kris McCormic

Have you ever wondered what devices are attached to your internal network? Perhaps wondered what software was installed and if those devices are up to date on software patches? Or whether or not a server system is out of date and due for replacement? With ServiceNow’s Discovery, you can answer these questions and much more.

What is ServiceNow?

For those unfamiliar, ServiceNow is a cloud-based platform that integrates nearly all aspects of business from computer network configuration management, problem and change management, to HR tasks, knowledge base, predicative modeling, and much, much more. For this article, we will assume that you would like to track all of the devices attached to your internal business network, their installed software, and know general device status.

What is ServiceNow Discovery?

If you wanted to create a network device catalog by hand, you would need a database (or worse, a spreadsheet) to store all of the relevant information, somehow input this information (likely by hand), and then maintain this information store over time. Accomplishing this goal without information drift can be a tedious and possibly daunting task given an even modestly sized network environment. This is where ServiceNow and the Discovery module can greatly improve accuracy and time to achieve a useful Configuration Management Database (CMDB) repository of computer network information by doing all of this automatically.

Since ServiceNow is a cloud-based platform and it is extremely unlikely that you would allow the outside world to scan your internal network directly, ServiceNow uses a Management, Instrumentation, and Discovery (MID) Server within your network to securely gather information and then relay that information to your ServiceNow main instance. MID servers are free to use with the ServiceNow platform and multiple MID servers can be used simultaneously within physical, virtual, and cloud network environments. Companies can have just a few or hundreds of MID servers depending on the expanse of the network architecture, potentially stretching around the globe.

The MID server uses a clientless discovery (meaning there is no software or client to install on the destination device) to poll devices it can find on your network with SNMP, WMI, SSH, and other discovery methods. A Simple Network Management Protocol (SNMP) poll to a device will return an Object Identifier (OID) that can be matched to a Management Information Base (MIB) of information generally provided by the device manufacturer and found in ServiceNow. Windows devices can provide additional information through the Windows Management Instrumentation (WMI) protocol. Other devices can use Secure Shell (SSH) to execute commands on the destination device to pull general information to help identify the device and its components.

Overcoming Challenges with Discovery

Discovery relies on network and device security to ensure information can be properly collected. The first layer of security is usually the network firewall. Many networks can have multiple layers of firewalls to ensure various parts of the company network are secure even amongst the company itself. Having a MID server in close network proximity to the devices it will gather data is generally more reliable than having to open network ports between a MID server outside a firewall to reach devices within the firewall. Luckily, you are free to have as many MID servers as your network requires.

Discovery typically runs on a schedule set by the ServiceNow system administrator. If a device is not attached to the network when Discovery is run, the device can’t be discovered. This conflict can come into play if general network Discovery is set to run every weekend or every night, but employees take their laptops home every day. Different discovery schedules can be created for various segments of the network. For example, the network segment that contains employee computers can be scanned during the day while servers and other 24/7 network devices can be scanned at night.

Once the MID server can reach the destination device, the MID server must communicate with the device. Simple things like “SNMP is enabled on the destination device” and proper login credentials can often be overlooked when implementing Discovery. The vast majority of “active, couldn’t classify” messages encountered during discovery are due to either disabled messaging services or incomplete credentials on the destination device. If you just want an inventory of devices, read-only credentials will be fine. If you want to expand ServiceNow capabilities to modify the destination device, such as automatically installing software updates and patches, read-write credentials and the Orchestration module are required.

Major device manufacturers are usually very good about providing complete MIB and OID information. ServiceNow has a large existing out-of-box repository of MIBs to match OID returns. But as the manufacturers become smaller and devices more obscure, MIBs may not be pre-loaded and missing within ServiceNow. Fortunately, these smaller manufacturers will often have MIBs you can download to add to your ServiceNow instance. But even if the manufacturer does not provide MIB information, you can create your own identifier using ServiceNow Discovery Pattern Designer to identify and collect device information.

Finally, all of this relies on a cooperative network administrator. Network admins are often very strict about how devices in their network behave and interact (and hey, they have to be!). Discovery requires the MID server to access the devices being discovered, credentials to read the device, and access to the internet ServiceNow cloud instance to report its findings. Failure in any of these areas will cause Discovery to fail and a fussy network admin can cause many unnecessary headaches.

Tips for Discovery Performance

As discussed above, you’re free to install as many MID servers as you like! MID servers can be physical or virtual machines and should have two cores with 8G RAM for generally good performance. MID servers can be used in clusters for further load balancing, generally having a few thousand devices per MID. It’s usually preferred that MID servers be placed behind each firewall segment as opposed to opening firewalls to allow discovery access.

A common hidden MID server performance killer can be anti-virus software. When devices are polled for information, that information payload is written to disk into the Windows “temp” directory by default. Good anti-virus will always scrub the Windows temp directory which means the server will spend a large amount of time scanning SNMP payloads. While keeping anti-virus installed and configured as recommended, you can change the MID server’s default “temp” directory to a location other than the Windows “temp” folder and then whitelist the MID server’s new temp directory. This can improve throughput performance by a factor of five or more!

If your network and MID servers are configured correctly, a typical discovery should take a few minutes to an hour to complete. Even a very large distributed environment of 65,000 devices should take less than five hours to complete a full network systems discovery.

Conclusion

Once configured and running, ServiceNow Discovery is a powerful tool for monitoring the status and health of your corporate network. It can automate the gathering of both routine and advanced system information to populate your CMDB. With a properly populated CMDB, system reporting becomes more accurate, informative, and meaningful for critical business decisions. Enhancing the system further with Orchestration to automate system changes and updates and Service Mapping to evaluate the dependencies and impact of service outages can transform your organization by greatly reducing any instance’s time to resolution.

Kris McCormic

Kris McCormic, Senior Technical Consultant, CDI Southeast

Kris McCormic, Senior Technical Consultant at CDI Southeast, is an experienced information systems architect, business process strategist, and senior application developer with a demonstrated history of working in the information technology and services industry. In his current role, Kris is responsible for being a ServiceNow sales subject matter expert, implementation specialist, and development guru. He is ITIL Certified and is skilled in business process vision, strategy, and implementation, business information architecture, database design, rapid development, and effective communication. Kris holds a BS in Computer Science from Clemson University (Go Tigers!) and in his spare time, enjoys camping, mountain biking, movies, and photography.