Note: Available only for new signups after the 31 March, 2026 release. If you signed up earlier, refer to the existing ITAM documentation.

Autodiscovery is based on your unique requirements and can be scheduled to keep your CMDB updated. The process is not network load intensive because autodiscovery only collects and reports inventory data. You can schedule many autodiscoveries in a day or even in an hour. The autodiscovery frequency depends on the amount of change occurring in the data center, as more change requires more frequent autodiscovery jobs.

This article provides an overview of autodiscovery best practices and logic. It includes information on how to schedule discoveries to keep your CMDB updated, the recommended sequence for initial discovery, and how the system reconciles data across different scanning methods to build comprehensive device profiles.

Building comprehensive discovery profiles

As more autodiscoveries are run, a comprehensive device profile is constructed by matching data such as the serial number, UUID, and device name collected during subsequent discovery stages. This information is used to construct impact and dependency mapping charts.

Initial discovery sequence

While the discoveries can be run in any order, the following order is suggested to minimize reconciliation work:

• Network: Network autodiscovery builds your Layer 2 network landscape and pulls in your network devices inventory, VLANs, subnets, IP addresses, MAC addresses, and more.

• V-Server: V-Server autodiscovery collects data from hypervisors such as VMware, Citrix Xen, libvirt, and oVirt.

• Windows/Linux/Hyper-V: This stage brings in Windows, Linux, and Hyper-V machine data.

• Cloud autodiscovery: This brings in virtual machine and storage data from Amazon Web Services, Microsoft Azure, Cloudstack, OpenStack, and other platforms.

• Blade: Blade server autodiscovery identifies the blade chassis, blade servers, and their location within the chassis. By matching serial numbers to previously discovered data, a comprehensive blade database is built.

• IPMI: Intelligent Platform Management Interface (IPMI) defines a set of interfaces used for out of band management and monitoring. It is recommended to run this last because IPMI might not have the correct hostname, but it will reconcile with a server discovered by other methods based on serial numbers.

Matching devices

Autodiscovery checks against the serial number, UUID, and name, in that order, to determine if it should update an existing device or create a new one. When looking for a name, the system also looks at any aliases that exist for a device.

The latest discovered information on an existing device is always used. For example, if there was a manual change to a device stating it has two CPUs, and an autodiscovery job pulls information for this device with three CPUs, the newer discovered data overrides the old entry.

Execute an autodiscovery scan

To run an autodiscovery scan and aggregate data, follow these steps:

1. Go to Admin > Asset Management > Scan and discover.

2. Select the discovery method based on the recommended sequence (Network, then V-Server, then OS-specific scans).

3. Configure the discovery profile by entering the IP range or cloud credentials.

4. Schedule the discovery frequency based on your data center change rate.

5. Click Save and Run.

Caution: 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.

Example discovery scenario

To understand how data is aggregated, consider the following flow:

1. Network discovery identifies the switch, its serial number, the number of ports, and the MAC addresses associated with each port.

2. V-Server (Hypervisor) discovery identifies the hypervisor’s IP and MAC address data that links it to the network switch port data. This adds hosts, virtual machines, and operating system information to the CMDB.

3. Blade discovery identifies the serial number and adds details about the chassis and the slot where the blade is located.

4. Native OS discovery (Windows/Linux) matches the serial number and UUID. New data is added, including the number of CPUs, RAM, VM version, and other OS related information.

The result is a comprehensive profile of the discovered devices, their characteristics, locations, software, and the physical and virtual interdependencies.