Cloning Strategy

[Richard101]

We have been using ServiceNow for about 2 months now, and ran into a few hiccups with cloning. The first was around users. We created a bunch of invalid references in our testing environments since we excluded user data from our initial clones. We fixed this by now bringing down all users, roles, groups and the three membership tables. We initially had the users excluded since we wanted to keep the access we had in the testing instances. So, my questions around this are:

• What is your strategy around user access?
• Do you have connections to non-prod versions of your HR system and AD to import test users and create/assign groups?
• Is there anything around users that you would exclude, preserve, or script in a cleanup script?

The second issue we just ran into was the loss of activity on our SDLC module. This is something we had in test, but not active in our production instance. When we cloned down, we've seem to have lost all of the activities on defects and enhancements except the most recent.

• How could we have avoided this situation?
• Are there other tables like the Activities table with which we should take special care?

Finally, are there any other suggestions you have around cloning that aren't in the wiki or do you have any favorite ServiceNow-endorsed suggestions?

We just did our first upgrade, so we are learning lots very fast! I look forward to learning from veteran developers/administrators.

[geoffcox]

We have a scheduled job that tests to see if the instance was freshly cloned and if so, performs the following:

1. Sets some style info to color code the instance according to whether it's QA, DEV, TRAINING, or SANDBOX. (Some of this is redundant since you can now preserve style when cloning).

2. Sets the test email address so that all outgoing email goes to one place and enables email.

3. Set the banner text at the top of the screen to indicate the instance.

4. Set the mobile banner text to indicate the instance.

5. Set various system properties that include the instance name.

[Jesper Slot]

I know this is an old post but it has a lot of views, so might still be relevant. I just want to bring up the Data Preservations: Data preservation on cloning target instances (servicenow.com)

We use data preservations for a number of stuff:

- Test users on our test instance. We do not want test users in production, but do also not want to create them again after every clone. Test users also have roles and groups, which needs to be preserved as well.

- Scheduled imports. We have scheduled imports and some of them deletes the source file after import. In that case we don't want the test instance to grab the file before production, so we either deactivated the scheduled import on test or changed the source to a test source... and then preserve it.

- Scheduled exports. We do not want the test instance to export stuff that's being used by other systems. So again we've either deactivated them or changed the destination and preserved it. 

- Stuff that uses the MID server as a reference and MID server details is also getting preserved so that we do not have to set this up again after a clone. 

- We also have colored the dev, test, sandbox like geoffcox mentions, but are preserving it.

Apart from that, then I just want to repeat HugoFirsts comment about workflow contexts not being cloned down. So always use newly created requests for tests. This also leads me to the attachments.. attachments are typically not cloned down, so your knowledge articles with pictures, incidents with attachments in production etc., could look different in your target instance.

There's also a timing for when the clone should run, which can depend on when the last backup of production was taken... If you have a tight upgrade schedule it is worth to know that the clone uses last created backup of production, when you clone down from production to other instances. Make sure all your changes are in production before the backup runs, so it becomes a part of the last backup - so that you do not lose development when for example cloning down to dev.
On the NOW support portal you can see when the last backups for your production instance were made. And I would assume (and it also looks like it) the backups are created on a schedule. So from viewing timestamps of the last backups, you can get an idea about when they run, so you can set a deadline for when your last deployments should be in production, prior to a clone. And you can always doublecheck if the backup has run, to be sure everything is included.

[Kim Simonsen]

HugoFirst, is right. Make sure to clone all user access tables (User, Role and User Has Role) and keep all audit data. This ensures you have a complete journal in all tables and forms. You're process-data will be intact, so to speak.
BUT; When doing so, make sure to maintain a post clone script that runs on target instance post clone, that diables all non-admin users, to prevent access to all users. Users on sub-prod instance should only be allowed access during test-efforts.