Discovery on windows server fails, credential test fails, but remote PowerShell from MID server works
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2019 09:39 AM
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
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2019 01:44 PM
The error message "...0x80070005 (E_ACCESSDENIED)" typically can be one of 2 things: 1) a bad credential or 2) a blocked port(s). If you resolve #1 and #2, then most of the time discovery will be successful.
For the error message you are getting, I always troubleshoot 2 steps specifically in the following order:
Step 1 (Validate Credential using RDP)
Both remote PowerShell and RDP are both valid methods to test the credential. I always test credentials using RDP, but other community members have mentioned using remote PowerShell for testing credentials as well.
Step 2 (Check WMI port 135 and port ranges 49152 - 65535 are open)
Check the high ports - the Windows firewall might be blocking them. Discovery uses WMI which initiates on port 135 and the remaining communication occurs on high ports (49152 - 65535) for a successful discovery.
I suggest completing steps 1 and 2 before moving on to other troubleshooting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-10-2019 07:35 AM
Thanks Chuck. The Credential Test from within ServiceNow fails. But remote PowerShell execution directly from the MID server is successful (using the same credential, of course).
I've asked the server admin to check the high ports...but wouldn't the remote PowerShell connection from MID fail if that's the issue?
Also, question about your port diagram. Is the remote management port 5985/5986 not used? I thought it was.
thanks again
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2019 07:04 PM
The reason why I don't use the Credential Test from within ServiceNow is that a failure does not indicate if it is a credential issue or port issue. Using RPC to test the credential from the MID Server can quickly determine if I have a valid credential - then I can move on to checking the ports.
I am not sure if the remote PowerShell uses high ports. RPC does use port 3389 and not the high ports.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2019 02:00 PM
Have you confirmed if the credential you have for Discovery has local admin rights on the device to be discovered?
Also, another thing we did here was setup the MID Server service to logon with the credential the MID server will use on other devices.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2019 03:59 PM
Is your credential record in the form of domain\user?