There are many moving parts that must work together for the VMware discovery and inventory gathering process performed by a beacon to be successful. This article details a range of considerations and areas to check when troubleshooting to identify a reason why virtual inventory data is not being successfully gathered from a VMware vCenter or ESXi server. 

This article assumes you have good knowledge of how the VMware virtual inventory gathering process works. Refer to other resources if you need an introduction to this capability. 

Identify a target VMware server for troubleshooting 

Identify a specific target VMware vCenter or ESXi server that will be used for troubleshooting. Confirm both the name and IP address for this server. 

TIP: Details in logs that are produced by the discovery and inventory gathering process may refer to the server by either its IP address or name, so be sure to look for either identity when reviewing logs. 

The rest of this document uses the IP address “1.2.3.4” as an example of a server to be targeted. 

Configure a discovery action, target, and rule for troubleshooting 

Configure a specific action, target, and rule in the Flexera One ITAM or FlexNet Manager Suite web UI to attempt to gather inventory from the VMware server that has been chosen to be used for troubleshooting. 

If you are using FlexNet Manager Suite, go to Discovery & Inventory > Discovery > Discovery and Inventory Rules.

If you are using Flexera One ITAM, go to Data Collection > IT ASSETS INVENTORY TASKS > Discovery and Inventory Rules.

Action details 

Ensure the following details are specified in the action: 

• Action type: Discovery and inventory 

• Network scan: Selected 

• VMware infrastructure 

• • Discover VMware infrastructure: Selected 

• Gathered VMware infrastructure inventory, with advanced recognition of VMware applications: Selected 

The following screenshot illustrates typical settings used for troubleshooting: 

Target details 

Ensure the target IP address used for troubleshooting is explicitly specified in the target configuration. 

The following screenshot illustrates typical settings used for troubleshooting: 

Review beacon subnet mapping 

If you are using FlexNet Manager Suite, go to Discovery & Inventory > Network > Subnets.

If you are using Flexera One ITAM, go to Inventory > NETWORK DISCOVERY > All Subnets.

Ensure a subnet/IP address range covering the target VMware server’s IP address is mapped to the beacon you expect to connect to the server. 

Review logging 

Configure discovery logging (2022 R2 to 2024 R1.x beacons only) 

FlexNet inventory beacon versions 2022 R2 (19.0) to 2024 R1.x (22.x) do not produce all logging that is helpful for troubleshooting purposes by default. 

If you are running one of these beacon versions, apply the changes described in the “Remediation” section of the following article before proceeding: Known Issue: Some expected details are not included in discovery.log files (IOK-1139954) 

Locating logs files 

After configuring and running a rule to discover and gather VMware inventory, gather and review log files from the rule execution. 

Some versions of the web UI provide access to log files from the System Tasks page. Find and expand the relevant task listed on that page and click on the link in the Logs column to download log files. 

If you have a version of the web UI that does not provide access to logs in this way, there will be no link available in the Logs column of the System Tasks page. You will need to gather logs directly from the beacon where the rule was executed. To do this: 

1. View the following directory: C:\ProgramData\Flexera Software\Compliance\Logging\InventoryRule 
    

2. A new subdirectory under the InventoryRule directory with a random name is created for each rule execution. Look for a subdirectory with a timestamp matching the time when the rule you are troubleshooting ran. It can be helpful to sort the subdirectories by the Date modified column in Windows Explorer to do this. 
    

3. Open the discovery.log file in the subdirectory you have located and check the rule name identified in the first line of the log file to verify that you have successfully found the logging from the desired rule. The log line will look similar to the following: 
    
   2025-01-29 11:31:17,117 [iscoveryActionExecuter|Async] [INFO ] Executing rule 'Troubleshooting VMware rule' revision '9787' 

Common indications of problems seen in log files 

Check network connectivity 

To gather VMware inventory, the beacon must be able to ping and connect to port 443 on the target VMware server. 

Execute the following commands in a PowerShell window on the beacon to verify the connectivity: 

ping 1.2.3.4

Test-NetConnection 1.2.3.4 -Port 443

curl.exe -k -v https://1.2.3.4/sdk/vimService.wsdl

Also, ensure that network name resolution resolves the VMware server’s name to the correct IP address: 

nslookup my-vmware-server-name 

Check discovery with MgsIPScan.exe 

The MgsIPScan.exe beacon executable is used during the discovery process to verify that the targeted VMware server IP address is accessible. It can be executed manually with different command line arguments to validate connectivity. 

1. First, try executing the following command to test connectivity with an ICMP type 8 (echo request) packet (“-PI” option): 

"C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\MgsIPScan\MgsIPScan.exe" -p 443 -PI -sU -sS 1.2.3.4

2. If this fails to connect, next try the following command to test connectivity with an empty TCP packet with the SYN flag set, also known as a “TCP SYN/ACK scan” (“-PS” option): 

"C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\MgsIPScan\MgsIPScan.exe" -p 443 -PS -sU -sS 1.2.3.4

3. If this still fails to connect, try the following command to test connectivity without any kind of ping (“-Pn” option): 

"C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\MgsIPScan\MgsIPScan.exe" -p 443 -Pn -sU -sS 1.2.3.4 

Note that the “-P?” argument is different in each case. 

By default, the discovery process uses the “-PI” argument. However, if the connection does not succeed with that argument but does succeed with another “-P?” argument, configure the beacon to use the argument that works by setting the following registry entry: 

Registry key: HKLM\SOFTWARE\Wow6432Node\ManageSoft Corp\ManageSoft\Discovery\CurrentVersion 

Entry: DefaultPingSweepOptions 

Value: -PS (or -Pn, if that is the option that worked) 

Take note of the following: 

• Configuring this registry entry will affect ALL rules executed by the beacons that perform a network scan. 

• Using a non-default value for this setting may slow down the port scanning discovery process. Use with care if the beacon will perform discovery operations targeting a large number of IP addresses. 

See the following Nmap documentation page for information about the behavior of the various options used with MgsIPScan.exe (which is a re-packaged copy of Nmap): Host Discovery Techniques. (Note: The “-PI” argument is the same as the “-PE” argument documented on this page.) 

Check WinHTTP proxy configuration 

The Windows HTTP Services (WinHTTP) subsystem is used to make HTTPS connections to VMware servers during the discovery and inventory gathering process. 

If a WinHTTP proxy is configured on the beacon, then HTTPS traffic generated by the discovery and inventory gathering process may be routed by the proxy. If the proxy is unable to connect to the target VMware server, then the beacon will be unable to gather inventory from the server. 

Execute the following command to check the current WinHTTP proxy configuration: 

netsh.exe winhttp show proxy 

If this command indicates that a proxy is configured, consider whether that proxy is able to correctly route HTTPS traffic to the VMware server IP address. If HTTPS traffic to the VMware server should not be sent via the proxy, remove the proxy or configure a bypass. 

For example, to remove the proxy: 

netsh.exe winhttp reset proxy 

Or to use the proxy “your-proxy:8080” for most traffic but bypass it for communicating to the IP address 1.2.3.4: 

netsh.exe winhttp proxy proxy-server=your-proxy:8080 bypass-list=1.2.3.4 

Check for problems with TLS version mismatches 

Failures can occur if the beacon is not configured to communicate with the same TLS versions that the VMware server is configured to use. 

If the VMware server has been configured to only support communications using a restricted set of TLS versions, the following registry entry may need to be set on the beacon: 

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DefaultSecureProtocols 

Set DefaultSecureProtocols to the following value to support TLS versions 1.0 through 1.3: dword:00002A80 
 
For more details, see Configure secure protocol options for WinHTTP.

NOTE: Beacons running on older Windows Server 2008 and 2012 versions may require an update to be applied to support modern TLS versions. See the following page for details: Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows. 

Verify an ESXi paid (not free) license is in use 

ESXi servers that are installed with a free license do not provide an API that can be used to gather virtual inventory details. Gathering virtual inventory from such servers is not possible. 

A symptom of free licensing being used is that details in discovery.log files will show a message like the following: 

2025-01-29 11:31:42,398 [.VirtualizationVisitor|Async] [INFO ] No inventory gathered for device 'my-vmware-server because discovery did not find the service on the device. 

Attempt inventory gathering using the VMware standalone inventory agent esxquery.exe tool 

Using the standalone inventory agent esxquery.exe tool can be helpful to test just the inventory gathering step without first executing the discovery step. This can help confirm whether the discovery step or the inventory gathering step of the process is failing. 

See the following page for information about using the esxquery.exe tool: VMware stand-alone inventory agent esxquery.exe for FlexNet Manager Suite & Flexera One ITAM. 

If esxquery.exe successfully gathers inventory but no inventory is gathered when running a discovery & inventory rule, then that suggests the problematic part of the process is the “discovery” step, not the “inventory gathering” step. 

Go deeper with diagnostic tracing 

If none of the above suggestions help, additional detailed diagnostic tracing can be enabled by changing settings in the following file: 

• If the beacon is installed standalone (that is, not on the application server): C:\Program Files (x86)\Flexera Software\Inventory Beacon\etdp.trace  

• If the beacon is installed on the application server: C:\Program Files (x86)\Flexera Software\FlexNet Manager Platform\etap.trace 

Edit the appropriate *.trace file and make the following updates: 

1. Modify the values of the following settings: 
    
   filename=C:\Windows\Temp\ManageSoft\discovery-trace.log
   

    

   flush_freq=0 

    

2. Add lines to the file to enable the following trace classes to troubleshoot this area of functionality: 
   +Communication/Network 
+Discovery 
+GSoap
+Error 
+Inventory 
+Scheduling/RemoteExecution 
   
   
3. Restart the FlexNet Beacon Engine service to ensure the .trace configuration changes are picked up.

Once these trace classes are enabled, run the problematic VMware discovery & inventory process again and then review the information in the generated trace output file to understand details about what the process is doing. 

This approach to enabling tracing works for both discovery & inventory rules executed by the beacon software itself, and also when executing the standalone inventory agent esxquery.exe tool on a beacon.

See the following page for additional information about configuring tracing: How to enable FlexNet Manager Suite diagnostic tracing. 

TIP: Remember to revert changes made to the *.trace file to disable tracing once troubleshooting has been completed to avoid generating large trace output files. 

NOTE: Tracing produced by beacon versions prior to 2022 R1 (18.0) is limited. It is recommended that you upgrade to a more recent beacon version that is currently supported for troubleshooting.