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

[Community Alums]

It almost sounds like the MID server is using the local account to run the discovery instead of whichever AD account you set up. I've seen this a few times and usually some type of force password reset or password expiration was the root cause.

[glennpinto]

Gary you have to verify that PowerShell is properly configured on your SN instance and MID to take advantage of any Windows credentials other than the service credential defined on the MID Server itself. Enabling and configuring PowerShell has been simplified in each release so how you do it will depend on the version of SN you are running. Affinity cannot mess up your discovery, just streamline it. If an affinity is not working, then Discovery will try each of the credentials based on type by the order specified in the Credentials table. Again none of the windows type credentials stored in the Credentials table are being used unless PowerShell is setup correctly, so I would verify that first.

One simple test is to discover any Windows system on your network based on a credential you defined in the Credentials table that is different from the one you defined as part of the Service Credential on the MID Server itself. If a credential affinity is built, then PowerShell is setup correctly for that MID. You will have to verify all your MIDs. You can browse the affinity table by navigating to dscy_credentials_affinity.list

[Ankush13]

Imho, powershell is correctly configured as he is able to discover his own machine but a fellow machine fails.

[glennpinto]

That doesn't necessarily mean PowerShell is correctly configured. Where is the MID? If it is on a different machine other than his own machine, then is the MID Service credential sufficient to discovery his machine, if it is, then PowerShell can still be misconfigured. I would check and see if an affinity was built with the Windows credential that you believe should be used to discovery his own machine. If it was, then PowerShell should be configured correctly.

[garyopela]

Yes, prdelong, this was it. Somehow the windows service was changed to use local account instead of AD account I had set up. I checked my other mid server services and they were still set up correct, but unfortunately i am not using any of them 😕