If a customer uses only the service account on the MID server service for their Windows credential, and do not have any windows credentials in the credential table of the instance, all windows discovery probes return details from the MID Server host, and not the target that's meant to be scanned.
The WMI classify probe returns the hostname of the MID server, not the target.

This issue is maintained even if the following properties are explicitly applied to the MID server:
mid.powershell.use_credentials = false
mid.powershell.local_mid_service_credential_fallback = true

The fallback facility to use the mid service credential is no longer working. It is acting as though there are no credentials being used at all. Since you can reproduce this with:
mid.powershell.use_credentials = false
mid.powershell.local_mid_service_credential_fallback = false

Steps to Reproduce

On a Madrid Patch 3 instance:

  1. Install a MID Server on Windows, and run the service as a domain user that has local administrator rights on target discovered servers
  2. Do not add any Windows Credentials to the instance
  3. Discover a target IP, different to the MID Server host

The CI of the MID Server host will end up being linked to the Device History for the IP scanned.

Inspect the "Windows - Classify" ECC Queue input record, and the hostname and other details of the MID server host will be returned.

If Windows - Identity probe also runs, the IP addresses returned by that will be of the MID Server, and not include the expected target's IP, proving we are not scanning the target.


This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.

To avoid the issue, make sure valid Windows Credentials exist in the instance Credentials table, and can be used by Discovery MID Servers.

If you have never needed additional Windows Credentials, you can still add the MID Server's Windows Service login as user as a Windows Credential in the instance.

It is possible you also hit this bug because you have Windows Credentials, but none are active or assigned to the MID Server used by Discovery. This may also be the case after a clone, when credentials records may still have references to the MID Servers that only exist in the source instance of the clone, and in that case the Credentials need to be set to 'All MID Servers' or add the specific MID Servers of the clone target instance instead.

Related Problem: PRB1348739

Seen In

There is no data to report.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-11-15 11:07:33