Windows, Linux, and Hyper-V Server Auto-discovery
Windows Auto-Discovery Tool
The Auto Discovery Client is an external tool [.NET based] that runs on a Windows machines, either standalone or as a service. It auto-discovers detailed information about Windows Servers, Linux / UNIX / *nix Servers, Hyper-V Hypervisor and Virtual Machine Guest inventories, and can also import CI data [API –> API] from Microsoft SCCM Instances. See our HowTo on using the Agentless Autodiscovery tool here.
The Discovery Client Software can be downloaded on the Device42 Autodiscovery Software page. Press the orange “DOWNLOAD” button under “Windows based Auto Discovery Software (ADS)”.
Installation requirements and instructions for setting up auto discovery client.
Install the Microsoft .NET Framework 4. There is a Standalone Installer available at: https://www.microsoft.com/download/en/details.aspx?id=17718
Install the Auto-discovery client. Download the installer at: https://www.device42.com/autodiscovery/.
After running installation, you can find the application in your Start Menu.
The silent install will fail if for whatever reason, it is unable to successfully stop the service in a short time period. If a discovery is running, the service will not stop until the discovery can be gracefully terminated (which could take a bit of time). The solution is to stop the service, and then wait; if the process is still running, kill it and then proceed with the installation.
The key here is to ensure the process is not running when you attempt to run the silent installation.
Under the Settings tab you will have sections for System, Credentials, and Exclusions.
System Sub-Menu - Device42 System Settings
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:
|Settings||Select Pre-Configured Jobs from this dropdown|
|Name||Your chosen name for the auto-discovery job|
|Credentials||Choose one credentials for the discovery 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, IPv6 address, and/or Virtual Subtype|
|Options||You can choose to give the host name precedence, Discover Services, and if you have the add-ons, discover software and/or application inventory|
|Device Category||Choose from Device Categories you’ve configured within Device42. Selecting ‘Override’ will replace existing categores with the current selection.|
|Service Level||These values are pulled from Device42 and allow you to set the Service Level on the discovered devices.|
|Customer||These values are pulled from Device42 and allow you to associate discovered servers with the selected Customer.|
|VRF Group||These values are pulled from Device42 and allow you to assign the discovered servers to the selected VRF Group.|
|Discover by||Here you can choose CIDR Blocks, Host Names, or IP Ranges, or Domain Servers to perform the auto-discovery against|
|Criteria||When Using Host Name or CIDR Blocks to auto-discover, you can enter the host names or CIDR blocks in comma separated list form|
|IP Range||When using IP address auto-discovery, you can enter a single IP address or an address 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 by entering an LDAP query to filter the results, excluding discovery of certain non-matching 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
The Device42 Auto-Discovery tool can add or update the Device Name of any targets with the hostname format of your choosing. Device42 can combine discovered Hostname with the Domain Name [Option: ‘Hostname plus Domain Name’]. You can also add the name as discovered (hostname) as an alias, rather than replacing an existing device’s name by choosing the option ‘Hostname and add Hostname plus Domain Name as Alias’. This option adds devices with the hostname as discovered as the device name, and the FQDN as the alias. Full details below.
From the Discovery tab, set your desired options, and choose the desired “Device Name” option from the dropdown.
- 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 to the FQDN of the device, make sure you select an option that includes “Hostname plus Domain Name”.l
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.
The Summary section displays a summary list of results of recent discovery attempts against a list of discovered IPs, including a date and timestamp. Looking at the summary is a quick way to determine if discovery against a specific IP succeeded or failed, and if failed, if the failure was possibly due to instance residing on the IP being unreachable [‘TCP Ping’], or maybe because of authentication errors [‘Authenticated’]. A value of ‘True’ in the ‘Sent to D42’ column means that CI data in the Device42 CMDB was updated for that particular line’s instance.
Tasks (Task Schedules)
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 populated Device42 [CSV imports, spreadsheets, manual entry, etc.] with devices before your first run of this tool, please make sure to run this on a few devices first to make sure the naming convention used by you and the one discovered by the 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 your network IPs reside on.
- Floating IPs that belong to a cluster logically but are found on a device during auto-discovery will be assigned to that device, and not the cluster resource.
- You can run the .NET Discovery tool from any (and multiple) network segments. Communication from the auto-discovery client back to the main Device42 instance requires access via port TCP/443 (HTTPS) to be allowed on your network.
- Please be sure to use an Administrator account. If you use the “Local System account”, discovery will not work correctly for other machines in the network.
Windows Discovery Information
Getting the WMI settings correct can sometimes seem a bit finicky, but these general guidelines should serve to get you on track.
- First, please ensure at least read-only access for the autodiscovery user account 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)
- MSCluster (Only used if “Discover Cluster Information” is selected)
- 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
- Enable access to IPC & ADMIN shares
- Device42 utilizes the IPC and ADMIN shares to obtain service port communication details in Windows discovery. These shares should be enabled and accessible over port 445 or inter-device communications will not be discovered.
If you are discovering servers that do not belong to a domain, there may be issues due to UAC settings. Please refer to this MSDN article for information regarding UAC’s effects on WMI.
The Hyper-V Server’s hardware details and its 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 automatically sync the hardware and software inventory (CI) data to Device42.
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 we tested with in the lab was an SCCM Admin, but the “Read-only Analyst” role should be plenty, 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: https://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (or you can google for PuTTY key generator - Download it from PuTTY directly).
2. Run puttygen.exe
3. Generate a public/private key pair. 4. Export the private key as an openssh key [as pictured below].
Next, add the generated public key to your Linux servers under the .ssh/authorized_keys file. Ensure permissions and owners are properly set; Permissions on the key itself should be 600, and the .ssh directory should be set to 700:
$ chmod 700 .ssh && chmod 600 .ssh/mykeyfile && chown myuser:myuser .ssh/mykeyfile
Linux Auto-discovery has been tested against Redhat, Debian, CentOS, Ubuntu, and Oracle distributions and should work fine against just about all similar linux distributions that have python installed.
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 that are run as part of the Linux autodiscovery process that, by default, typically require root privileges. We do extensive testing to see which commands we can run without sudo while still obtaining all available information. The following is a table of commands we sometimes or always run as sudo. For the “Sometimes” commands, we’ll try to run the command first without, and if we receive a permission denied command rather than an “invalid command”, “command not found” or similar we’ll attempt to run as sudo. This list will also say if it’s ran on every linux/unix flavor or only certain platforms:
|zlogin||Always||Solaris (For Zones)|
Below you can see an example of how to allow a particular user or group to run a specific sudo command without being prompted for password: ~~~ %your-group-here ALL = (ALL) NOPASSWD:/usr/sbin/dmidecode, /sbin/hdparm, /sbin/fdisk ~~~
Adjust the above paths as needed to match the location of each program. If these permissions are missing, the auto-discovery client will not be able to discover hardware, manufacturer, serial #, and so on, as well as service dependencies and valuable application configuration information.
You might also have to comment out Default Requiretty in /etc/sudoers file.