Autodiscovery Best Practices
This page explains how Device42 builds comprehensive device profiles through sequential discovery and device matching. For operational best practices on planning, configuring, and scheduling discovery jobs, see Discovery Job Best Practices.
Device42 uses agentless, automated device discovery tools to collect inventory data and populate the Configuration Management Database (CMDB). The discovery tools work seamlessly in the background and are not network-load intensive. You can schedule multiple autodiscoveries per day or hour, with frequency depending on how rapidly your environment changes.
Recommended Discovery Sequence
You can run discovery jobs in any order, but Device42 recommends the following sequence to minimize reconciliation work and build more complete device profiles. For a comprehensive list including Storage, Certificate, Warranty, and other discovery types, see Discovery Job Order.
Network Discovery (SNMP)
Network autodiscovery builds your Layer 2 network landscape and discovers network devices, VLANs, subnets, IP addresses, MAC addresses, and connectivity information. Run this first to establish the network foundation.
Hypervisor Discovery (V-Server)
Hypervisor autodiscovery collects data from virtualization platforms such as VMware, Citrix Xen, libvirt, and oVirt. This discovers hosts, virtual machines, and initial operating system information.
Windows, Linux, and Hyper-V Discovery
OS-level discovery brings in detailed Windows, Linux, and Hyper-V machine data, including CPU counts, RAM, software, services, and configuration details.
Cloud Discovery
Cloud autodiscovery discovers virtual machines and storage from cloud platforms including Amazon Web Services, Microsoft Azure, Cloudstack, OpenStack, and other providers.
Blade Discovery
Blade server autodiscovery identifies blade chassis, blade servers, and their physical locations within the chassis. Device42 matches this data to previously discovered devices using serial numbers to build comprehensive blade profiles.
IPMI Discovery
Intelligent Platform Management Interface (IPMI) provides out-of-band management data for physical servers. Run IPMI discovery last because it may not have accurate hostname information, but Device42 reconciles it with servers discovered by other methods using serial numbers.
How Device42 Matches Devices
Autodiscovery uses serial number, UUID, and device name (in that order) to determine whether discovered data updates an existing device or creates a new device. When matching by name, Device42 also checks device aliases.
Device42 uses the latest discovered information for existing devices. For example, if a device record shows two CPUs and autodiscovery detects three CPUs, the newer discovered data overrides the previous entry.
Comprehensive Discovery Profiles
Don't be alarmed if one autodiscovery method doesn't provide the level of detail you were expecting. As more auto discoveries are run, Device42 constructs a comprehensive device profile by matching data such as the serial number, UUID, and device name collected during subsequent discovery stages.
Example Discovery Scenario
The Network discovery identifies the switch, its serial number, the number of ports to the switch, and the MAC addresses associated with each port.
The V-Server (Hypervisor) discovery identifies the Hypervisor’s IP and MAC address data that links it to the Network discovered switch port data. This discovery adds hosts, virtual machines, and operating system information to the Device42 CMDB.
The next level, blade discovery, identifies the Serial Number and adds it to the Device42 CMDB, along with details about the chassis and the slot where the blade is located in that chassis.
The native Windows and Linux OS discovery matches the Serial Number and UUID. The new data is added to Device42 including the number of CPUs associated with the VM, the amount of RAM, VM version, version number, and other OS-related information.
In the example above, you'll find out which blade server is in which chassis slot, what network ports or chassis the blade server is connected to, what VMs are on that blade server (if it's a Hypervisor), all the services that are running on those VMs, and all the software installed on those VMs.
The result is a comprehensive profile of the discovered devices, their characteristics, locations, software, and the physical and virtual interdependencies between the devices. The discoveries populate the CMDB with detailed records and uses that information to construct Device42 impact and dependency mapping charts.
User Account for Autodiscovery
Do not set up an autodiscovery scan using critical production account credentials. Create a separate, dedicated account to use only for discovery.
Account lockout could result in an otherwise avoidable outage depending on your permissions and configured password policies.