If there is an OAuth 2.0 type Credential [oauth_2_0_credentials] added to the list of Credentials in the instance, the instance will no longer return any credentials to the MID server when the MID Server tries to re-load the credential list. The MID Server will no longer be able to run any probes that requires credentials. This includes all Discovery, Orchestration, Event Management Connector probes, and others.

The MID Server agent logs will show a "SEVERE *** ERROR *** An error occurred while decrypting credentials from instance" when running each affected probe.

Steps to Reproduce

  1. Create a new OAuth 2.0 credential using an OOB OAuth Entity Profile (e.g. Google default_profile) on an instance with at least one MID running.
  2. Verify that an ECC queue output record has been processed by the MID(s) with the topic credentials_reload. The agent logs will also confirm this ran.
  3. Verify that in the agent log file for the MID(s) there is an exception that looks like the following. This is the exception thrown when no key element is found in the response (i.e., the response is empty)
SEVERE *** ERROR *** An error occurred while decrypting credentials from instance
com.snc.automation_common.integration.exceptions.AutomationIOException: Unable to retrieve data from instance. This MID may not be validated. <<<=== Red Herring - The MID Server is Validated.
at com.glide.util.MIDServerInfoPayloadDecrypter.decryptPayload(
at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.loadCredentials(
at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.load(
at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.init(
at com.service_now.mid.creds.provider.MIDCredentialsConfigProvider.getCredentialsProvider(
at com.snc.commons.credentials.CredentialsProviderFactory.getCredentialsProvider(

Lines below this in the stack trace will be specific to the probe running.


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.

The Workaround is to ensure the affected MID Servers do not have any OAuth Credentials set up for them:

  • Deactivating all OAuth 2.0 Credentials in the Credentials table will workaround this issue, however they will then not be available to the features that require them.
  • If OAuth Credentials are still needed to be Active for integrations or other features, set the Credential up to "Applies To:" "Specific MID Servers", that are not used by discovery or other features broken by this problem. You could even specify a fake MID Server record [ecc_agent] that is set as Down.

Related Problem: PRB1342894

Seen In

Madrid Patch 2

Intended Fix Version


Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-06-19 03:12:03