Advanced Discovery Troubleshooting - WMI

[doug_schulze]

My friend in the BRK showed me this handy little way to help prove a WMI connection outside the midserver but using the same components asking the question. This can come in handy when you can't figure out why you are having problems connecting to a Windows OS and want to see the raw return before the "machine" starts processing it.

*As always be careful whenever stepping outside the controls of the UI, this process will have no more impact then a regular discovery but you want to be sure you have the necessary understanding of how scripting works, do this with an idle mid server application and the ability to understand the returns...have fun, this can be very helpful to prove where the problem lies...

1. RDP to Midserver host as the Midservers 'runs as' user
2. Open a command prompt and navigate to your midserver /agent folder
3. Create a script (test.js) with the necessary query you are trying to re-create, below is an example of a single command trying to pull back an Operating System value


var scanner = getScanner();
if (scanner) {
scanner.addFetch('Win32_OperatingSystem.Caption');
scanner.fetch();
}


4. After you save it, type and execute the line below

cscript lib\WMIRunner.js [IP of the target] test.js

5. Review results


Again, this can help with troubleshooting connecting to a machine for the first time or fixing a troublesome probe...Knowledge is power... enjoy

[DanLevin]

Hey Doug, I've found another cause and solution for the "Connection failed to WMI service. Error: Permission denied" error.

We recently stood up a new instance, and I found that the MID server associated to it was returning the "Connection failed to WMI service. Error: Permission denied" error when attempting to discover windows CIs. After verifying that the account running the MIDServer sevice was correct (an active directory service account, in our case), and determining that it was not plagued by an unannounced password reset or account expiration, I started searching for issues elsewhere.

I had set the following parameters for the MID server to use PowerShell:

mid.use_powershell

mid.powershell.use_credentials

I had set the value for these parameters to "True" with a capital "T". While configured in this fashion, discovery was returning the "Connection failed to WMI service. Error: Permission denied" error.

To resolve the issue, I had to set the value for the two PowerShell parameters to "true" with a lowercase "t". Once this change was made, Discovery behaved as desired and was able to successfully discover the windows CIs within our discovery schedule.

Hope this helps!

Dan

[glennpinto]

This is a key error message ""Connection failed to WMI service. Error: Permission denied" This error message signifies that the Windows service credential is being used and is failing. If this is the only authentication error message being received, then the culprit is usually that PowerShell is not enabled correctly as you found out. If PowerShell is not enabled correctly then any Windows credentials defined in the SN Credentials table are not being used and only the MID Service Credential is.

In Fuji, this parameter is turned on by default on the MID Servers (thanks development), however PowerShell 2.0 must also be installed on each Windows Server MID or must be verified that it is installed.

[Ankush13]

This is a great post for servers which are in domain.

What if the server that we want to troubleshoot is a WORKGROUP server and not in domain? I have come across this situation many times.

While I was troubleshooting this, I did the following:

1. Connected the WRKGRP server from MID server via WMI -- Success

2. Added credentials in credentials table with .\username and ran the discovery -- Active, couldn't classify

In this case, it is not possible to login to the MID server as the local account that was created on WRKGRP server.

[doug_schulze]

The same troubleshooting should work, Ive even adapted to using a straight wmi query from the midserver host using this command..

wmic /node:"10.0.0.1" /user:"domain\user" /password:"password" path win32_operatingsystem

Replacing the necessary IP/user/pass values..

The one main thing you might come across is that if you have User Access Control (UAC) enabled you cannot make remote WMI queries, it has to be a domain user.. So check to see if that is enabled..

[Ankush13]

That wmic query will come in handy for sure...

If we are able to connect from MID --> WRKGRP server via wbemtest successfully, then I guess UAC as a probable cause can be eliminated.

There are instances where wbemtest is a success. Discovering them is not.