Discovery MID Server itselfIssue When you discovery Mid Server itself, you might see below warning message and Discovery failed. <Warning>User credentials cannot be used for local connections </Warning><Warning>User credentials cannot be used for local connections </Warning><Warning>User credentials cannot be used for local connections </Warning><Warning>User credentials cannot be used for local connections </Warning><Warning>User credentials cannot be used for local connections </Warning><Warning>User credentials cannot be used for local connections </Warning> ReleaseAll Fixed in Yokohama versionCauseThe root cause of this issue is a gap in the legacy WMI fields fetch flow, which requires a code fix. When executing the WindowsClassifyWMI probe, if the credentials provided in the discovery do not have PowerShell access, the legacy flow is used to fetch WMI fields. However, when the target is the MID server itself (localhost), this results in the error: "User credentials cannot be used for local connections."Resolution1. Update the WMIFetch.psm1 script file with the following updated code:Original Code:```pythonif ($cred) {$wmiClass = gwmi -namespace $namespace -class $table -computer $computer -credential $cred -impersonation impersonate -authentication packetprivacy -EA "Stop"} else {$wmiClass = gwmi -namespace $namespace -class $table -computer $computer -impersonation impersonate -authentication packetprivacy -EA "Stop"}```Updated Code:```pythonif (($global:isMid -eq $False) -and $cred) {SNCLog-DebugInfo "WMIRunner.psm1 with credential: $cred.username computer: $computer namespace: $namespace table: $table isMid: $global:isMid";$wmiClass = gwmi -namespace $namespace -class $table -computer $computer -credential $cred -impersonation impersonate -authentication packetprivacy -EA "Stop"} else {SNCLog-DebugInfo "WMIRunner.psm1 no credential computer: $computer table: $table namespace: $namespace isMid: $global:isMid";$wmiClass = gwmi -namespace $namespace -class $table -computer $computer -impersonation impersonate -authentication packetprivacy -EA "Stop"}```And using "Windows MID Server Service Account" as a credential is a workaround.1> create discovery credential affinity from "Windows MID Server Service Account" to target MID server IP2> remove other discovery credential affinities to target MID server IPRelated Linkshttps://support.servicenow.com/problem.do?sys_id=2e37b443475c1a5048cb2920326d432a