Post-Cloning Checklist

A clone is a snapshot of a ServiceNow instance typically used to refresh your test or development environments. ServiceNow performs the cloning process, but there are several post-cloning tasks for you to perform as described in this article. For more information about cloning, see the Cloning Resources Page.

Finally, if you clone frequently, it might be helpful to develop a script that automates the execution of these post-clone tasks, as described in the last section of this article.

Post-clone tasks

Perform the following tasks after your production instance is cloned:

• Update the welcome page
• Change the email properties
• Restrict user access
• Modify LDAP to disable imports and updates.
• Disable active scheduled jobs

Welcome page

Verify that the welcome page message is active. Within each instance, welcome messages contain standard text that is displayed on the sign-in page for each instance, for example, text indicating that the instance is non-production or training.

1. Navigate to System UI > Welcome Page Content.
2. Open the Welcome to page.
3. Select the Active checkbox.

Email properties

Email is disabled during the cloning process and must be re-enabled. The process of configuring email properties is different for ServiceNow email servers and custom email servers. Users with the admin role can change email properties.

ServiceNow mail servers

If your instance uses ServiceNow mail servers, most of the important email properties are configured automatically. Cloning does not overwrite the email settings of the target instance although it does disable email.

To enable email:

1. Navigate to System Properties > Email.
2. Configure the email properties:
   
   • Enable email sending (SMTP) (glide.email.smtp.active): Yes
   • Enable email sending (POP3) (glide.email.read.active): Yes

   For more information, see Email Properties in the product documentation.

3. Click Save.

Note: If the instance is a hosted development instance being cloned to production, log a Case to have the mail server password set up.

Custom mail servers

If you are not using ServiceNow email servers, you must configure several ServiceNow properties. Edit email properties to avoid unnecessary messages being sent or processed by the custom mail server.

1. Navigate to System Properties > Email.
2. Configure the email properties as described in the table below.
   For more information, see Email Properties in the product documentation.
3. Click Save.

Note: Contact your mail administrator to set up the mail server password.

User access

Consider restricting user access to each environment using these guidelines:

• Development: Lock out all accounts except for administrators
• Testing: Lock out all accounts except for administrators and users actively involved in user acceptance testing for releases
• Training: Lock out users not participating in training

User access can be restricted through a script or manually on a per-user basis.

Update sets

Update sets are used to track changes made to a specific instance. Transfer update sets between instances to move customizations from development to testing environments and then on to a production system.

If you ever plan to upgrade an instance version outside of cloning, do not delete update set records. The upgrade process uses the records to restore your customizations.

LDAP

Disable imports and updates in the development and testing instances.

1. Navigate to System LDAP > LDAP Servers on a development or testing instance.
2. Open each record and clear the Active checkbox.
3. Click Update.

Scheduled jobs

Disable active scheduled jobs in the development and testing instances to avoid duplication of jobs and to provide a clean system for development. Always check for the instance name in the scheduled job so that the scripted schedule job runs only in one instance. In the example script below, the script runs only on the instance named my_instance_name.

1. Navigate to System Definition > Scheduled Jobs in a development and testing instance.
2. Open each active, scheduled job and clear the Active checkbox.
3. Click Update.
   
   EXAMPLE SCRIPT THAT CHECKS FOR THE INSTANCE NAME
   

   doSomething();
    
   function doSomething() {
     var thisInstance = gs.getProperty("instance_name");
     var instanceToRunOn = "my_instance_name";
   
     if (thisInstance != instanceToRunOn) 
       return;
   
     //start processing here
     gs.print('this is running');
   }

MID Servers

If you are using MID servers for Discovery or Orchestration:

• Ensure that the users configured on the MID servers in the config.xml file are also on the instance.

• Empty the ecc_sender folder on the MID Server queue. This gives the cloned instance a clear queue.

Troubleshooting the MID Server

Ensure that your MID Server user credentials match the credentials that all the MID Servers connected to the target instance are configured to use. It is possible that the source MID Server user credentials copied into the target instance do not match those used by the existing set of target MID Servers. Check MID Server Issues on the MID Server dashboard for post-cloning errors pertaining to the current MID Servers. The MID Server Issue [ecc_agent_issue] table stores records of MID Servers that are down after an instance clone and publishes error messages regarding suspected issues with bad credentials. Error checking in this table only examines MID Servers that existed on the target instance prior to the clone. You can view records from the ecc_agent_issue table in the MID Server Issues related list in the MID Server form. The instance retains records in this table for 30 days.

Automating configurations

If you clone frequently, it may be helpful to have a script that automates post-clone changes. The script must exist in your source instance so it is copied with the clone. Work with ServiceNow to add protection and ensure that you cannot run the script in your source instance. The following procedure includes a sample script that you can edit to fit your environment. Set the correct values in the first section.

Administrators can perform the following process. If the instance is running High Security, see Elevated Privilege in the product documentation.

1. Copy the script to any text editor and save it with a file extension of .js.
2. Upload the file to your source instance by navigating to System Definition > Upload File.
   This module uploads the file only to the current node.
3. Navigate to System Definition > Scripts - Background. You might need to enable the Scripts-Background module, as described in Enable or disable an application menu or module.
4. View and run the script.
   

   //define the instance names here
   var devInstance = "mydev";
   var devEmailRedirect = "myemail@mycompany.com";
   var qaInstance = "myqa";
   var prodInstance = "my";
    
   //get this instance's name
   var thisInstance = gs.getProperty("instance_name");
   switch (thisInstance) {
    case devInstance:
     devConfig();
     break;
    case qaInstance: 
     qaConfig();
     break;
    case prodInstance: 
     gs.print("**** You're running this script in production, are you asking for trouble?");
     break;
    default: 
     gs.print("**** I don't understand what this instance is for: " + thisInstance);
   }
    
   function devConfig() {
    //set the base color
    gs.setProperty("css.base.color","mediumseagreen");
     
    //disable email notifications
    gs.setProperty("glide.email.read.active",false);
   
    //disable all LDAP servers
    var ldap = new GlideRecord("ldap_server_config");
    ldap.query();
    while (ldap.next()) {
     active = false;
     ldap.update();
    }
   
    //set header name
    gs.setProperty("glide.product.description","DEV Instance");
    gs.print("Applied Dev Configurations");
   }
   
   function qaConfig() {
    //set the base color
    gs.setProperty("css.base.color","darkred");
    //redirect all messages
    gs.setProperty("glide.email.test.user",devEmailRedirect );
   
    //set header name
    gs.setProperty("glide.product.description","QA Instance");
    gs.print("Applied QA Configurations");
   }

All Releases

Perform the following tasks after your production instance is cloned:

• Update the welcome page
• Change the email properties
• Restrict user access
• Modify LDAP to disable imports and updates.
• Disable active scheduled jobs