Windows, Linux, and Hyper-V Server Auto-discovery
Windows Auto-Discovery Tool
The Auto Discovery Client is an external tool that runs on a Windows machines either standalone or as a service. It auto-discovers information about Windows servers, Linux servers, and Hyper-V virtual machines.
The client can be downloaded by going to the Device42 Autodiscovery Software page and downloading the “Auto Discovery Software”.
Installation requirements and instructions for setting up auto discovery client.
- Install Microsoft .NET Framework 4
Standalone Installer available at:
- Install Auto-discovery client
Download installer from: http://www.device42.com/autodiscovery/
After running installation, you can find the application in your Start Menu.
The silent install works if it can successfully stop the service in a small amount of time. The problem is that if the a discovery is running the service will not stop until the discovery can be gracefully terminate (which could take a bit of time). The solution would to to stop the service, wait and then if the process is still running kill it and then perform the install. The key is to make sure the process is not running when you run the silent install.
Under the Settings tab you will have sections for System, Credentials, and Exclusions.
You can enter your Device42 credentials here to allow the application to upload the auto-discovered data directly to Device42.
The Task Threads value allows you to limit the amount of task threads the application will spawn during auto-discovery. You can use this to reduce the strain on your network if you are concerned about scanning a higher amount of systems.
You can choose to ignore common services, software, and software patterns to avoid pulling in services or software that are typically not tracked by users. The lists used are available at https://github.com/device42/AutoDiscoverIgnoreFiles
By choosing “New” from the dropdown you will be able to define all the credentials to be used in the Auto-discovery process. For Windows credentials you can enter a local or domain user who has privileges to execute Remote WMI calls. You can also opt to use the current credentials of the logged in user.
You can enter a test address to verify that a server is accessible from the Auto-discovery application.
You can use the Exclusions section to list listening or remote ports that you would like excluded from auto-discovery. For instance, adding port 22 to the excluded Unix ports will exclude adding the service port for ssh if you are not interested in seeing ssh connections in Device42.
You can exclude remote connections by IP address and port as well. This is convenient if there are known connections to any of your devices that you are not interested in bringing in to Device42.
The Discovery section will allow you to setup and save multiple auto-discovery jobs for Windows, Unix, and HyperV machines.
By choosing “New” from the dropdown for Settings you will be able to setup a new auto-discover job. The settings for the fields are as follows:
|Name||The name for the auto-discover job|
|Credentials||Choose one of the credentials that were setup in the Settings tab|
|Device Name||Choose from one of the options to set the device name. See below for details|
|Ignore||You can choose to ignore OS name, UUID, Serial Number, Domain Suffix, and/or IPv6 address|
|Options||You can choose to Give host name precedence, Discover Services, and if you have the add-ons, discover software and/or applications|
|Service Level||These values will be pulled from Device42 and will allow you to import the discovered servers at a given service level|
|Customer||These values will be pulled from Device42 and will allow you to associate the discovered servers with a particular customer|
|VRF Group||These values will be pulled from Device42 and will allow you to import the discovered servers to a particular VRF Group|
|Discover by||Here you can choose CIDR Blocks, Host Names, or IP Ranges to perform the auto-discovery|
|Criteria||When Using Host Name or CIDR Blocks to auto-discover you can enter the host names or CIDR blocks in a comma separated list|
|IP Range||When using IP address auto-discovery you can enter a single ip address or a range in this section|
|Exclusions||If you would like to ignore ip’s in a range, you can enter them here|
For Windows Autodiscovery by Domain Server, if you would like you can use a custom filter and enter an LDAP query to filter the results to exclude the discovery of certain devices:
will search the domain server for all computers with dns hostname - d42sus.pvt and autodiscover the matches.
This is where you will see information about the last run status of the auto-discovery job.
Device Naming Options
With recent changes to the Device42 Auto-Discovery tool it is now possible in v10.1.1 add/update the Device Name of any targets with the Hostname plus Domain Name.
This will allow the ability to add devices with the possible FQDN of the device, also will allow the option add discovered names as an alias rather than replacing the Device Name.
From the Discovery tab, you can set your options and any default actions you would like for devices that are discovered. Here you can also find a field for “Device Name”.
- Hostname as discovered
- Hostname plus domain name as discovered. If domain name already exists in the hostname, it will not be added again.You may need to set “Ignore Domain Name” for best functionality.
- Hostname and add Hostname plus Domain name as alias. This is the default and recommended setting.
- Hostname plus Domain name and add Hostname as alias..
In order to set the Device Name as a possible FQDN of the device, you will want to make sure you select an option that includes “Hostname plus Domain Name”
In the Information section you have the ability to see Recent Messages which will allow you to follow the progress of your autodiscovery jobs.
The Search Logs section will allow you to enter search criteria to check the log files if you have problems with any of the autodiscovery jobs.
If you have trouble with auto-discovery using the application, we now have a section that will allow you to generate a log bundle to send to the Device42 team for diagnosis. This section allows you to set the location of the logs, select which logs to keep, and to generate a bundle.
In the tasks section you can set as many different auto-discovery schedules as needed to cover your environment in the Schedules section. You can choose which days of the week, and whether you want to run the job at a specific time, or every X hours, as well as which discoveries to run.
In the Status section you will see the last status of each of your autodiscovery jobs.
Here are some limitations and considerations:
- If you have Device42 populated with devices before your first run of this tool, please make sure to run this on few devices first to make sure the naming convention used by you and the one discovered by this tool are compatible. (For example: you added nh-linux01 as a device. Then, auto-discovery finds the hostname nh-linux01.example.com and adds it as a new device because the names don’t match. To fix this, you can check the checkbox above to use only hostname)
- It is best to use the auto discovery client after you have run network auto-discovery and/or defined the subnets where IPs belong to.
- Floating IPs that belong to a cluster logically but are found on a device during auto-discovery will be assigned to the device instead of the cluster resource.
- You can run it from any(and multiple) network segment, just need to allow access to port 443(HTTPS) from auto-discovery client to the device42 appliance in your network.
- Please be sure to use an Administrator account. If you use at “Local System account”, it will not work correctly for other machines in the network.
Getting the WMI settings correct can be a little tricky, but these general rules should get you on track. First, please ensure at least read-only access for the autodiscovery user to the following WMI Namespaces:
- virtualization (Hyper-V only)
- virtualization\v2 (Hyper-V only)
- MicrosoftIISv2 (Only for IIS)
- Microsoft\SqlServer (Only for SQLServer)
- SMS (Only for SCCM)
Firewall Rules to Enable
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
Services to Enable and Set to Automatic
- Remote Procedure Call (RPC)
- Windows Management Instrumentation
The Hyper V Server hardware details and the name, UUID, and MAC addresses are pulled in from the VMs.
If you are already using SCCM in your environment or are planning to use it, the Device42 SCCM integration can now automatically grab the hardware and software inventory data.
The user account you supply must have permission to access the SCCM instance. You can add a user in SCCM under “Administration”; Choose “Administrative Users”. The user I tested with happened to be an SCCM Admin, but the “Read-only Analyst” role should be enough, as it “Grants Permissions to view all Configuration Manager Objects”, and the import is a read-only operation from the SCCM perspective.
Using a Private Key for Linux Authentication
In the Credentials setting, you will see an option to use a Private Key for linux credentials.
The last step in the process will be to check the Private Key checkbox as indicated above. However, before you do that you will need to generate public and private keys.
To generate a private key:
1. Download puttygen.exe from: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (or you can google for Putty key generator).
2. Run the puttygen.exe
3. Generate a public/private key pair. 4. Export the private key as an openssh key.
Next, add the generated public key to your linux servers under the .ssh/authorized_keys file.
Linux Auto-discovery has been tested on Redhat, Debian, CentOS, Ubuntu, and Oracle distributions and probably will work on similar linux distributions that have python intsalled. (You can confirm this by checking to see if your platform supports the following commands:
OS: /usr/bin/python -m platform
Manufacturer, Hardware and Serial # : sudo /usr/sbin/dmidecode -s system-manufacturer (and system-product-name, system-serial-number)
IP Info: /sbin/ifconfig -a
CPU Info: from /usr/sbin/dmidecode
There are several commands ran in the linux autodiscovery process that, by default, typically require root privileges. These are: dmidecode, fdisk, and hdparm. If you are running autodiscovery as a non-root user, you will have better results adding those commands to the sudoers file for the user or a group:
%your-group-here ALL = (ALL) NOPASSWD:/usr/sbin/dmidecode, /sbin/hdparm, /sbin/fdisk
Adjust the file paths as needed to match the location of each program. If this permission is missing, auto-discovery client would not be able to find hardware, manufacturer, serial #, and so on.
You might also have to comment out Default Requiretty in /etc/sudoers file.