Discovery on windows server fails, credential test fails, but remote PowerShell from MID server works

[Bob D]

I have several windows servers on a subnet.   All but one are Discovered properly.  One fails.

from Discovery logs:

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))

also

{"credential_type":"Windows","credential_name":"Windows","credential_order":"100","credential_success":false,"credential_id":"9e.....................b0ee"},

And finally - A credential test on this server fails to connect.

Has to be a credential issue, right?  Or possibly network connectivity?

However - 

Windows admins are able to establish remote PowerShell connection from the MID server using the Windows credential in question and run simple commands such as  >dir c:\       

I don't believe I have any options from the ServiceNow side to change any configuration or setting to address this. Suggestions on what could be the issue on the server side if the remote PowerShell from MID server is working?   

thank you

[Ian Mildon]

Are you able to run the PowerShell connection with the failing credential from the MID Server? Also, can you make a successful Remote Desktop Connection to the server using the same credential?

If the credential is good, you should be able to do both.

[chuckm]

As Ian mentioned, if you are able to validate the credential using RDP then you know you have a good credential. RDP uses port 3389 which is a different port than ServiceNow Discovery uses.

Once you have a good credential, then I suggest you validate the ServiceNow Discovery WMI ports between the MID Server and the Remote Windows host are open (in the Windows Firewall and/or any firewall between the MID Server and the Windows host). ServiceNow Discovery uses WMI for discovery, therefore port 135 from the MID Server to the Remote Windows host must be open for initial communication AND high ports 49152 - 65535 must be open for the remainder of the communication. Even though this is a large range of open ports, only a portion of this range are dynamically allocated.

[Bob D]

Thanks guys -

Yes - Windows admins are able to establish remote PowerShell connection from the MID server using the Windows credential in question and run simple commands such as  >dir c:\

Have not tried RDP...but would that tell me anything given the above connection is successful?

That's what makes this puzzling.  What else is required if this test already works?

Port 135 is open, that's the only reason it's attempting the windows credential loging in the first place (for Windows Classify probe)

Port 5985 is open but 5986 is not (according to Shazaam input)

I'll check the high ports

[Ian Mildon]

If the Windows Admins are running the PowerShell with their credentials/logins, then it would work, even if the Credential entry for Windows fails. A lot comes down to the actual PowerShell script/commands they are sending and how the session is being established