Cloning - and Update Sets Duplication

[Jason Stuart]

Good Morning,

        We have recently cloned an instance in ServiceNOW.  The Clone went fine.  We ran into something we did not expect - and this was Update Sets.  Here is the scenario. Our typical deployment goes from Dev -> Test -> Prod

We cloned Prod to Test

After the clone, I went in and created a new Remote Instance for my Update Source pointing it back to Dev.  So, Test -> Dev.  

I then did a retrieve update set, which behaved weird. It pulled back update sets, but seemed to duplicate those that already existed in DEV2 - and it did not do it for ALL OF THEM.  Why would there be duplicates?  The ones in test that had been duplicated were already completed.  It pulled them in as previewed.

Any reason why this would happen?

[Alberto Consonn]

Yes, you're right, this is another best practise to do for preventing duplication.

Please, remember to mark Correct or Helpful if you find my response useful.

Cheers
Alberto

[Nickels]

I have been having this issue as well and am wondering if I should setup either a Preserver Data entry for the update source and update sets or setup an Exclude Tables for each of the update sets? Does anyone have any recommendations for this? What are the best practices here? We are setting our update sets to Ignore after committing in Production.

We finished a sprint last Friday and I waited until Saturday to clone, this allowed the backups to run. Now we are pulling update sets into test and they are duplicated. 

Appreciate the advice!