--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Post-clone Discovery configuration # Post-clone Discovery configuration {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Post-clone Discovery configuration After cloning a ServiceNow instance, Discovery schedules are copied from the source to the target instance. However, additional post-clone configuration is required for these schedules to operate correctly, ensuring proper setup of Cloud-based and IP-based Discovery schedules and maintaining optimal system performance. Show full answer Show less ## Post-clone Configuration for IP-based Discovery Schedules Configuration steps depend on the MID Server selection method used in the original Discovery schedule: * **Specific MID:** Update the MID Server record for each Discovery schedule on the target instance. * **Cluster:** Create the cluster, attach the MID Server to it, and update the cluster name in the Discovery schedule. Alternatively, remove the MID cluster record from the Clone Exclude Tables to clone this data. * **Use Behavior:** Create or attach the required behaviors and functionalities, then associate the behavior with the Discovery schedule. * **Auto-select:** Verify that all MID Servers on the target instance have correct IP ranges, supported applications, and capabilities configured. ## Post-clone Configuration for Cloud Discovery Schedules After cloning, you must update the Cloud Service Account records to reference the appropriate Discovery credentials and update MID Servers similarly to IP-based schedules, based on the original MID Server selection method: * **Specific MID:** Update MID Server records for each Discovery schedule. * **Cluster:** Create and attach the MID Server cluster, then update the schedule accordingly, or remove cluster records from cloning exclusions. * **Use Behavior:** Create or attach behaviors and functionalities, then link them to the Discovery schedules. * **Auto-select:** Confirm all MID Servers are configured correctly with IP ranges and capabilities. ## Important Considerations * Credential aliases are cloned, but their actual credentials are not. You must verify and update credential aliases to point to correct credentials on the target instance. * No MID Server-related tables are cloned by default; these must be configured manually post-clone. * Discovery functionalities and behaviors are not cloned and need to be recreated or attached on the target instance. ## Additional Resources For more detailed information and troubleshooting, consult related knowledge base articles on instance cloning, MID Servers, and Discovery schedule management. 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. Note: For general information about instance cloning, see the [Clone FAQS-Frequently Asked Questions \[KB0715621\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=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\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0789119) article in the Now Support Knowledge Base. ## Post-clone target configuration for IP-based Discovery schedules {#PostCloneDiscoveryConfig__section_lkd_skl_kfc} After completing the [Request a clone](https://www.servicenow.com/docs/access?context=t_StartAClone&version=australia&pubname=australia-platform-administration&ft:locale=en-US) process, post-clone configuration is determined by the MID Server selection method you chose in the Discovery schedule on the source instance. {#PostCloneDiscoveryConfig__table_yb1_v45_nfc__entry__2} | 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](https://www.servicenow.com/docs/access?context=t_ExcludeATableFromCloning&version=australia&pubname=australia-platform-administration&ft:locale=en-US). | | 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. | [Table 1. Target instance configuration for IP-based Discovery schedules] {#PostCloneDiscoveryConfig__table_yb1_v45_nfc} ## Post-clone target configuration for Cloud Discovery schedules {#PostCloneDiscoveryConfig__section_nkd_skl_kfc} After completing the [Request a clone](https://www.servicenow.com/docs/access?context=t_StartAClone&version=australia&pubname=australia-platform-administration&ft:locale=en-US) 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. {#PostCloneDiscoveryConfig__table_pkd_skl_kfc__entry__2} | 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](https://www.servicenow.com/docs/access?context=t_ExcludeATableFromCloning&version=australia&pubname=australia-platform-administration&ft:locale=en-US). | | 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. | [Table 2. Target instance configuration for Cloud Discovery schedules] {#PostCloneDiscoveryConfig__table_pkd_skl_kfc} For more information, see the [Cloud discovery schedules fail after the instance clone \[KB1759363\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1759363) article in the Now Support Knowledge Base. ## Clone Exclusions {#PostCloneDiscoveryConfig__section_sxk_htl_kfc} 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\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0786475) article in the Now Support Knowledge Base. **Related topics** * [Managing Instance Clone](https://www.servicenow.com/docs/access?context=using-instance-clone&version=australia&pubname=australia-platform-administration&ft:locale=en-US)