If you are having issues discovering installed software on Windows servers or collecting user login details from an AD server, this article will go through some common troubleshooting steps to help resolve those issues.
Testing WMI Access Using the Command Line
Windows has a built-in tool to run WMI queries that we use to test the WMI connection to a remote server easily without running discovery in Faddom. You can refer back here after making any of the changes below to see if it resolved the issue.
If the following commands can be run successfully from the Faddom proxy (or Faddom server if you are not using a proxy), then Faddom should be able to run the discovery process.
In the commands below, you should replace <ip-address> with the IP address or hostname of the server you are trying to discover.
The <user-name> parameter should be set to DOMAIN\User if you are using a domain account or just the user name if you are using a local account.
Software Discovery
The following commands can be used to test the WMI access needed to run software discovery on a Windows server:
wmic /node:<ip-address> /user:<user-name> /namespace:\\ROOT\Cimv2 path Win32_OperatingSystem GET
wmic /node:<ip-address> /user:<user-name> /namespace:\\ROOT\StandardCimv2 path MSFT_NetTCPConnection GET
wmic /node:<ip-address> /user:<user-name> /namespace:\\ROOT\Default Class StdRegProv Call EnumKey hDefKey="&H80000002" sSubKeyName="SOFTWARE\Microsoft\Windows\CurrentVersion"
To get the specific error code in case of an access denied error, you can add /trace:on to the command at the beginning. e.g.
wmic /trace:on /node:192.168.0.1 /user:faddom /namespace:\\ROOT\Cimv2 path Win32_OperatingSystem GET
User Login Discovery
To test access for reading the event log on a remote computer needed for the user login discovery, you can try running the following command:
wevtutil el /r:<ip-address> /u:<user-name>
Error Codes
After running the commands you may get one of the following common error codes:
Error Message | Likely Cause | Resolution Steps |
The RPC server is unavailable | The traffic to the server is being blocked - likely by a firewall rule | Check the required ports in the Firewall Rules section |
Access is denied
Error Code: 0x80070005 | Remote access permissions | Either an incorrect user name or password, or the user doesn't have remote access through DCOM. See Required Permissions section |
Access is denied
Error Code: 0x80041003 | WMI Permissions | The user managed to log in and access the server remotely, but does not have access to perform the WMI queries. See Required Permissions section |
Troubleshooting Steps
Firewall Rules
By default, WMI utilizes DCOM, which uses a dynamic port range to facilitate communications. This port range can be changed as described in the Microsoft documentation, but this guide will assume you are using the standard port range.
The following ports are required to be opened from the Faddom proxy or server to the server being discovered:
Port number | Description |
135 | RPC Endpoint Mapper Service |
49152-65535 | DCOM (Dynamic port) |
139 | Netbios Session Service |
445 | SMB |
Required Permissions
In order to run WMI queries on a remote computer, the user requires the following permissions:
Note: For users using a local account in the Administrators group see here
The created user should be added to the Performance Log Users in the local computer. This will give the user permissions to access the server through DCOM remotely.
In addition to the group, the user will need permission to run WMI queries. To manage these permissions, open the WMI Management console by going to Start -> Run and running wmimgmt.msc
Right click WMI Control (Local), and select Properties. There, select the security tab to get the following:
Here, you need to specify access either to the following nodes required by Faddom.
DEFAULT
CIMV2
StandardCimv2
Select the nodes and click on Security:
If the user does not appear, add it by clicking Add, and give it the permissions:
Enable Account
Remote Enable
If you are enabling access for the Root node, click on Advanced, select the user and click on Edit. Make sure the permissions apply to This namespace and subnamespaces
Using a Local Administrative Account
By default, Windows blocks all WMI access for administrative users that are not the built-in Administrator user. To change this behavior, use the following procedure:
Open the registry editor by going to Start -> Run and type regedit and navigate to the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
There check for a key named LocalAccountTokenFilterPolicy of type REG_DWORD. If it does not exist, create it and set the value to 1.
This should allow other administrative users to access the server using WMI remotely.