Post-clone Discovery configuration
Summarize
Summary of Post-clone Discovery configuration
When you clone a ServiceNow instance, Discovery schedules are copied from the source to the target instance but require additional configuration to function correctly. This ensures proper operation of both Cloud-based and IP-based Discovery schedules and maintains optimal performance post-cloning.
Show less
Post-clone Configuration for IP-based Discovery Schedules
After cloning, the configuration depends on the MID Server selection method used in the source instance’s Discovery schedule:
- Specific MID: Update the MID Server record for each Discovery schedule on the target instance.
- Cluster: Create the MID Server cluster on the target instance, attach the MID Servers, and update the cluster name in the Discovery schedule. Alternatively, you can exclude the MID cluster table from cloning to avoid manual updates.
- Use Behavior: Since Discovery functionalities are not cloned, you must create or attach necessary behaviors and functionalities on the target instance, then associate them with the Discovery schedule.
- Auto-select: Verify all MID Servers on the target instance have the correct IP ranges, supported applications, and capabilities configured.
Post-clone Configuration for Cloud Discovery Schedules
Post-cloning, update the Cloud Service Account records to correctly reference Discovery credentials. MID Server configuration steps mirror those for IP-based Discovery schedules based on the MID Server selection method:
- Specific MID: Update each MID Server record.
- Cluster: Create the cluster, attach MID Servers, and update the cluster name or exclude the cluster table from cloning.
- Use Behavior: Recreate or attach behaviors and functionalities, then associate them with the Discovery schedules.
- Auto-select: Confirm MID Servers are properly configured with IP ranges, applications, and capabilities.
Credential and MID Server Considerations
- Credential aliases are cloned, but actual credentials are not. You must verify and update aliases to point to the correct credentials in the target instance.
- No MID Server-related tables are cloned, so MID Server configurations must be recreated or adjusted after cloning.
Why This Matters
Proper post-clone configuration is essential to ensure Discovery schedules function as intended, preventing failures and maintaining accurate discovery of resources. Following these steps helps maintain a stable and performant Discovery environment after cloning.
When a clone occurs, Discovery schedules are copied from the source instance to the target instance. Additional configuration is necessary for these schedules to function correctly on the target instance, helping you properly configure Cloud-based and IP-based Discovery schedules and maintain optimal performance.
For general information about instance cloning, see the Clone FAQS-Frequently Asked Questions [KB0715621] article in the Now Support Knowledge Base.
For instructions on how to deactivate or cancel a Discovery schedule after creating a clone, see the A Post-Clone script to Deactivate and Cancel Discovery Schedules [KB0789119] article in the Now Support Knowledge Base.
Post-clone target configuration for IP-based Discovery schedules
After completing the Request a clone process, post-clone configuration is determined by the MID Server selection method you chose in the Discovery schedule on the source instance.
| MID Server selection method | Next steps |
|---|---|
| Specific MID | Update the MID Server record for each Discovery schedule. |
| Cluster | Create the cluster, attach the MID Server to the cluster, and then update the cluster name in the Discovery schedule. Alternatively, remove the MID cluster [ecc_agent_cluster] record from the Clone Exclude Tables [clone_data_exclude]. For more information, see Exclude a table from cloning (legacy). |
| Use Behavior | Create the behaviors, create a functionality or attach an existing functionality, then go back to the Discovery schedule and attach the behavior to the Discovery schedule. Note: Discovery functionalities aren’t cloned with an instance. |
| Auto-select | Verify all MID Servers on the target instance are set up with target IP ranges, supported applications, and capabilities. |
Post-clone target configuration for Cloud Discovery schedules
After completing the Request a clone process, you must access the Cloud Service Account [cmdb_ci_cloud_service_account] table and update the service accounts with the proper reference to the Discovery credentials. You must also update the MID Servers for the Discovery schedule. Additional post-clone configuration is determined by the MID Server selection method that you chose in the original Discovery schedule.
| MID Server selection method | Next steps |
|---|---|
| Specific MID | Update the MID Server record for each Discovery schedule. |
| Cluster | Create the cluster, attach the MID Server to the cluster, and then update the cluster name in the Discovery schedule. Alternatively, remove the MID cluster [ecc_agent_cluster] record from the Clone Exclude Tables [clone_data_exclude]. For more information, see Exclude a table from cloning (legacy). |
| Use Behavior | Create the behaviors, create a functionality or attach an existing functionality, then go back to the Discovery schedule and attach the behavior on the target instance. Note: Discovery functionalities aren’t cloned with an instance. |
| Auto-select | Verify that all MID Servers are set up with target IP ranges, supported applications, and capabilities. |
Clone Exclusions
Credential aliases are cloned but their credentials aren’t cloned. If Discovery schedules have credential aliases, you must go to the Connection & Credential Aliases [sys_alias] table and confirm the alias points to the correct credentials. After cloning, update the Discovery schedules and add credentials within the target instance.
Additionally, no MID Server related tables are cloned. For more details, see the MID Servers and Clones [KBKB0786475] article in the Now Support Knowledge Base.