Hi,
Below are the best practices as suggested by ServiceNow
Post-cloning checklist
Overview
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.
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
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.
- Navigate to System UI > Welcome Page Content.
- Open the Welcome to page.
- Select the Active check box.
Email is disabled during the clone 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:
- Navigate to System Properties > Email.
- 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.
- Click Save.
| Note: If the instance is a hosted development instance being cloned to production, log an incident 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.
- Navigate to System Properties > Email.
- Configure the email properties as described in the table below.
For more information, see Email Properties in the product documentation. - Click Save.
| Property | Setting required |
| Enable email sending (SMTP) (glide.email.smtp.active) | Yes |
| Enable email receiving (POP3) (glide.email.read.active) | Yes |
| Outgoing (SMTP) mail server (glide.email.server) | URL to your SMTP server. For example, smtp.yourdomain.com. |
| User email (eg. helpdesk@company.com) that is used to login to the SMTP server optionally. (glide.email.user) | Email address to use for SMTP authentication. For example, smtp@yourdomain.com. Define a different email account for each instance. |
| Outgoing (SMTP) mail server password. (glide.email.user_password) | Password for your SMTP server. |
| Email address to which all emails will be sent. (glide.email.test.user) | Email address to use for testing. Allows you to enable notification but direct all messages to a single mailbox. |
| 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.
- Navigate to System LDAP > LDAP Servers on a development or testing instance.
- Open each record and clear the Active check box.
- 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.
- Navigate to System Definition > Scheduled Jobs in a development and testing instance.
- Open each active, scheduled job and clear the Active check box.
- 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.
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.
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.
- Copy the script to any text editor and save it with a file extension of .js.
- Upload the file to your source instance by navigating to System Definition > Upload File.
This module uploads the file only to the current node. - 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.
- View and run the script.
//define the instance names here var devInstance = "medev"; var devEmailRedirect = "myemail@mycompany.com"; var qaInstance = "meqa"; var prodInstance = "me"; //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"); }
Kind Regards,
Satyaki Bose
Technical Support Engineer - UX
ServiceNow | Works for you
MARK THE ANSWER AS HELPFUL IF YOU ARE SATISFIED WITH THE SOLUTION
