Saviynt unveils its cutting-edge Intelligence Suite products to revolutionize Identity Security!
Click HERE to see how Saviynt Intelligence is transforming the industry.
Saviynt Copilot Icon

ServiceNow Instance Clone - Best Practices?

BarCar
Regular Contributor
Regular Contributor

Has anybody worked out any best practices for a ServiceNow clone-back from production to a sub-production instance where the Saviynt App is installed and connected to the production Saviynt instance?

Are their jobs which should be disabled, or properties which should be cleared to stop the cloned ServiceNow instance connecting to the production Saviynt instance? 

Follow-up question... how do you get your newly cloned sub-production instance connected to your sub-production Savinyt instance? Is there a way to blow away the data in the app and start fresh?

Really would hope to see these standard ServiceNow operations covered in the app documentation.

5 REPLIES 5

saikanumuri
Saviynt Employee
Saviynt Employee

Hi Barry,

Thanks for reaching out. Can you please help me understand the use case?

If your intention is to perform some testing, I would recommend creating it as a fresh instance as the data will vary between prod and sub-prod and you may encounter errors while submitting the request in case there is a mismatch in data

BarCar
Regular Contributor
Regular Contributor

Hi. Thanks for replying.

Clone-back from production is a pretty standard ServiceNow operational task. You have, let's say a PROD instance and a DEV instance. You will clone the PROD instance to DEV to keep them in sync - we do this every few months. Starting from a fresh ServiceNow instance is not a viable option for operational systems and our release pipeline.

If you add Saviynt to the mix, we have a ServiceNow PROD instance connected to a Saviynt PROD instance and a ServiceNow DEV instance connected to a Saviynt DEV instance.

So when you clone ServiceNow PROD to ServiceNow DEV you would end up having 2 ServiceNow instances connected to a single Saviynt PROD instance. This would be a bad thing.

To mitigate this, I'm assuming that we need to take some actions in a ServiceNow post-clone cleanup script to disconnect the "new" ServiceNow DEV instance from the Saviynt PROD instance. That would take care of the immediate risk of DEV updates being made to PROD security systems.

And then you would need to  blow away the cloned (ex-PROD) Saviynt data in the ServiceNow DEV instance and reconnect it to Saviynt DEV.

So my question is:

  • What steps are required to safely perform a ServiceNow PROD to DEV clone when both instance are connected to DEV/PROD Savinyt Instances?
  • How do you blow away the ex-PROD Savinyt data in a cloned ServiceNow instance so that it can be reconfigured to connect to the DEV instance again?

Hope that helps clarify.

saikanumuri
Saviynt Employee
Saviynt Employee

Hi Barry,

Thanks for sharing those details.

My previous recommendation was to have a clean setup only for SnowApp by deleting the App after cloning the ServiceNow and performing a fresh install for SnowApp so that you won't end up having any prod data references.

BarCar
Regular Contributor
Regular Contributor

Hi @saikanumuri - thanks for reaching out and confirming that you meant that I should uninstall the Saviynt app in the cloned DEV ServiceNow instance and then reinstall it fresh.

I also wanted to share the System Clone - Cleanup Script which I have implemented in ServiceNow to avoid any risk of the cloned DEV instance connecting to the Saviynt PROD instance. The value of the Saviynt application scope will obviously differ depending on your instance.

 

// Disconnect cloned instance from Saviynt Production

// Clear Saviynt Properties to link ServiceNow to prod Savinyt instance		
gs.log('InstanceClone: Clearing Saviynt connection properties.', 'InstanceClone');
var sp = new GlideRecord('sys_properties');
sp.addQuery('sys_scope', 'c10a58bddb921850f4e89ec2ca9619e6');
sp.addQuery('name', 'IN', 'x_saviy_iga.bearer_token,x_saviy_iga.refresh_token,x_saviy_iga.app_username,x_saviy_iga.endpoint_url,');
sp.query();
while (sp.next()) {
    sp.setValue('value', '');
    sp.update();
}

// Disable Saviynt Scheduled Jobs in ServiceNow
gs.log('InstanceClone: disabling all Saviynt scheduled jobs.', 'InstanceClone');
var sj = new GlideRecord('sysauto');
sj.query('sys_scope', 'c10a58bddb921850f4e89ec2ca9619e6');
sj.addActiveQuery();
sj.setValue('active', false);
sj.updateMultiple();

 

 So the process I will be following is:

  1. Implement Clone Cleanup Script (as above) in production ServiceNow instance 
  2. Perform Clone from ServiceNow production to development
  3. Check Saviynt is disabled in cloned ServiceNow development instance
  4. Uninstall Saviynt App in cloned ServiceNow development instance
  5. Reinstall Saviynt App in cloned ServiceNow development instance
  6. Reconfigure new Saviynt App to connect to Saviynt development instance

BarCar
Regular Contributor
Regular Contributor

Hi @saikanumuri - do I need to worry about clearing the Saviynt ID (x_saviy_iga_saviynt_id) and Saviynt User Active (x_saviy_iga_saviynt_user_active) properties on the sys_user table before reconnecting Saviynt?

It looks like those properties were not removed/cleared when I uninstalled the application - so they still link to the PROD instance.

Thanks.