The Flexera Community is currently in maintenance mode to prepare for the upcoming launch of the new community. Click here for more information.
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
Jan 26, 2022 12:57 AM - last edited on Jan 31, 2022 08:50 PM by ChrisG
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.
Feb 02, 2022 01:06 AM
For vCenter inventory I do the following:
Jan 26, 2022 05:21 AM
@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
Jan 26, 2022 05:27 AM
@emtmeta - 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
Jan 26, 2022 06:48 AM
@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()
Jan 26, 2022 10:19 PM
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.
Jan 28, 2022 10:56 AM
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.)
Feb 01, 2022 05:10 AM
@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
Feb 01, 2022 11:47 PM
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.
Feb 02, 2022 01:06 AM
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'
Feb 03, 2022 03:30 AM
@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
Feb 03, 2022 08:58 AM
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
Feb 03, 2022 09:52 AM