junaid_vengadan
Level 7

VCenter Integration - Inventory Rule is not scanning VMWare

Jump to solution

I have created an inventory rule to scan vcenter inventory using one of my beacon ,  the rule was exact having duplicate actions of another working rule , but with different target.

 

When i u run the task from beacon, it just completed with only discovery action as per the logs ( note that i have both discovery and inventory actions mentioned in the role) 

On the communication part, i can open the vcenter client from same beacon server as well as i can telnet to VC via 443

 

i'm not sure how to troubleshoot or fix this issue as there is no error as well.

 

Regards

1 Solution

If you are relying on the discovery process to find installations of VMware VCenter or ESX before a connection is made to them to gather virtual inventory (which is typical), then ICMP is normally required - an IP address won't be probed by the discovery process unless it responds to a ping.

The following article discusses how to turn off this behavior: How to allow beacon network scans in a network with ICMP disabled. But apply that kind of configuration carefully, as it can make the discovery process take longer and generate more network traffic: it will probe multiple ports on all targeted IP addresses regardless of whether there is anything there.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

View solution in original post

11 Replies
adrian_ritz1
Level 9

For vCenter inventory I do the following:

  • Assign IP of the vCenter to a beacon from where I want to do the audit, in form of xxx.xxx.xxx.xxx/32
  • Modify the targets 
  • Assign target to rule
  • Schedule the rule to be run or wait till it's replicated to the beacon, and run from there

 

@adrian_ritz1  i have already added this IP as subnet/32 and added to a beacon and made this as one of my target in the rule.

 

But as i mentioned, it ran discovery (i guess port) and stopped without running VMware inventory.

Regards,

Junaid Vengadan

 

0 Kudos
kclausen
Level 14 Flexeran
Level 14 Flexeran

@junaid_vengadan - There are usually 2 causes of this scenario:
1) The "Action" for the vCenter Rule only has Discovery enabled and not Inventory
2) The Discovery task runs and it is not able to determine that the target server is running vCenter, and therefore it does not connect to the SDK to obtain inventory

For the second scenario, information from the Log Files on the Beacon Server may provide more information.
  Go to the Beacon Server, launch the UI and go to the Rules/Task Lists page
  Find your vCenter Rule and note the last date/time it was run
  In File Explorer, go to C:\ProgramData\Flexera Software\Compliance\Logging\InventoryRule
  Find the folder that matches that Data and Time
  Open up that folder and look for your vCenter Rule and view the activity

@kclausen  i have tried the same, nothing useful in discovery logs and no other logs are available.

 

I have tried adding following values in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Discovery\CurrentVersion by referring to another community article , then i got the following error in discovery log.

 

2022-01-27 08:14:11,629 [ource.NMapDeviceSource|IPScan] [ERROR] Failed to perform an IP scan.
System.IO.FileNotFoundException: Could not find file 'C:\WINDOWS\TEMP\ManageSoft\discovery\mgsipscan-t-2022127_81411-279eab5267-de78-4a8a-82ad-45bea4ce7974.xml'.
File name: 'C:\WINDOWS\TEMP\ManageSoft\discovery\mgsipscan-t-2022127_81411-279eab5267-de78-4a8a-82ad-45bea4ce7974.xml'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials, IWebProxy proxy, RequestCachePolicy cachePolicy)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
at System.Xml.XmlTextReaderImpl.OpenUrlDelegate(Object xmlResolver)
at System.Threading.CompressedStack.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.CompressedStack.Run(CompressedStack compressedStack, ContextCallback callback, Object state)
at System.Xml.XmlTextReaderImpl.OpenUrl()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlTextReader.Read()
at Flexera.RemoteExecution.Discovery.DeviceDiscovery.NMapDiscovery.<ReadDevicesFromXMLStream>d__5.MoveNext()
at Flexera.Beacon.Engine.ActionExecution.DiscoveryManagement.DeviceSource.NMapDeviceSource.PopulateDeviceCore()

0 Kudos

I had this issue after an upgrade to 2020R2.   Seemed they move to npcap instead of WinpCAP in previous versions.   Anyway....the version that shipped with the installer of npcap was 0.99 or something like that.   I had a support ticket in with flexera and they provided me a new version of npcap that was 1.0 or newer....and the issue went away for me.    They provided the new version of npcap...i just had to uninstall old and install newer.   then my discovery logs showed success.

 

Along the lines of @cdubs76's comments, the "Could not find file 'C:\WINDOWS\TEMP\ManageSoft\discovery\mgsipscan-....xml'." error could indicate some problem with the installation of components used during the discovery process.

To test that the relevant process is able to run, you could try directly running an MgsIPScan.exe process using a command line like the following, and checking the output for any indication of a failure:

"C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\MgsIPScan\MgsIPScan.exe" -p "T:22,80,443" -PI -sS -sU 192.168.1.0-255

 (NB. Use an IP address range that makes sense for your network at the end of this command line.)

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

@ChrisA 

one quick doubt here, by any chance ICMP Ping is required from Beacon to Vcenter for the VMware inventory gathering.

When i did this integration before it was only port 80/443 communication that was required.

 

Regards,

Junaid Vengadan  

0 Kudos

If you are relying on the discovery process to find installations of VMware VCenter or ESX before a connection is made to them to gather virtual inventory (which is typical), then ICMP is normally required - an IP address won't be probed by the discovery process unless it responds to a ping.

The following article discusses how to turn off this behavior: How to allow beacon network scans in a network with ICMP disabled. But apply that kind of configuration carefully, as it can make the discovery process take longer and generate more network traffic: it will probe multiple ports on all targeted IP addresses regardless of whether there is anything there.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
ChrisG
Community Manager Community Manager
Community Manager

I have just worked through a situation with similar symptoms to what are described here, and found that it was caused by the Windows WinHTTP subsystem having a proxy configured that was not forwarding network traffic generated by the beacon on to target VMware servers. The discovery process that runs on the beacon uses WinHTTP for communicating with VMware servers.

The following symptoms of this issue were evident.

Discovery.log showed that VMware was not discovered:

2022-01-25 00:25:33,055 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Performing VMware discovery for device 'vc101'
2022-01-25 00:25:53,960 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Completed VMware discovery for device 'vc101': not discovered

The beacon was able to connect directly to the target VMware server, as demonstrated by running the PowerShell Test-NetConnection cmdlet:

PS> Test-NetConnection vc101 -Port 443                                                                                                                                                                                                                                                                                                                                                                                                                                                       ComputerName     : vc101
RemoteAddress    : 172.3.4.5
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 172.6.7.8
TcpTestSucceeded : True

Output from executing netsh on the beacon showed a proxy was configured:

PS> netsh winhttp show proxy

Current WinHTTP proxy settings:

    Proxy Server(s) :  65.1.2.3:3128
    Bypass List     :  (none)

The WinHTTP proxy can be cleared as follows:

PS> netsh winhttp reset proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

The discovery succeeded after doing this, with the following details now appearing in Discovery.log:

2022-02-03 08:02:35,981 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Performing VMware discovery for device 'vc101'
2022-02-03 08:02:36,634 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Completed VMware discovery for device 'vc101': Name 'VMware vCenter Server', Port '443', Protocol 'https', Version '6.0.0', ApiType 'VirtualCenter', ApiVersion '6.0'

 

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

@ChrisG  thanks for the detailed observation and notes on the proxy related configuration which some times not easy to identify .

By the way , my issue is solved once we enabled ping from beacon to vcenter.

i still wonder why we need ping ( discovery option) for vcenter integration as we directly providing the vcenter IP and configuring rule to do only inventory.

 

Regards,

Junaid Vengadan

azam_tajammul
Level 3

I have exactly same issue, I have created a new rule and only getting discovery logs and no vmware inventory.

How can i solve it

0 Kudos