Windows and Hyper-V Auto-discovery
Installation Pre-Requisite for Discovery
Prior to running a Window’s 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.
Please first visit our doc’s page for Windows Discovery Service Installation
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.
Selecting “Add Hypervisors/*nix/win for Autodiscovery” will start your setup of a new auto-discovery job.
For creation of a Windows/Hyper-V discovery first change the “Platform” to Windows. Optionally, select the Remote Collector and WDS to use to perform the discovery. (By default the Device42 VM will be used and “Any” WDS connected will be attempted) Also, include a “Job Name” to identify the purpose for this auto-discovery job.
Here are definitions for the available options:
|Name||Your chosen name for the auto-discovery job|
|Server(s)||Here you can enter CIDR Blocks, Host Names, or IP Ranges in a comma seperated list to perform the auto-discovery against|
|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||Include A Domain Server to run an LDAP query for specifying server’s for discovery|
|Give precedence to hostname||Enable to allow the auto-discovery to replace the name of existing devices|
|Device Name Format||Choose from one of the options to set the device name. See below for details|
|Discover VMs||WMI query of Hyper-V namespace to identify VM’s running on any Windows Hyper-V hosts|
|Discover Cluster Information||WMI query of MS_Cluster for Windows Clustering 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||You can choose if you have the add-ons, discover software, services, and/or application inventory|
|Store||You can choose to store Application Config Files, Registry Info, and File System Info (Requires ADM Module)|
|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|
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.
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 Window’s discovery there may be differences in device names. Often vSphere will show the short hostname, but a WMI query against the OS will provide the FQDN. Device42 trys to best match devices by Serial #, UUID, and name. However, if duplcates are added the following options will assist in correcting them.
When running any discovery you 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.
- 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
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.
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.
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 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)
- WebAdministration (Only for IIS 7+)
- 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.
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