IPAM Windows DHCP server scan fails on WinRM-only node with “The remote procedure call failed and did not execute” while PowerShell WinRM works

Problem / Symptoms 

• Windows 2019 DHCP server running on a domain controller is monitored in IPAM.
• The node is configured for WinRM only and WinRM over HTTPS 5986 works from the polling server using PowerShell (Test-WSMan, Invoke-Command, DHCP PowerShell module).
• In IPAM:
  • Test Authentication for the DHCP server fails.
  • DHCP scope scan fails with:
    > DHCP Server scanning failed with error:The remote procedure call failed and did not execute.
• On the Windows DHCP/DC:
  • WMI/WinRM events show errors such as 0x80041001, HTTP 401, and WSMan error 1359.
• In the SolarWinds Platform, the same server can still be polled via WinRM and Real-Time Process Explorer works.

What this article explains

• Why IPAM still uses RPC/WMI for Windows DHCP polling even when the node is set to WinRM only.
• Why DHCP Test Authentication/scans fail while WinRM/PowerShell and Real-Time Process Explorer succeed.
• How to resolve the issue by allowing and validating the RPC/WMI path and permissions needed for IPAM’s Windows DHCP polling.

• Design behavior:

  • IPAM’s Windows DHCP integration always uses RPC/WMI to the DHCP WMI provider (root\Microsoft\Windows\DHCP) to retrieve scopes, leases, and reservations.
  • The node polling method (WinRM/WMI/SNMP) controls how the core node is polled (CPU, memory, Real-Time Process Explorer, etc.), but it does not change how IPAM talks to Windows DHCP.

• Environment/configuration issue:

  • On the Windows 2019 DC/DHCP server, the RPC/WMI path from the polling server to root\Microsoft\Windows\DHCP is:
    • Blocked by a firewall / Windows Firewall (ports 135, 445, and/or dynamic RPC range), and/or
    • Restricted by insufficient WMI/DCOM permissions for the IPAM Windows credential (often not a local admin on a DC).
  • As a result:
    • IPAM DHCP Test Authentication and scans fail with “The remote procedure call failed and did not execute” and WMI 0x80041001.
    • But WinRM over HTTPS 5986 and PowerShell DHCP cmdlets continue to work, because they use a different channel (WinRM + DHCPServer module), not the RPC/WMI path IPAM uses for DHCP.

• Related, but separate, issue:

  • The WinRM test may additionally fail with 0x80131500 / HTTP 401 / name-resolution errors because the WSMan URL and account context that the SolarWinds Platform builds internally can differ from the manual PowerShell tests (short name vs FQDN, DNS suffix/search order, or account/SPN/certificate differences).
  • This affects the WinRM test UI, but the DHCP scan failure itself is caused by the blocked/under-privileged RPC/WMI path, not by the WinRM channel.

Goal: Ensure that the IPAM polling server can reach the DHCP/DC over RPC/WMI and that the IPAM Windows credential has sufficient rights to the DHCP WMI provider.

1. Verify RPC connectivity from the polling server to the DHCP/DC

   On the SolarWinds/IPAM polling server, run PowerShell:

   Test-NetConnection <DHCP_IP_or_FQDN> -InformationLevel Detailed
   Test-NetConnection <DHCP_IP_or_FQDN> -Port 135
   Test-NetConnection <DHCP_IP_or_FQDN> -Port 445

   powershell

    
   • Port 135 – RPC Endpoint Mapper
   • Port 445 – SMB / RPC over SMB

   If any of these port tests fail (TimedOut/Refused):

   • Open ports 135 and 445 from the polling server to the DHCP/DC in:
     • Network firewalls, and
     • Windows Firewall on the DHCP/DC (if enabled).
   • If your environment uses a restricted dynamic RPC port range, ensure at least one port in that range is also reachable between the poller and DHCP/DC.

2. Validate WMI access to the DHCP WMI provider

   From the polling server, using the same Windows credential configured in IPAM for this DHCP server:

   • Run wbemtest.
   • Connect to:
     • root\Microsoft\Windows\DHCP
   • Run query:

     SELECT * FROM DhcpServerv4Scope

     sql

      
   • If this returns errors or no data, you have a WMI/provider or permission issue on the DHCP/DC host.
   • Work with your Windows/AD team to:
     • Repair or reinstall the DHCP role / WMI provider if it is broken.
     • Confirm that WMI/DCOM security allows this account to query root\Microsoft\Windows\DHCP.

3. Confirm Windows account group membership and logon rights

   On the DHCP/DC server:

   • Ensure the Windows account used in IPAM:
     • Is a valid account on the DHCP/DC, and
     • Is a member of at least one of:
       • DHCP Users
       • DHCP Administrators
       • Administrators

   On the IPAM polling server:

   • Ensure the same account is allowed to “log on locally” / interactively (per IPAM Admin Guide). IPAM impersonates this user before making RPC/WMI calls.

4. Re-test from IPAM

   After confirming RPC connectivity and WMI/DCOM permissions:

   • In IPAM, go to DHCP Servers, select the affected Windows DHCP server.
   • Click Test Windows Credentials:
     • It should now succeed.
   • Run a DHCP scope scan:
     • The scan should complete without the “The remote procedure call failed and did not execute” error, and scopes/leases should populate.

5. (Optional) Review WinRM test behavior

   • If the node’s WinRM Test still fails while PowerShell WinRM works, review:
     • WSMan URL (short name vs FQDN),
     • DNS suffix/search order on the polling server,
     • Authentication method (Kerberos/Negotiate vs Basic/HTTPS and TrustedHosts),
     • Certificate CN/SAN and trust for HTTPS listeners.
   • This does not affect IPAM’s DHCP polling, but can help clean up WinRM test warnings in the SolarWinds Platform.