This article provides a comprehensive guide to discovering Windows-based hosts and Hyper-V environments. By leveraging either WMI (default) or WinRM, the discovery engine collects detailed information on operating systems, services, software, and virtual machine data.

Prerequisites

Before starting, ensure your environment meets the following baseline requirements:

• WMI Discovery: You must install the Windows Discovery Service (WDS) and connect it to your Remote Collectors (RCs).

• WinRM Discovery: Ensure WinRM is enabled on target hosts (typically via GPO). The connection originates from the RC.

• Credentials: You need an account with sufficient permissions to query the target systems.

Network requirements

Discovered Information

With a properly configured discovery account, the system gathers:

• Device Details: Host information, Model, Serial Number, and UUID.

• Hardware Parts: CPU, RAM, and Storage details.

• Software & OS: Operating System version, installed software, and configuration files.

• Services: Running service processes and communication ports (ADM).

• Virtualization: Virtual machine metadata for Hyper-V hosts.

Create a Windows or Hyper-V discovery job

1. Navigate to Discovery > HyperVisors / Nix / Windows.

2. Click Create and set the Platform to Windows.

3. Choose your communication protocol:

   • To use WinRM: Select Discover Using WinRM. If running through WDS, ensure the WDS service is running under a Domain Account (Local System is not supported for remote authentication).

   • To use WMI: Leave WinRM unselected (WMI is the default).

4. Add your target FQDNs, IP addresses, or CIDR ranges.

5. Click Add another Username/Password to provide credentials.

Query a Domain Controller (Active Directory)

Instead of entering static IPs, you can dynamically target devices found in AD.

1. Enable Query domain controller to obtain a list of discovery devices.

2. Enter the Domain Server IP/Hostname and LDAP credentials.

3. Select your LDAP Criteria (e.g., "All Computers" or a custom filter like (&(objectCategory=computer)(dNSHostName=*.domain.com))).

Microsoft LAPS integration

If your domain uses Local Admin Password Solution (LAPS), the system can retrieve local admin passwords directly from AD.

1. Follow the Query Domain Controller steps above.

2. Enable the Use LAPS (only Applies to WDS) checkbox.

3. Ensure the LDAP account used has permission to read the LAPS password attributes in AD.

Device naming and duplicate prevention

To maintain a clean inventory, use the Naming Options section to standardize how devices are added:

• Strip domain suffix: Removes the .domain.com portion of a hostname.

• Device Name Format:

  • Hostname as Discovered: Keeps the name exactly as returned by WMI/WinRM.

  • Hostname plus Domain Name: Forces the FQDN format.

  • Alias Options: Use these to keep one format as the primary name while storing the other as a searchable alias.

Permission requirements

WMI and Windows Host Discovery

The discovery account requires Enable Account, Remote Enable, and Read Security permissions for the following WMI namespaces:

• Root\CIMV2, Root\StandardCimv2, Root\default

• Root\virtualization (for Hyper-V)

• Root\MicrosoftSqlServer (for SQL Server)

• Root\WebAdministration (for IIS)

The account must also be a member of the Performance Monitor Users and Distributed COM Users groups on the target machine.

Application Dependency Mapping (ADM)

To discover service communications, the account generally requires Local Administrator privileges.

• Standard Method: Requires access to IPC$ and ADMIN$ shares over port 445.

• Alternate Method: If administrative shares are disabled, you can specify a custom network share with read/write privileges for the scanning account.

• Non-Admin Workaround: You can grant the SC_MANAGER_CONNECT permission to a non-admin SID using the sc.exe sdset command in PowerShell.

Port Matrix

Best Practices and Limitations

• If you've populated the devices before your first discovery run (using CSV imports, spreadsheets, or manual entry), test discovery against a few devices to verify that the selected discovery naming options are correct for your naming convention. For example, if you added nh-linux01 as a device, discovery could find the hostname nh-linux01.example.com and add it as a new device because the names don't match. See the Device Naming and Duplicate Device Prevention section.

• Run device discovery after running network discovery or after defining the subnets where your network IPs reside.

• Floating IPs that logically belong to a cluster but are found on a device during discovery will be assigned to that device and not the cluster resource.

• You can run the WDS from any or multiple network segments. Communication from the discovery client back to the main Device42 instance requires access via port TCP/443 (HTTPS) on your network.

Legacy Windows 2000 Discovery Prerequisites

To discover a legacy Windows 2000-based operating system, adjust the following OS settings on the machine hosting your WDS:

1. Change or create the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel element so that it has the value 1.

2. Change the WDS service user from System to one of the host users (like an admin account). You can try to run a discovery job without this step, but users report failure without making this change.