Clone Tips and Tricks - Support and Troubleshooting

Clone Tips and Tricks This article covers Cloning Tips and Tricks. Find out more about: preserving ATF jobs, issues with creating new clone target after instance rename, exclude and Preserve Users, Roles, and Groups, what tables not to include, and profiles.

This article is part of a 3-part series on Clones, including:

Clone Basics - KB1214608 Clone FAQs - KB0715621

.mce-toc { background-color: #f7f7f7; padding: 10px; border-radius: 5px; border: 1px solid #dedede; width: 70%; min-width: 500px; } Table of Contents How can I preserve my ATF jobs? I have renamed my instance and cannot create a new clone target? How can I exclude and Preserve Users, Roles, and Groups? What tables should I not exclude? How do Profiles work? Is the System Profile my default and should I use it? How can I preserve my ATF jobs? We have had many requests on how to preserve ATF jobs during a clone. Preserving is not the best option as ATF was not designed to work with preservers but it was designed to be moved via update sets.

The best option would be to move your ATF tests to Production via update sets, then when you clone prod over a sub prod the ATF tests are there for you to use. If you commit the ATF tests in prod it doesn't mean you need to run them in prod it just makes it much simpler to clone over as you don't need to worry about preserving anything in the clone.

Note: If you are currently testing an ATF job in a sub prod and it's not ready to be pushed to prod but you need to clone, then export the ATF test via an update set, clone over your target instance, and then recommit your update sets containing that ATF Test.

I have renamed my instance and cannot create a new clone target? After you have renamed your instance you have tried to log in to the instance and tried to create a new clone target for the instance, this will not work as the instance is already in your instance under the old name.

To fix this you can follow the steps detailed in Unable to add clone target after instance rename - KB0550896 .

How can I exclude and Preserve Users, Roles, and Groups? In some situations, you would like to not bring over the users from the source instance and only preserve the target instance's users. There are many different reasons for this and there are a number of ways you can achieve this.

Method 1 (Recommended): Preserve access and users in target without excluding.

You can preserve the access in a target instance with a simple group and preserver logic. You will not need any exclusions with this method (excluding sys_user or sys_user_role can cause broken references). Create a user group (e.g. “developers”) that contains all the users that should still have access after cloning Clone Source over target Disable all user accounts that should not have access after a clone Create a cleanup script to check all users that have access and are not part of the “developers” group, if found then disable If you need to preserve further roles/groups for the target instance you can add them in preservers The cleanup script will remove any new users that are copied from production but do not yet have a record on the target instance. It will find any users that are not linked to your “developers” group and set them to inactive. Future clones will now have the value as false and it will always keep working with adding/removing users.

Method 2 (Recommended): (Use with caution – can break related tables and instance functionality)

You can set up data excludes and preservers.

This is a trickier solution and means that when implemented that if you ever clone with the option to exclude tables unchecked, this will not work and will break future clones using this method. To do this you need to create the following Excludes : sys_user sys_user_role ** sys_user_has_role sys_user_group sys_user_grmember sys_group_has_role sys_user_role_contains cmn_notif_device customer_contact (only if you have the Customer Service Management plugin installed) This will not bring over any users from the source instance or any of the references to groups and roles, but now you need to preserve the sys_user in the target instance. Something that many people forget is you also need to preserve roles, groups, and also the links from users to roles and groups. This is a common mistake, and after cloning you are missing the admin role and cannot log in, this is because the links to the roles are missing. Now you should create these Preservers (add any conditions depending on your requirements): sys_user sys_user_role ** sys_user_group sys_user_grmember sys_user_has_role sys_group_has_role sys_user_role_contains cmn_notif_device customer_contact (only if you have the Customer Service Management plugin installed) This will preserve all the users, roles, and groups in the target instance, but it will also preserve the permissions of those users to those groups and roles. If you place these in your instance, after a clone you will have all the same users from your target instance and will still have all the access from before the clone. ** Treat the sys_user_role table with caution.

If you exclude/preserve the sys_user_role table; plugin-related roles can be excluded/preserved. The role can be missing on the target with the plugin being in active status if the plugin is in active state on the source and NOT active on the target. If a plugin is NOT active on the source and active state on the target, excluding/preserving the sys_user_role will create broken references as the roles will be available on the target without the plugin being active. The sys_user_role table has a unique index on name which makes it impossible to have duplicate role names. So therefore for records where index collision happens between source & target, target record will be preserved & source will be excluded. (Recommended to only preserve roles in target that are not in source, as this can break all references to the source role sys_id) For Example: If I preserved the role: TestRole Source: TestRole - sys_id = 77c8e0a61b88d10739e2f48b04bcbdc Target: TestRole - sys_id = 32f4f3t23b42a23425e1f63g12efase

After the clone we would only have the role from the Target instance, we will not have the role from source as we can't have both with the unique index. What tables should I not exclude? Upon looking at issues raised through Support we have seen a number of tables that have been excluded and caused issues after the clone, we recommend that if this table needs to be excluded that you also preserve it, or if you just wish to delete some of the data from that table to use a clone cleanup script.

Tables to not exclude:

sys_properties sys_properties is a base table that works with an instance's metadata and configuration. If excluded, the related information will be missing on the Target instance, where the config and metadata are transferred. If preserved, the sys_properties are preserved on the Target, where their related metadata and config are wiped out and replaced with the Source data.

sys_trigger sys_plugins (this can potentially cause the target instance to go down) sys_user (as stated before but if preserved with the other tables it should be fine) Any sys_* tables custom exclusion should be treated with caution as these table data from the source will be excluded on Target ( E.g. sys_app, sys_store_app and sys_scope exclusion can kill the modules if the application is not installed on the target) Excluding these can put your target instance into a bad state, and you will need to roll back the clone, adjust and clone again.

How do Profiles work? Is the System Profile my default and should I use it? When requesting a clone, you can select a profile, once selected then the clone profile automatically populates the clone request with your selected profile settings.

Here is some more information about Profiles, these profiles can be helpful when you have different settings to clone over different environments.

Clone Profiles for Clone Requests

NOTE: ServiceNow provides one profile called "System Profile" that will only include the OOB defined list of excluded tables, preserve data entries, and clean-up script. So this will NOT include the excludes / preservers you have created previously for your default clone. If you wish to keep using your default settings without profiles then leave the profile field empty when requesting a clone, DO NOT use System Profile unless you have configured it.

More information: Clone Profile : Behavior of table Excludes/Preserve during Clone - KB0855777