Where are the WMI Commands Located for Probes

[Mason Angus]

I have been having an issue with Windows Credentials for my Discovery. I have been through a laundry list of trouble shooting steps including remote connecting to a target server from the mid server host via WMI, connecting using a powershell commands, RDPing using the wmi credentials on the instance from my computer, and RDPing from the mid server host machine with the same credentials. All of these methods have comeback clean but I continue to receive this error back in the ecc from the windows classifier probe:

<error>Authentication failure with the local MID server service credential.</error>
<error>Failed to access target system. Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))</error>
<debug_info>{"debug_info":[{"xxxxxxxxxx":{"creds_failed_trying_local_mid_cred":true,"credentials_attempted":[{"credential_type":"Windows","credential_name":"WMI Credential","credential_order":"100","credential_success":false,"credential_id":"*windows credentials*"}],"local_mid_credential_success":false,"connection_parameters":{"credential_types":["Windows"],"target":"xxxxxxxxx"}}}]}

 I'm now getting our Windows server team involved but the problem is I want to be able to show them the actual command the midserver is sending that is responsible for trying to log onto these target machines. I can not seem to find them on the instance under any of the windows probes.

As a follow up, we are running on New York, would it be a good idea to try and do a migration from probes to patterns for windows devices? I have heard patterns cam make trouble shooting a lot easier. 

Thanks in advance

[SteveJoe]

Hello,  It looks like there may be two issues you are having..  the first may be that you need to Configure the MID Server to use Powershell by setting the mid.use_powershell parameter to true

and the second when looking in the payload above at the 'creds_failed_trying_local_mid_cred":true' is stating the configuration parameter to the MID Server Mid.powershell.local_mid_service_credential_fallback = true

you may want to consider setting this to false, this will avoid the MID Server Services Log On credential to be used as the last resort.

(See the following product documentation for this may help:

https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/product/credentials/reference/r_...)

Have your tried to discover your MID Server first? If you have not tried doing a test credential or running discovery to your MID Server first, I would suggest doing that.

[Rahul Priyadars]

Hi ,

I assume you tried all.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0787202#:~:text=This%20error%20is%20usually%...

https://hi.service-now.com/kb_view.do?sysparm_article=KB0657528

See if you having this known issue - https://hi.service-now.com/kb_view.do?sysparm_article=KB0549834

Regards

RP

[Ashutosh Munot1 · Accepted solution]

Hi,

Basically when you run discovery/Orchestration then first thing discovery will do is it try the credentials. Now where this happens is on MID server we have Script files.

1) If its a Windows Machine then it use WMI to test the credentials and gwmi.

2) Script which is triggered is : credentials.psm1 which is stored in Scripts folder under your MID server folder. In that you have WMI script folder and you will find this script there. In that script check function testCredentialWMI.

3) Check this as well : https://hi.service-now.com/kb_view.do?sysparm_article=KB0564282

4) https://community.servicenow.com/community?id=community_question&sys_id=4ad529a1db52ef004abd5583ca961930

5) https://hi.service-now.com/kb_view.do?sysparm_article=KB0787202#:~:text=This%20error%20is%20usually%20associated,again%20from%20the%20ServiceNow%20Instance.

Thanks,
Ashutosh

[Mason Angus]

I may be looking in the wrong place but within the WMI script folder for my mid server I only see two files, a "WMI Runner" and a "WMI Scanner". Is there another location this script could be in and could this perhaps be the cause of the credential issue?