WinRM Quick Discovery fails with “No creds found for type [Win]” when using MID Server service accou

[DhanarajG]

Hi Community,

We are trying to discover Windows servers using WinRM and the MID Server service account, but Quick Discovery fails with:

No credential found for type [Windows]
Active, couldn't classify: No WMI connection, now finished
Our configuration:

The Windows MID Server service runs under a domain service account, confirmed by the Windows administrator.
The MID Server connects to the ServiceNow instance using its configured instance username/password.
The MID Server parameter is set to:
mid.windows.management_protocol = WinRM
An active Windows credential exists with Use MID Server Service Account checked. Username/password are blank because we intend to use the service identity.
The credential is configured for the relevant MID Server.
Tests and observations:

The administrator successfully ran these commands using the service account:
winrm id -r:<target-hostname>
Both target servers returned an IdentifyResponse.
Shazzam reports port 5985 open, with Microsoft-HTTPAPI/2.0 and an HTTP 404 response.
In a failed Windows classification response, the debug information shows:
"credentials_attempted": []
That classification response also contains:
win_protocol = wmi
even though the MID has the WinRM parameter.
Testing the service-account credential through Test Credential returned:
A JSONObject text must begin with '{' … SNC_ENC_VAL[…]
Questions:

Is any additional configuration required for Quick Discovery to use the MID Server’s Windows service account with WinRM?
What could cause Discovery to report no Windows credential when an active service-account credential is available?
Why would the classification response show win_protocol = wmi despite the WinRM setting?
Could the SNC_ENC_VAL credential-test error be related, and which logs should we check?
Has anyone encountered this issue? Any troubleshooting steps or resolution would be appreciated.

Thanks!

[kmohammed]

Hi Dhanaraj,

Good troubleshooting so far. The most important clue is this line:

credentials_attempted: []

That means Discovery never resolved a credential for this MID Server and target at all, before it even got to trying WinRM versus WMI. Your winrm id test succeeded, so the account and WinRM connectivity from the MID host are most likely fine — the problem is on the Discovery credential-resolution side. I would work through it in this order:

1. Restart the MID Server after the WinRM parameter change

The mid.windows.management_protocol parameter is read when the MID Server starts, so changing it on the record alone is not enough. Confirm it is set to WinRM on the correct MID Server record (MID Servers > Parameters), restart the MID Server service, and then run Quick Discovery again. Until that restart happens, seeing win_protocol = wmi in the classification response is expected.

2. Check the credential scoping

The Windows credential must be Active, Type = Windows, and assigned to the same MID Server that Quick Discovery is using. Also check that no IP range on the credential excludes this target IP. If the credential is scoped to a different MID Server, or the run is using another MID, Discovery will report no credentials found even though the credential looks correct.

3. Check how the service-account credential is set up

For the MID Server service-account option to work, the MID Server Windows service itself must run as (Log On As) that same domain account, not Local System, and the credential must have "Use MID Server Service Account" checked with the username and password left blank. That account also needs local Administrator rights on the Windows targets and permission to use WinRM. If any of those three do not match, Discovery will not resolve it.

4. Run an isolation test with a standard credential

Create a temporary standard Windows credential with an explicit domain username and password for the same MID Server and the same target IP, and run Quick Discovery against it. If that works, the issue is specific to the service-account credential resolution. If it still reports no credentials found, the issue is the MID Server or IP-range scoping in step 2.

5. Do not chase the Test Credential error on its own

The "A JSONObject text must begin with '{'" / SNC_ENC_VAL error is commonly seen when testing a service-account credential, because it has no password value to test. Validate it with a real Quick Discovery run instead, and check the MID Server agent log on the MID host and the Discovery log in the instance for which MID Server was used and which credentials were considered for the run.

One more reassurance: the Shazzam probe returning 404 on port 5985 is normal for a WinRM listener (it is not an HTTP service), so that is not a failure by itself.

If the standard-credential test works but the service-account credential still does not, please share what the MID Server service Log On As account is and whether the credential is on the same MID Server — that will narrow it down quickly.

If this helped, please mark it as Helpful — and if it solved your issue, I'd be grateful if you accepted it as the solution.