Cloning may cause orphaned records in the discovery_credentials table, even if there is a data preserver set up on the target instance, as well as the table being added to the excluded tables list on the source instance. This should mean that the table does not get touched at all during the clone, however, it is causing orphaned records.
Symptoms include those listed in the article below:
KB0719158 Discovery Credentials - Orphaned cause "SEVERE *** ERROR *** An error occurred while decrypting credentials from instance"
Steps to Reproduce
- Create discovery credentials on your source instance.
- Create discovery credentials on your target instance.
- Preserve only the Credentials [discovery_credentials] table, and none of the child tables.
- Clone from your source instance to your target instance.
- After the clone has completed, browse discovery_credentials records on your target instance.
- Viewing the 'Record not found' message when trying to open a credential shows orphaned records have been generated.
This problem is fixed for specifically the discovery_credentials table from December 2019. Other table-per-class extended table may still have a similar problem during clones.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 consists in creating a Data Preserver record for each of the following tables:
|Ansible Tower Credentials||sn_cfg_ansible_credentials||Credentials|
|API Key Credentials||api_key_credentials||Credentials|
|Azure Enterprise Agreement Credentials||ea_azure_credentials||Credentials|
|Basic Auth Credentials||basic_auth_credentials||Credentials|
|Chef Server Credentials||sn_cfg_chef_credentials||Credentials|
|Cloud Management Credential||cloud_credential||Credentials|
|Azure Service Principal||azure_service_principal||Cloud Management Credential|
|Cloud Mgmt Credentials||cmdb_cloud_mgmt_credentials||Credentials|
|CMP Node Credential||sn_cmp_node_credentials||Credentials|
|CMP SSH Key Pair||sn_cmp_ssh_credentials||Credentials|
|Google API Credentials||gcp_credentials||Credentials|
|OAuth 2.0 Credentials||oauth_2_0_credentials||Credentials|
|SNMP Community Credentials (Password Only)||snmp_credentials||Credentials|
|SSH Private Key Credentials||ssh_private_key_credentials||Credentials|
Note: This list is from a New York Patch 2 instance that has most ITOM- and Integrations-related plugins installed. Your instance may not have some of those, or maybe additional ones. The following URL will list all the tables for your instance.
Please follow the steps below:
- Verify that the Discovery plugin is installed.
- In the Navigator, search for Credentials.
3. Verify there are a variety of credential types (SSH, Windows, SNMP).
4. On the source instance of a clone, type Preserve Data.
5. Select Preserve Data under Clone Definition.
6. Click on the New button.
7. Name your preserver (i.e. SNMP to preserve the SNMP credentials).
8. In the filter, type Credential, which should filter for all but the unusual names like Azure Service Principal and CMP SSH Key Pair, which would need a different filter)
9. Notice a host of tables, which are extensions of discovery_credentials, show up as suggestions.
10. Select the table for each type of credential (i.e. snmp_credentials to preserve the SNMP credentials).
11. Save the Preserver.
12. Repeat steps 6 to 11 for each distinct type of credential you use, and so need to preserve to avoid this problem. Although it would be safest to add preservers for all listed, only the ones you actually have records in must be preserved.
13. Go to your source instance and Request a clone using the target instance where you defined the new data preservers for each type of credential.
14. When the clone is complete, return to the Credentials list on the target instance.
15. Select one of the credentials. Notice the record will have been preserved and there are no orphaned records.
Note: When creating credentials on one instance, you should export the discovery credentials data using XML Export and import them into your other instances using XML Import. This will prevent creating the same discovery credentials data with different sys_ids.
Related Problem: PRB1305469