- Installation pre-requisites for Windows discovery
- Creating & running Windows WMI/WinRM discovery jobs
- Scheduling discoveries
- Device naming & duplicate device prevention
- General considerations
Installation pre-requisites for Windows discovery
Prior to running a Windows Discovery, you must install an instance of the Windows Discovery Service (WDS) on at least one Windows system which will connect to the Device42 main appliance (MA) or a Remote Collector (RC). WDS can be downloaded from the Auto-Discovery Software page.
For WDS installation instructions and detailed information, visit the Windows Discovery Service (WDS) installation documentation.
Creating & running Windows WMI/WinRM discovery jobs
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:
Select “Add Hypervisors/*nix/Win for Autodiscovery” to setup a new Windows / Hyper-V Auto-discovery job.
To specify Windows WMI-based or Hyper-V discovery, select “Platform” Windows. For Windows Server 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 options & 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 host OS info (name), UUID, Serial Number, Domain Suffix, IPv6 address, Subnets, and/or Virtual Subtype|
|Options||Select appropriate checkbox(s) to discover: software, services, applications, Cloud ID, 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.
Discovery with Microsoft LAPS [Local Admin Password Solution]
Microsoft LAPS (Local Admin Password Solution) is a method of securing Active Directory member servers whereby the server’s local admin password is randomly generated and stored as an attribute of that servers AD object in Active Directory. This password can then be looked up on demand via an Active Directory / LDAP query, and is often used to support scripted / automated actions that iterate through lists of AD member servers. If you are looking to Download LAPS from Microsoft, click here. For more information on LAPS, see this article from Microsoft, or if you’d like to deploy LAPS, you might find this “Deploying LAPS” guide on ‘FlamingKeys.com’ helpful.
Device42 now supports pulling credentials from LAPS when discovering Active Directory domain member servers that are using Microsoft LAPS [Local Admin Password Solution] to manage their local admin passwords. You will see this option only when you have checked “Query domain controller to obtain list of discovery devices”; once the former is checked, you will see “Use LAPS (only Applies to WDS)”.
Check the “Use LAPS (only Applies to WDS)” checkbox to enable it; Ensure “Query domain controller to obtain list of discovery devices” is checked to reveal the option:
Relevant fields / requirements for using LAPS discovery mode are as follows:
- Check the “Query domain controller to obtain list of discovery devices” option.
- Specify your domain server
- Specify an LDAP user/pass credential combination with permission to query the LAPS password for each server
- You must have at least one instance of WDS installed (A requirement for all Windows-based discoveries).
- Choose “All Computers” or “All Servers” from the LDAP Criteria dropdown, or Optionally, supply your own custom LDAP query by selecting “Custom Filter” from the dropdown:
- Run your discovery!
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.
Device naming & duplicate device prevention
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 discovery 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.
Permission requirements – WMI & Windows
Windows permissions requirements are broken down into two parts:
- A) Minimum required permissions for discovery of Windows hosts/guests
- B) Minimum required permissions for ADM – discovery of services & application data for dependency mapping on Windows
A) Windows AutoDiscovery minimum permissions:
The following requirements represent the minimum necessary user account permissions that should allow Device42 to connect and discover a Windows host:
1) Ensure at least Enable Account, Remote Enable, and Read Security, as well as WMI permissions are applied to the auto-discovery user account and to the following WMI Namespaces and subnamespaces:
**Note for HyperV discovery against Windows Server2k12 and newer: Should discovery fail due to a permissions error, you may need to add your Device42 discovery account to the built in HyperV administrators group due to changes made with the way Microsoft verifies permissions on these newer operating systems.
2) Firewall Rules to Enable:
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
3) Services to Enable and Set to Automatic:
- Remote Procedure Call (RPC)
- Windows Management Instrumentation
4) The discovery user account must be a member of the Performance Monitor Users Group and Distributed COM Users Group on the machines being targeted for discovery.
Provided the above is successfully configured for the discovery account (& the data is available), Device42 will successfully gather the following info:
Note: 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.
B) Windows Application Dependency Mapping (ADM) minimum permissions:
There are now two options for configuring Application Dependency Mapping permissions; The first, preferred method allows users to configure their own share as of v15.16.00, and does not require local admin permissions, while the second option uses Local Administrative Permissions and the IPC$ & ADMIN$ shares.
When setting up a discovery job, you can now specify the share where your data is located. The share can be local to the device or a shared location on your network. You will only need to give the scanning account read privileges to the new share location.
Local Administrator [alternate] Method:
Application Dependency Mapping requires the local admin group on the target hosts and access to IPC & ADMIN shares.
Enable access to IPC & ADMIN shares: Device42 will utilize the
ADMINshares to obtain service port communication details in Windows discovery. Ensure these shares are enabled and accessible over port 445, or inter-device communications will not be discovered.
Connection data is written to a path on the
admin$administrative share, which is only writable by the local admin group. This path is used because it is a standard, consistent path that can be found on all Windows deployments.
Best practices & limitations:
- If you’ve populated Device42 [CSV imports, spreadsheets, manual entry, etc.] with devices before your first discovery run, please make sure to test discovery against just a few devices to ensure the selected discovery naming options are correct for your naming convention. (For example, if you added nh-linux01 as a device, auto-discovery could find the hostname nh-linux01.example.com and add it as a new device because the names don’t match. Fix this by checking the checkbox “use only hostname”)
- It’s best to run device auto-discovery 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/or 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.
To run a Hyper-V discovery, set the “Platform” to Windows, and enable the “Discover VMs” option.
The Hyper-V server’s hardware details and its name, UUID, and MAC addresses are pulled in from the VMs.
Be 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.