The goal of this article is to answer generic frequent requests/questions ServiceNow Technical Support receives in relation to clones. I if you have follow-up questions, please contact Technical Support.
NOTE (6/8/2021): Progress and automation milestone updates can be found within the clone history record on the source instance. Currently, these milestone updates are also available in this Change Request, which results in automatic email notifications. However, moving forward, only some of these milestone updates will be available in this Change Request but all of them will continue to be available within the clone history record on the source instance. If email notification is desired for any of the milestone updates, please follow instructions in KB0966447 - Email notifications for clone to create custom notifications in the source instance itself.
NOTE: If you would like to provide feedback or have any questions please leave comments on this blog: Clone - Frequently Asked Questions - F.A.Q
NOTE: If you are experiencing issues with attachments missing after clones this is because of a known issue that was fixed in Dec 2018 and is working as designed
NOTE: I have included an XML file (cloneFAQ.xml) if you import this XML file into your instance it will create a module link in your instance which will show under clone and it will redirect to this FAQ page for up to date information about clones.
NOTE: If you are not able to cancel your clone using the link on the clone form, it might be due to a missing field on the form. This is probably because the form has been customized. More details in the Can I rollback my clone? The section on how to fix and make this work.
In response to a clone request, the ServiceNow platform performs the following tasks:
This file contains the data preserved by data preservers.
As we take a backup of the database after the cloning process we can roll back the clone up to 7 days after the clone was run.
To request a rollback please raise a case in NowSupport to request a rollback of a clone.
Madrid and above:
After a clone is complete there is a UI action 'Rollback clone' if you click this button it will roll back the clone using the same automation that Technical Support will use to roll back the clone.
Any issues faced or clarification about the rollback of a clone please contact Technical Support and we will be happy to help.
If the Cancel clone link is not working or responding, it has been related to a field "Cloud details" not being on the form. The reason this field has not been added to your form is because it would have been skipped as you have customized the clone form.
To resolve the issue, please navigate to the clone Form and revert it to the base version. This will enable the "Cloud details" field on the form and then the "Cancel clone" link will work.
Another option is to configure the clone Form and add the "Cloud details" field on the form.
In London we added the feature: Amount of data copied from the Task table, see Request a clone [London documentation]
|Exclude tables specified in Exclusion List||Prevent cloning records from the source instance specified in the System Clone > Exclude Tables module. Use this option to create empty but usable tables on the target instance. By default, the system excludes tables for auditing, license usage, logging, and notifications. This option is selected by default.
Note: This option is not supported by the legacy clone engine.
|Exclude audit and log data||Prevents cloning audit and log records from the source instance. Use this option to create an empty but usable audit and log tables on the target instance. This option is selected by default.|
|Exclude large attachment data||Prevents the cloning of large attachments such as video files, image files, and other typically large binary file types. Excludes all common binary file types, regardless of file size. When selected, the clone also excludes attachments from the Attachments [sys_attachment] and Attachment Documents [sys_attachment_doc] tables that meet all these criteria.
This option is selected by default.
|Amount of data copied from the Task table||Select the amount of data to clone from the source instance Task table. By default, the target instance receives the last 90 days of Task table records from the source instance.|
|Preserve theme||Enables data preservers for the target instance theme and CSS elements. This option is selected by default.|
Clone requests always use the latest backup for the source instance,
If you wish to have a fresh backup be taken just before the clone is kicked off you can do this by raising a case in NowSupport so that your instance to be added to on Demand Backup list to take a backup just before the clone
Get a "List of Available Backups of an Instance" from Now Support (HI)
This error message happens when the instance is being repointed to the new database and a health check is done on the node and it is offline causing this message. This can be safely ignored as the clone is working as designed it is just a timing issue with the health check.
This is a known problem, see KB0689695: Node in charge of the clone generates an offline error message on the instance clone history.
This error message happens when you are trying to clone over an instance that is too small and is not set up to grow in size.
Demo and POV instances are built to only grow to a specific size, so they can be cloned too if the source instance is also small, but once it grows to a specific size you cannot use Demo or POV instances for cloning. You must then clone over a sub prod instance (which has the capability to grow in size)
Also to note we cannot increase the size of a demo or POV instance, we will always request to clone over a sub prod instance.
This happens more often than you would think.
When cloning over an instance it brings the settings from production this can include SSO and login functionality that can cause you not to be able to login into the sub-production instance after the upgrade.
This illustrates the benefits of always having a local account you can always log into, not only just for cloning.
To avoid this issue from happening for cloning you can do the following.
Method 1: Create a local admin user on the source instance.
Method 2: Create local admin user on target instance and include preserver.
More information can be found in KB0717012 - Clone results based on Exclusion and Preserver configuration
var instanceName = gs.getProperty('instance_name');
if (instanceName == 'testdev')
// Do specific jobs for dev instance
else if (instanceName == 'testsandbox')
// Do specific jobs for sandbox instance
This is as designed, if you clone with excluders you are excluding the sys_audit table, the sys_audit table is used to keep the user, date and time for each comment and update so without the sys_audit it will use the sys_created_by and sys_created_at fields for all comments on the record.
If you view the history of the record all the updates will show as update 0
More information can be found in KB0690828: Cloning - Activity formatter and Audit not showing correct user and time.
When you click on the UI to submit a clone, a record is created in the clone table, if you do not proceed with the clone or click out of the pop-up window the record will stay in your system as a 'draft' but this can be safely ignored. The reason these cannot be deleted is that they have a link to an internal instance at ServiceNow which manages the Clone requests.
More information can be found in KB0694499 - Several clones in the state of 'Hold'
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
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 KB0550896: Unable to add clone target after instance rename.
When someone asks to do a full clone this means that when you clone you should untick all the exclude options. If you are in London you will also have the option Amount of data copied from the task tables you should set this to all.
This means no excluders will run in the clone and it will be as close to a replica of your source instance as possible.
Yes, as when you are cloning you are making a replica of your source instance, so it will match in table structure and version.
So if you clone a Kingston over London, the target instance will be a Kingston release.
If you clone a London over a Kingston, the target instance will become a London release.
This error appears in your instance clone history and is a known error that is fixed in Madrid, this is tracked in PRB1262541/KB0689695: Node in charge of the clone generates an offline error message on the instance clone history.
This is a cosmetic issue only and is not an indicator that the clone has failed, if you check and see that the change request in HI is completed successfully then the clone has completed successfully and you can safely ignore this message.
When cloning you may get an option to select either Standby database and Source instance.
This is an old option and is no longer needed when requesting clones, it is removed in the newer releases and you shouldn't see it appear, but if you still see it appear you can safely leave and ignore this option.
In some situations, you would like to not bring over the users from the source instance and only preserve the target instance's users. This will step you through the best way to exclude and preserve Users.
To do this you need to create the following Excluders:
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, but 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)
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.
When cloning over an instance you may experience the issue that your text searches are not working.
This is because one of the clone cleanup scripts that run after a clone completes is to reindex this instance for search, while this is running your search will not work.
If you look at jobs running you will see text index events process, if you look on your stats.do you will see something like this:
You can monitor this to completion, once done your search functionality will start to work.
You may have realized that lately, after your clones have been completed, you are missing attachments in the target instance and has been causing issues.
This is actually working as designed but this exclusion started to work correctly after December 2018 after an internal problem was fixed with the clone automation. This is outside the ServiceNow releases so this will affect all releases and all clones from then. The fix was for the clone option: Exclude large attachment data.
As documented in the previous question: What do all the options do for cloning?
It states it will remove sys_attachment records that don't meet that criteria, it is not based on the size as the name suggests.
So this is working now as designed and documented through our documentation if you wish to keep your attachments you will need to uncheck the Exclude large attachment data checkbox upon cloning.
In some cases when testing plugins in your target instance you wish to preserve these plugins so you can continue to test out these plugins and work on them.
Unfortunately, the way we do clones we do a restore of the source instance over a new database, after the clone you will need to activate the plugins again or request them via HI if required.
When cloning you may want to preserve certain records on your target instance like for example some incidents, you also want to make sure after the clone that the attachments linked to these incidents are preserved also.
Currently, in our automation, if you preserve a record that has attachments we automatically preserve those attachments without having to create another preserver specifically for the attachment table.
This is risky and would advise against it but in some cases, you may want to perform a clone over your production instance, this may be for a go-live if your instance is already live this is not a good idea, and would advise you to contact Technical Support for assistance.
To add your production instance as a clone target you can follow the below steps:
This will now allow this instance to be created as a clone target
Cloning over this instance is the same as any other request for a clone. After cloning is complete this property should be then set back to 'false' so you don't accidentally clone over your prod instance later.
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
Excluding these can put your target instance into a bad state, and you will need to roll back the clone, adjust and clone again.
This is a very common question that comes up to support. You enter in an excluder but after the clone, the data is still there.
This can be a number of different causes:
The system cannot exclude tables that extend the Task table and are also flattened into it as part of the table per hierarchy extension model. Since these extended tables are actually part of the same physical database table, the system clones the data when it clones the Task table. You can exclude tables that extend the Task table under two conditions. Either the system stores the tables in their own physical tables as part of the table per class extension model, or you exclude the Task table itself.
A common question, you have just adjusted your excluders or preservers and want to know if you have to wait for some time before cloning. The answer is NO, once you change the excluders and preservers, those changes will be enforced in the next requested clone.
On occasion after a clone before turning on email you see that your production email account has been copied into your sub-production instance. You then check that you did have the exclude tables option checked but still seem to have come across.
When this issue has happened it is because normally on one occasion you have cloned to a sub prod and not excluded the table, therefore the sys_email_account has been copied across to your target instance, then you have a preserver for sys_email_account so it would have been preserved every clone after that.
Workaround: Clone Cleanup Script
// Add sys_ids to the encoded query (queryString) // Like queryString = "sys_idIN206594e8db9eb3002e14c6fc34961998,6ab25213db003300eaf8e64305961927" var queryString = "sys_idIN"; var emailclean = new GlideRecord('sys_email_account'); emailclean.addEncodedQuery(queryString); emailclean.deleteMultiple();
This will mean after all clones it will delete these sys_email_accounts even if they were cloned over or not. If you add new email accounts you will need to add to this script, but this will stop the email accounts from ever coming from your source instance.
Recently we have seen an increase in this issue. After requesting a clone and unticking the exclusion options after the clones it seems like excluders still run why??
This has been linked to a UI change in the request form and some customers had customized the form therefore not getting the changes.
A change was made to the UI to hide the options for excluding in an option tab that you need to click to open and view. Since this happened some customers have customized the form or may have already customized the form to show those values instead of seeing the options in the hidden section, therefore having the field twice on the form.
The problem here is that the values will always come from the last value it finds so if you unchecked the options on the main form it will take the values from the options as that is the last value for that field it finds.
To fix this you will need to update the form so the fields only appear once on the form over all sections. Once this is fixed it will not happen again.
Sometimes you are trying to add a data preserver for a specific table and you cannot find it in the list and wondering why?? This is most probably due to the scope of the table.
If you want to preserve a table that is part of a specific scope you need to do the following:
A change was made recently (Feb 2020) to avoid the issue described earlier in Clone Mapping.
The issue is when you request a clone over a demo instance, it fails with storage capacity checks as the source instance is too large to store all the information on the target instance. This is because Demo instances are not configured to expand their storage capacity past a set limit.
Due to certain circumstances, this change to not allow clones over demo instances has now been rolled back and cloning will run again as normal for cloning over demo instances, with the original issue of if the source is too large the clone will not work due to capacity reasons.