Failure to run discovery on VMware vCenter/Host Servers in FlexNet Manager Suite On-Premises

[#1]

Summary

No inventory gathering on device 'Device_Name' because the discovery did not find the server type

Symptoms

The following FlexNet Manager Suite On-Premises error can be seen in the VMWareInventory.log files:

No inventory gathering on device 'Device_Name' because the discovery did not find the server type.

Cause

This is a known issue when the Inventory Beacon is not able to verify that the VMware vCenter/Host Server has an SDK open on the target port.

The VMware vCenter/Host inventory scan goes through three processes when it is targeted:
STEP 1: Discover the device information, IP to Host resolution, Host to IP resolution, and its open ports while scanning the provided list


STEP 2: Discovering the existence of a VMware SDK using the IP Address


STEP 3: Taking inventory of the vCenter/Host using credentials from the Inventory Beacon's Password Store, targeting by IP Address


The above error refers to the failure of Step 2.
The best way to test if the Inventory Beacon Server has access to the VMware vCenter/Host is through a Web Browser with the following link, while having any Internet Proxies disabled (vimService.wsdl is case sensitive!):

https://IPAddress:PortNumber/sdk/vimService.wsdl (e.g. https://10.1.10.101:443/sdk/vimService.wsdl)

.
If you get an xml-formatted page or a login screen, then the test passed. If you get a "page not found" error, try the following to make sure it's not a firewall issue which this link should ask you for a login if it passed the firewall: 

https://IPAddress:PortNumber/mob (e.g. https://10.1.10.101:443/mob)

Possible causes are as following, sequenced by the most common:

1. A firewall is blocking the port between the vCenter/Host and the Inventory Beacon Server (above browser tests will both fail)
2. The target vCenter/Host does not have a SDK enabled/fully-enabled (above SDK browser test will fail)
3. The Local_Machine registry keys have forced policy to use an Internet Proxy, which would apply to the Inventory Beacon since it by default runs as the Local System account (above browser tests might succeed)
4. The current mgsipcan (Flexera's port scan tool) reported 443 as "filtered" not "open" which prevented inventory to proceed. (above browser tests will succeed).

Resolution

This can be resolved by identifying which of the 4 common causes and contacting the proper internal department (e.g. Network Security, Firewall Team).

If the issue is not due to the first three issues, then it could be due to cause #4. This can be resolved by downloading the attached MGSIPScan.zip to the inventory beacon server and unzip it to the following directory:
Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\MgsIPScan\ - overwriting the current contents.

mgsipscan port scanner.zip

[jjgarcia_sia]

Good evening/afternoon for everyone.

Happy new year.

Sorry to ask again, but we did more debugging on the issue, and it seems that the problem comes because the Dnslookup of the vCenter web interface returns a hostname that is different from the FQDN of the machine. Shared resources on this server that also has an ILO (remote control) interface . Because of the web server redirect is not succeeding; it always redirects to FQDN and  only works for the perfect FQDN , the remoteexecution from Beacon is not caching the 443 websso authentication as expected.

Setting the fqdn on the /etc/hosts has no effect as the nslookup talks only at DNS level.

There is any alternative to force the dnslookup resolution of the beacon to overwrite a hostname with another?. Any additional suggestion?.

Many thanks, Kind regards.