When discovery via WMI takes too long time, vScope will abort the session as a safety routine. The result is that no or only partial data is recorded from the machine. Troubleshooting for WinRM is on the second section of this article.
No discovery results from WMI
Possible cause 1 – Damaged WMI repository
Investigate the WMI repository in these steps
- Open the command prompt an a machine with suspected WMI problems. Make sure you have administrator privileges
- Run the command
winmgmt /verifyrepository - If the repository is OK the response should be
WMI repository is consistent
- Run the command
- After this, run WMI Diagnosis Utility from Microsoft on one of the machines having WMI trouble. Download here: https://www.microsoft.com/en-us/download/details.aspx?id=7684
- Run WMIDiag.exe and choose where files should be extracted
- Open the command prompt with administrator privileges
- Go to the folder where WMIDiag.exe files were extracted and run the script cscript WMIDiag.vbs. The script will analyze WMI in different ways and report. This may take several minutes
- Three files are created, names something like this:
- %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_2017.01.25_09.32.46.LOG
- %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_2017.01.25_09.32.46-REPORT.TXT
- %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_2017.01.25_09.32.46-STATISTICS.CSV
- Analyze the files for possible problems. We offer help though our support if needed.
Possible cause 2 – Long latency
If a machine takes too long to respond, it could be due to long latency in the discovery. This may happen if the discovered machine is on a slow network connection, e.g. when being on a remote site. the solution could be to let a vScope proxy handle the discovery of the remote site. Read more
Additional troubleshooting
Looking in the Discovery logs you might find error codes that can be used to troubleshoot the root cause of WMI timeout. Here are the most common error codes:
0x800705AF
(The paging file is too small for this operation to complete)
This happened when vScope queried the Win32_OperatingSystem class for very basic system information. The error seems to have something to do with the page file on the scanned machine. I’ve googled for an explanation and found that WMI might leak memory on some Windows 2008 Server machines. There should exist a patch to remedy this. Windows 2008 Server R2 SP1 apparently includes this patch. Do the affected machines have SP1 in place?
0x80041013
(Provider not found)
This happened when vScope queried the Win32_ComputerSystem class for very basic system information. The error seems to indicate that the WMI-provider providing this data could not be found. It is a standard provider and should be available. I suspect it is a result for the previous error (0x800705AF).
What versions of Windows are the machines running running? Patch status? Do they have at least 2008 R2 SP1?
Even if machines are running WinRM to scan the machines, The WMI registry is queried for specific information so toggling WinRM on/off will not change anything.
No discovery results from WinRM
When troubleshooting WinRM, start by doing the following:
Try a different domain format
Try a different domain format for the credential. For example, use DOMAIN\CREDENTIAL instead of CREDENTIAL@DOMAIN.
Confirm WinRM access
Can the credential access target machines with WinRM? Confirm access with this article: https://support.vscope.net/how-to-confirm-winrm-and-remote-scripting/
Enable WinRM on target Machines
Make sure that WinRM is enabled on the target machines. https://support.vscope.net/how-to-enable-winrm-on-windows-servers-clients/
Firewall access
Make sure the firewalls are open. Is your WinRM port default or set to a custom port? https://support.vscope.net/what-ports-are-used-by-vscope/