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

[RamSagar]

We had orchestration to add the user to AD group after we upgraded instance to orlando, we are facing the below issue.

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

We didn't changed any service or password,but still we are facing the issue.

Could you please help me on this.

[Ashutosh Munot1]

Hi,

Couple of things to check:

1) Credentials and MID Server on that credentials.

2) What rights do you have with this account to do this operation.

3) Are this credentials stored in servicenow or external storage?

4) try to login to MID Server and then run WMI command to target machine to check the access.
See this HI.

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

• WMI, does the mid server service account have access to the targeted machine? What if a domain admin account is used as the mid server service account?
• From the command prompt on the mid server host, execute for runner_type=WMI
  
  wmic /node:"<target>" /user:"<user>" /password:"<password>" path win32_operatingsystem
   
• From within a Powershell console on the mid server host, execute for runner_type=Powershell
  
  gwmi win32_operatingsystem -computer <ip> -credential '<username>'
   
• It is possible that probe is timing out while waiting for a response. If the command is successful from a command prompt, try extending the wmi_timeout value of the probe.

Thanks,
Ashutosh

[sharepointau]

I have the same issue as @RamSagar . 
I have done all of the tests from the MID Server to the target. All successful.
I have validated the credential from SNow from the MID Server to the target on all ports.

I still get this error, and on some boxes get No WMIConnection... when clearly there is.

The account in use is in the Admin group on the target. 
I am using an external credential storage, but as previously stated the validation on this credential is successful. 

There is seemingly nothing keeping this discovery from happening. Any other suggestions? 

[Julie Gordon]

I ran into some where the error in the ECC queue didn't point to the actual problem.  Had an error about No Valid Credentials, but the problem was the UAC in the Windows OS.  Some showed the UAC off in the GUI, but it still didn't discover.  Finally when we changed the UAC registry key & rebooted, I was able to discover those servers.  Might be worth a look.  

Navigate to HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > Current Version > Policies > System. Double click on EnableLUA, verify if value is 0; if not, change it to 0.

[Dlam]

We started seeing this error since 15 January 2025, and it generated an error and stopped one of our workflows. Is this something to do with one of the Windows update?  Much appreciated.