- Installation Pre-Requisite for Discovery
- Windows WMI and WinRM Discovery Settings Overview
- Device Naming Options and Preventing Duplicates
- Configuring Windows Hostname Discovery Details
- Auto Discovery Schedule
- General Considerations
Installation Pre-Requisite for Discovery
Prior to running a Windows Discovery, you must install the Windows Discovery Service (WDS) on at least one Windows system which will connect to the Device42 Main Appliance or a Remote Collector! For more information on WDS / WDS installation, please visit the Windows Discovery Service (WDS) installation documentation.
Navigate to the Discovery menu and select HyperVisors / *Nix / Windows, this section will allow you to setup and save multiple auto-discovery jobs for Windows, Hyper-V, and other platforms.
Click on “Add Hypervisors/*nix/win for Autodiscovery” in the top right to start job creation.
Windows WMI and WinRM Discovery Settings Overview
Selecting “Add Hypervisors/*nix/Win for Autodiscovery” to start your setup of a new Windows / Hyper-V Auto-discovery job.
To specify Windows WMI-based discovery, change the “Platform” to Windows. For Windows/Hyper-V WinRM-based discovery, choose WinRM. Optionally, select the Remote Collector and WDS to use to perform the discovery. (By default the Device42 VM will be used and “any” available WDS connected will be utilized). Device42 discovery supports both the WMI and WinRM native Microsoft Windows protocols.
Include a “Job Name” to identify this auto-discovery job:
Windows/Hyper-V discovery option definitions:
|Option||Detailed description of option|
|Name||Your chosen name for the auto-discovery job|
|Server(s)||Enter your discovery target(s) Host names, IP addresses, IP range(s), and/or CIDR Blocks in a comma or line seperated list|
|Exclude Server(s)||Comma seperated list of Server hostnames or IP Addresses to exclude from discovery in the included targets|
|Username / Password(s)||Select or create a Password object to use as credentials for discovery|
|Use Service log on account||Will use the current logged-in user of the system running WDS to perform WMI discovery|
|Use Domain Server||Get list of machines to discover via LDAP query against specified AD domain [full details below]|
|Give precedence to hostname||This option instructs auto-discovery to overwrite existing device hostnames with discovered hostname|
|Discover VMs||WMI query of Hyper-V namespace to identify VM’s running on any Windows Hyper-V hosts|
|Device Name Format||Choose from one of the options to set the device name. See below for details|
|Discover Parts||Discover installed hardware parts with a unique Serial Number|
|Capture Hosts File||Discover hosts files of targeted systems and store details in Device42|
|Ignore||You can choose to ignore OS name, UUID, Serial Number, Domain Suffix, IPv6 address, and/or Virtual Subtype|
|Options||If you have the appropriate add-ons, select checkbox(s) to discover: software, services, application inventory, CloudID, and/or Cluster Info|
|Discover Cluster Information||WMI query of MS_Cluster for Windows Clustering details|
|Store||You can choose to discover & store Application Config Files, Registry Info, and File System Info (Requires ADM Module) in Device42|
|Object Category||Choose from Categories to apply to any discovered devices|
|Service Level||Set the Service Level on the discovered devices|
|Customer||Set discovered servers with the selected Customer|
|VRF Group||Set the discovered servers to the selected VRF Group|
|Service Ports Discovery Interval||Set an interval in seconds to allow for discovery to ONLY poll for new listener/client services|
|Service Port Client IPs||Port Range to exclude polling for service details of|
|Remote IP Exclusion||Entire IP address range to exclude from the targeted discovery|
“Use Domain Server” Option
Selecting the “Use Domain Server” option hides the “Server(s):” field; Target(s) to be discovered in this mode are instead defined by the result of chosen “LDAP Criteria” as returned by the specified Microsoft Windows Active Directory Domain or Domain Directory Server.
Relevant fields when using this discovery mode are as follows:
Username/Password(s): Authentication criteria to use for the Windows discovery job that will be run against the machines returned via the LDAP query
Use Service log on account: use whatever account credentials the WDS service executing the discovery is running as for authentication
Domain Server: Hostname or IP address of the Active Directory server to run LDAP query against
LDAP username/password: Authentication credentials used to execute LDAP query against specified domain controller/server
Use FQDN: Use Fully Qualified Domain Name (FQDN)
LDAP Criteria: Choose the LDAP Query to execute against AD, the resultant list which will then be targeted for Windows Auto-discovery. Selecting “Custom” allows specification of custom LDAP filter/query. Choose “save and continue editing” after checking to reveal the “Custom Filter” field.
“Use Domain Server” LDAP Query Example:
…will search the domain server for all computers with DNS hostname – d42sus.pvt and autodiscover the matches.
Device Naming Options and Preventing Duplicates
To prevent or correct any duplicate devices, you can control the format for names of devices added.
For example: If running a VMWare Discovery in tandem with a Windows discovery, there may be differences in discovered device names. vSphere will often show the short hostname, but a WMI query against the OS will return server FQDNs.
Device42 tries to best match devices by Serial #, UUID, and then name. However, if duplicates are added, the options detailed in the following section will assist in correcting them.
Configuring Windows Hostname Discovery Details
When running any discovery, you can add or update the Device Name of any targets with the host-name format of your choosing. Device42 can combine discovered host-name with the Domain Name [Option: ‘Host-name plus Domain Name’]. You can also add the name as discovered (host-name) as an alias, rather than replace an existing device’s name by choosing the option ‘Host-name and add Host-name plus Domain Name as Alias’. This option adds devices with the host-name as discovered as the device name, and the FQDN as the alias. Full details below:
For naming options, the above mentioned Strip Domain Suffix option occurs prior to assigning the device name according to the naming option you choose. The naming options are as follows:
- Hostname as discovered – if domain is present and domain is not in the name it is set to “name”
- Hostname Plus Domain Name and Add Host name as Alias – alias is set to “name” and the device name becomes “name.domain”
- Hostname Plus Domain Name the device name becomes “name.domain”
- HostnameAddHostnamePlusDomainNameAlias names stays the same and a alias is set as “name.domain”
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”.
Windows Hostname Process:
Device42 uses the following WMI query to obtain host & domain details on Windows servers:
select DNSHostName, Name, Manufacturer, Model, TotalPhysicalMemory, Domain, DomainRole from Win32_ComputerSystem
From these results, we’ll first look at DNSHostName for the device name, and if that is empty we’ll use Name.
To obtain the domain name, we’ll use the Domain value if the DomainRole value is one of the following: WinDomainRoles.MemberWorkstation, WinDomainRoles.MemberServer, WinDomainRoles.PrimaryDomainController or WinDomainRoles.BackupDomainController.
Strip Domain Suffix Option:
When selected, Device42 will drop everything after the first “.” in the device name.
Note that your “Device Name Format” setting works in *conjunction* with the “strip domain suffix” setting. Therefore, if your server hostnames INCLUDE domain names [e.g. server1.domain.com] and you do not strip domain suffix, “Hostname plus Domain Name” will append the domain again: ‘server1.domain.com.domain.com’. If your server hostnames are consistently named as you’d like them to appear, use “Hostname as Discovered”. “Strip domain suffix” + “Hostname plus domain Name” work best together in environments with inconsistent naming convention, stripping all hostnames to short names, and then appending found domains.
Auto Discovery Schedule
In the schedule 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 time.
Last Status and Run Report
This is where you will see information about the last run status of the auto-discovery job.
Run Report will give you summary diagnostic details of stderr/stdout for the last discovery job.
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 WDS 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 Permissions & Details
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)
- virtualizationv2 (Hyper-V only)
- MicrosoftIISv2 (Only for IIS)
- WebAdministration (Only for IIS 7+)
- MicrosoftSqlServer (Only for SQLServer)
- SMS (Only for SCCM)
- MSCluster (Only used if “Discover Cluster Information” is selected)
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
- Remote Procedure Call (RPC)
- Windows Management Instrumentation
- 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.
To run a Hyper-V discovery, set the “Platform” to Windows, and enable the “Discover VMs” option.
Make sure to include the Hyper-V servers as hostname’s, IP Address, or part of the CIDR/IP Range in the “Server(s)” criteria
Windows 2000 Discovery Pre-Requistes
If you are looking to discover a legacy Windows 2000-based operating system, a few OS settings need to be tweaked on the machine hosting your WDS (Windows Discovery Service) to obtain proper results:
- Change or create HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel element with value 1.
- Change WDS service user from System to one of the host users (admin). You can try without this step, but users report failure without making this change as well.