ESX Query tool working and vCenter Discovery & Inventory not

[oqueck]

Hi,

we've implemented FlexNet Manager Suite 2019 R2 and are wondering, why importing all VMware vCenter hosts is working fine when using the Flexera ESX Query tool, but when we want to achieve the same with our Discovery & Inventory rule no vCenters are discovered and no inventory scan files are created. Would the Flexera ESX Query tool be capable of collecting more information then FlexNet Manager Suite in certain cases like e. g. some free version of VMware or would could be the root cause for this different behavior and is there an easy way to figure this out ?

Thanks & best regards

Oliver 

[AamerSharif]

Would the Flexera ESX Query tool be capable of collecting more information then FlexNet Manager Suite in certain cases

Aamer: No it would not. ESX Query tool uses the same implementation. Free VMWare API restriction is within the VMWare API not in FNMS solution OR ESX Query tool

It looks like discovery process may not be discovering VMWare vCenter API. Please check the generated discovery file by vmware rule (created to collect VMWare inventory data), Is it in scope, If yes, discovery file should have port and VMWare API information. If discovery could not find API, it would not collect VMWare inventory. You a

Rule execution logs and generated discovery files, are good starting point (discovery and vmware inventory log) created by that rule execution to narrow down the problem.

This could be due to multiple reasons e.g. ICMP is blocked (inventory only option can help by setting the VMware vCenter Server and port on the discovered device through advance tab on discovered device properties and use known discovered device for inventory only), device not in scope etc.

Hope this will help to narrow it down.

Cheers

Aamer

[Anonymous · Accepted solution]

Hi @oqueck - Try setting the parameters in the attached screenshot if the discovery step isn't working. I wish the dependency on the network discovery scan would get removed, there's been many instances where ESXquery works fine but the beacon does not.

As far ESXQuery, I don't believe it brings in any vCenter license info so you may lose that if you decide to do the introspections outside of the beacon, however not sure if this is still the case with the latest version.

[oqueck]

Hi Peter,

your screenshot solved my issue.

Thank you soo much &

best regards

Oliver

[romanmensch]

Hello Community and Hello Oliver @oqueck ,

I have a vCenter that I can read out well with the associated VMs.
Now I have another vCenter from another organization that up until now only brings the nodes.

Do you think that is true?

It is because too few rights in the vCenter ? or as here describe the reg key setting?

Thanks a lot for help

[JohnSorensenDK]

@romanmensch 

Are you sure that you've collected inventory from the virtual machines belonging to the vCenter from another organization that only brings the nodes?

Also please be aware that the registry settings in above screen shots are a bit dated compared to the available configuration options as per the latest version. Please refer to online documentation for the latest and greatest configuration options.

Thanks,

[kclausen]

@romanmensch  - When connecting to vCenter, you will not see the individual VMs under an ESX Host until hardware/software inventory from the VM is received - either from a 3rd-party tool such as SCCM, or from the FlexNet Agent.

[romanmensch]

I guess that's it, thank you. In another cluster, we probably get all information from the SCCM or because the Flexera agent is installed on the VM's.

[DiannaB]

Hi @Anonymous ,

Do you know if this solution worked on a Windows Server 2019 Beacon (with FNMS 2019 R2 installed)?  We have the same issue so I added these two registry parameters but it didn't appear to make any difference.  We get two lines in our discovery log and then the beacon stops running other rules and we have to reboot the beacon to free it up:

2020-03-09 15:09:47,922 [iscoveryActionExecuter | Async] [INFO] Executing rule 'vCenter - XXXX....

2020-0309 15:09:47,938 [iscoveryActionExecuter | Async] [INFO] This task was run manually by 'xxxxx….

Thanks!

[DiannaB]

P.S. This rule works fine if we run it from a Windows Server 2012 or 2016 beacon.

[Anonymous]

Hi @DiannaB,

I haven't done any sort of testing on Windows Server 2019 so I'm not sure how that may factor into this. There may be a platform supportability issue with mgsipscan on v2019 but that's just a complete guess

[sasikumar_r]

Hi @DiannaB 

Is Scheduled tasks is also getting disabled on the Winserver 2019 where your Vcenter rule is configured?

Thank you

Sasi

[DiannaB]

Hi @sasikumar_r ,

At the time, we had not noticed the scheduled tasks getting disabled on the Winserver 2019 beacon where our Vcenter rules are configured.  We ended up re-imaging to Win Server 2016 because we were losing time and that was suggested by the consultant we were working with.  As it turns out, I believe 2019 would have been okay if we had spent more time diagnosing root cause.  I now believe that Symantec's IPS (Intrusion Prevention System) was killing our beacon traffic.   On our new Win 2016 beacons we discovered that pings would stop working for 5-10 minutes while IPS "locked" us out.  Once we got an exception added, we were back in business.  So maybe check with your Security team to see if that could be occurring.   

We have seen our scheduled tasks go disabled on our Win 2016 beacons so we followed this suggestion to resolve that issue:  Beacon scheduled tasks disabled

We monitor that file now and alarm if it disappears so we catch it faster. 

Dianna

[sasikumar_r]

Hi @DiannaB ,

We had the same issue on one of our Win2019 server, Scheduled tasks get disabled and discovery rules & inventory rules generating only discovery log.

Also we noticed npcap missing error message on the event viewer.  When ever the discovery rule is running npcap error exception get added into the event viewer log. 

i have created the attached batch file to check the availability of npcap once in a week and if it is missing it will copy it to the temp location. Soon after that task disabling issue and discovery rule issue is not appearing on the Windows 2019 server.

Thank you

Sasi

[ChrisG]

Thanks for sharing your batch script @sasikumar_r! Nice work.

The problem with errors about the missing npcap*.exe file appearing in the event long along with scheduled tasks being disabled was an issue in the 2019 R2 and R2.1 versions of the beacon software:

• The beacon installs a npcap*.exe file in a temp directory
• If somebody cleans up the temp directory and deletes the npcap*.exe then Windows Installer will notice the file has been deleted and automatically initiate a repair operation of the beacon MSI package the next time a discovery operation runs.
• The repair operation leaves the beacon scheduled tasks in a disabled state.

There is some more discussion about this problem in this thread: Beacon scheduled tasks disabled.

This problem has been addressed in 2019 R2.2 and later versions of the beacon (see issue IOJ-2094877 noted in FlexNet Manager Suite 2020 R1 Resolved Issues). In the meantime, the workaround .bat script that sasikumar_r has suggested is an interesting strategy to avoid the problem. The other mitigation approach is to avoid deleting the npcap*.exe file that gets installed to your temp directory.

[DiannaB]

@sasikumar_r   thank you for sharing your script!  We will definitely take advantage of this.  Appreciate the help!