Skip to main content

Windows and Hyper-V Autodiscovery

Prerequisites & Information for Windows discovery

Device42 discovery can utilize multiple protocols to communicate with the target devices. Either WinRM or WMI can be utilized for windows discovery. As of 18.10.00, WMI is the default protocol.

When using WMI and before setting up your Windows Discovery job, you must first install WDS and connect to your Remote Collectors. For WDS installation instructions and information, visit the Windows Discovery Service (WDS) installation documentation.

Your OS must be at Windows 8.1, Windows Server 2012 R2 or above with the latest patches installed.

Network Requirements for WinRM vs WMI

WinRM

WinRM uses port 5985 (HTTP) or 5986 (HTTPS), depending on the configuration on the target host. These connections come from the RC selected at the top of the jobs page. For configuring within your environment, please refer to the Microsoft documentation here. Note that you must enable this on your Windows machines which can be configured through a GPO.

WMI

WMI is based on DCOM/RPC. This means a connection is first initiated on port 135 to determine what dynamic port to use. The connection then proceeds to use the dynamic port negotiated. The following Microsoft documentation can be used for configuring WMI. Network Issues

Our support team can provide best effort assistance in trying to resolve issues. However, for both protocols, it is best to reach out to your network or system admin, in order to resolve connection issues.

Discovered Information

Provided with a successful configuration of the discovery account, and given the data's availability, Device42 will gather the following information:

  • Device host information
  • Parts
  • Operating System
  • Service processes
  • Software installed
  • Installed common applications and configuration files

Within the Parts section of device details, the CPU, RAM, and storage entries for the device will be displayed. You may also see additional information such as model number, slot, and location.

Option To Ignore IPs/MAC Addresses

You can ignore IP and MAC addresses from being included in our database during autodiscovery. Devices with these addresses will still be discovered but the detailed information that would typically be collected and stored is ignored.

Configure rules to ignore IP and MAC addresses for a specific job when creating or editing the job.

Ignore IPs and MACs

Globally, you can add an Exclusion to ignore IP and MAC addresses for all jobs by navigating to Tools > Settings > Global Settings on the Main Appliance.

Creating & running Windows discovery jobs

Navigate to the Discovery menu and select HyperVisors / *Nix / Windows, this section will allow you to setup and save multiple autodiscovery jobs for Windows, Hyper-V, and other platforms.

  1. Select "Add Hypervisors/*nix/Win for Autodiscovery" to setup a new Windows / Hyper-V Autodiscovery job.
  2. For Windows or Hyper-V discovery, select Windows as the Platform.
    •  As of 18.08.00, you can select WinRM as the default method within the Windows discovery (pictured below) and the URL prefix and port will default accordingly.
  3. Include a "Job Name" to identify this autodiscovery job:

*Classic WinRM is no longer a Platform type as of 18.08.00. Existing Classic WinRM jobs will continue to function.

Windows/Hyper-V discovery options & definitions:

  • Job Name: User-defined name for the job.

  • Remote Collector: Select which remote collector you’d like to run the discovery job from – optional.

  • Job Debug Level: Debug On for extra debug info, useful for a support ticket.

  • Discovery Target(s): Specify FQDN or IP of discovery target(s). If using FQDN, Device42 must be configured to resolve the DNS.

  • Use Service Account Credentials: Will use the current logged-in user of the system running WDS to perform WMI discovery.

  • Query domain controller to obtain a list of discovery devices: Hides the Discovery Target(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. See the Query domain controller section below.

  • Collect database server information: Select this option to discover Oracle, MSSQL, DB2 and Postgres database servers. If selected, it will display a Database Username/Password(s) field.

  • ADM Sampling Interval: Off or sampling interval in minutes or hours.

  • Enable Resource Utilization Tracking for Device(s): Optionally enable collection of resource utilization metrics from discovered devices.

  • Resource Utilization Sampling Interval: Set the interval for RU data collection (only in effect if RU Tracking is enabled).

  • Autodiscovery Schedule: You can schedule the discovery to run at certain times.

“Query domain controller to obtain list of discovery devices” option

Selecting the “Query domain controller to obtain list of discovery devices” 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:

  • Use Service Account Credentials: 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 the LDAP query against.

  • LDAP username/password: Authentication credentials used to execute the LDAP query against the 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 Autodiscovery. Selecting “Custom” allows specification of a custom LDAP filter/query.

"Query domain controller" LDAP Query Example:

(&(objectCategory=computer)(dNSHostName=d42sus.pvt))

...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 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:

  1. Check the "Query domain controller to obtain list of discovery devices" option.
  2. Specify your domain server
  3. Specify an LDAP user/pass credential combination with permission to query the LAPS password for each server
  4. You must have at least one instance of WDS installed (A requirement for all Windows-based discoveries).
  5. 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:
  6. Run your discovery!

Additional Options

After completing the required options for your Windows or Hyper-V discovery, scroll down the discovery job page to see additional job options including Exclusions, Naming, Host Discovery, Hypervisor Options, Software and Applications, and Miscellaneous options.Click “Show” to expand those options.


Scheduling discoveries

Schedule

In the schedule section you can set as many different autodiscovery 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 autodiscovery 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:

  1. Hostname as Discovered
  2. Hostname plus Domain Name
  3. Hostname and add Hostname plus Domain Name as Alias
  4. 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”.

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.


General considerations

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

Note that where applicable, WinRM specific items are listed but permissions themselves must be enabled on the target machine.


A) Windows WMI 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 autodiscovery user account and to the following WMI Namespaces and subnamespaces:

  • CIMV2
  • StandardCimv2
  • default
  • 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)

**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:

WinRM

  • HTTP (5985)
  • HTTPS (5986)

WMI

  • 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.

info

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 two options for configuring Application Dependency Mapping permissions. The first option uses Local Administrative Permissions and the IPC$ & ADMIN$ shares. The second option lets users configure their own share**.**

Local Administrator Method:

  1. Application Dependency Mapping requires the local admin group on the target hosts and access to IPC & ADMIN shares.
  2. Enable access to IPC & ADMIN shares: Device42 will utilize the IPC and ADMIN shares 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.
  3. 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.

Alternate Method:

When setting up the discovery job if the IPC and ADMIN shares are inaccessible you can now specify a network share to use. The share can be local to the device or a shared location on your network. You will need to give the scanning account read and write privileges to the new share location. Note, this method also requires local admin permissions.

C) Port Matrix

PortsProtocolApplication ProtocolNotes
5985HTTPWinRMAlways required for WinRM.
5986HTTPSWinRMAlways required for WinRM.
135TCPWMIAlways required for WMI.
137UDPNetBIOS Name ResolutionOptional/Legacy. Windows 2000 and newer versions of Windows can work over port 445.
138UDPNetBIOS Datagram ServiceOptional/Legacy. Windows 2000 and newer versions of Windows can work over port 445.
139TCPSMBOptional/Legacy. Windows 2000 and newer versions of Windows can work over port 445.
445TCPSMBOptional. Used by the WDS (Windows Discovery Service) to retrieve UDP communication and configuration files from targets.
1024-5000TCPRPC randomly allocated low TCP portsOptional/Legacy. Used in Windows 2000, Windows XP, and Windows Server 2003. Newer versions of Windows use high TCP ports 49152 - 65535.
49152-65535TCPRPC randomly allocated high TCP portsAlways required (Unless entire environment predates Windows Server 2008). Used in Windows Server 2008 and later versions, and in Windows Vista and later versions.

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, autodiscovery 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 autodiscovery after you have run network autodiscovery 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 autodiscovery 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 autodiscovery client back to the main Device42 instance requires access via port TCP/443 (HTTPS) to be allowed on your network.

Hyper-V information

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 prerequisites

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:

  1. Change or create HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel element with value 1.
  2. 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.