Device Discovery Best-practices Using Device42

With its agent-less, automated, device discovery tools, Device42 automates a significant portion of building an accurate picture of a user’s IT infrastructure. These device discovery tools work seamlessly in the background to “collect” inventory data and then populate Device42’s Configuration Management Database (CMDB).

Auto-discoveries can be scheduled to ensure the accuracy of the CMDB, based on each client’s unique requirements. Because theseauto-discoveries are only collecting and reporting inventory data, the process is not network load intensive, and clients can schedule manyauto-discoveries in a single day or even a single hour. The frequency of auto-discovery is often dependent on the amount of change occurring within the data center the more change, the more frequent auto-discoveries should be scheduled for.

While the discoveries can be run in any order, we recommend the following order to minimize some reconciliation work later on.

1. Network: Network auto-discovery builds your L2 Network landscape and pulls in your network devices inventory, VLANs, Subnets, IP Addresses, Mac Addresses, etc.
2. V-Server: V-Server auto-discovery collects data from hypervisors such as VMware,Citrix Xen, libvirt and oVirt), Windows/Linux/Hyper-V which will bring in Windows, Linux, Hyper-V machines), and cloud auto-discovery
3. Blade: Blade server auto discovery identifies the blade chassis, the s blade servers, and their location within the chassis. By matching serial numbers to previously discovered data, Device42 builds a comprehensive blade database (see note below).
4. IPMI: Intelligent Platform Management Interface defines a set of interfaces used by system administrators for out-of-band management of computer systems and monitoring of their operation. We recommend this as last to run because IPMI might not have the correct hostname of the machine, but it will reconcile with a server discovered by any of the methods discussed above based on serial number.

Don’t be alarmed if oneauto-discovery method does not provide the level of detail you were expecting. As you run subsequent auto-discoveries, Device42 constructs a comprehensive device profile by matching data such as serial number, UUID, and device name that is collected during subsequent discovery stages.

For example:

• The Network discovery identifies the switch, its serial number, the number of ports to the switch, and MAC addresses associated with each port.
• The V-Server (Hypervisor) discovery will identify the Hypervisors’ IP and MAC address data that links it to the Network discovered switch port data. This discovery adds hosts, virtual machines, and operating systems information to Device42’s CMDB.
• The next level, Blade discovery, identifies the serial number, linking it to the Device42 CMDB, while adding the chassis, and the slot where the blade is located in that chassis.
• The external .net auto-discovery tool matches the serial number and UUID, and adds new data to Device42 including the number of CPUs associated with the VM, the amount of RAM, and any other OS-related information (version and version number) specific to that VM.

So in the example above, you can find out what blade server is in which chassis slot, what network ports it is connected to (or chassis is connected to), what VMs are on that blade server (if it happens to be Hypervisor) and all the services that are running on those VMs and all the software that is installed on those VMs.

The result is a comprehensive profile of the devices, their characteristics, locations, software, and the physical/virtual interdependencies between the devices. This not only populates the detailed CMDB records, but also serves as the data for constructing Device42’s impact and dependency mapping functionality.

Additional information regarding auto-discovery can be found on Device42’s support portal: /autodiscovery/