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

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.

The following commands can be used to test the WMI access needed to run software discovery on a Windows server:

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.

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:

After running the commands you may get one of the following common error codes:

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:

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.

Select the nodes and click on Security:

If the user does not appear, add it by clicking Add, and give it the permissions:

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

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:

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.