Post-Clone Checklist, anyone?

[sbailey1]

We're getting ready to refresh all of our instances from PROD in preparation for go-live. When we clone, we run through a checklist (which we're still trying to develop out) to tweak those things we know need to be tweaked. Mailbox password, user account lockout, color scheme (for visual platform indication), etc. Does anyone else have a checklist for post-clone cleanup we can use to match up against ours to make sure we've caught everything? I'll be glad to post our version as well, if others would find that useful.

[sbailey1]

Thanks, everyone! This has been a very useful dialog and I appreciate the wiki page, which should help the entire community. I'm uploading my version of the checklist, which isn't formatted as nicely as the others. It's got a couple of additional items, though, I thought worth sharing.

Pre-Cloning Checklist
1)Check for any pending update sets on target instance. Ensure that those are propagated through so they are not lost.
2)Check for attachments that must be preserved during the clone. Those will be lost in the target instance, unless specified in the request that they should be preserved.

Welcome page - in wiki article, it says to set the appropriate ones to active, but those need to be created first.

Data Cleanup (to prevent notifications from non-prod systems)
•DEV, STAGE, TRAIN
oDisable email sending (System Properties / Email) — uncheck Enable Email Sending
oClose Tasks:
View all Incidents and filter for those created prior to the clone. Update all to Set Status to Closed
View all Requests and filter for those created prior to the clone. Update all to Set Status to Closed
View all Changes and filter for those created prior to the clone. Update all to Set Status to Closed
oView Email Outbox (System Mailboxes / Outbox) and delete all pending emails
oRe-enable email sending (System Properties / Email) — uncheck Enable Email Sending

SSO Hash Key
4.1.8.SSO Hash Key
•In the left nav, under System Definition, click Installation Exits
•In the list, click DigestSingleSignOn
•Click the Active checkbox, then the Update button
•In the left nav, under System Properties, click Single Sign-on
•Click the "Enable external authentication" checkbox
•Enter the "Secret passphrase…" —in the demo it's 123abc.
•Click the Save button

Additionally, when we created our Production clone, we had to go in and clear out all of our test data. Although it may belong in a different thread, I've started a checklist for that as well.

When cleaning out system data from an instance, additional steps are required:
•Remove all Incidents EXCEPT 1. (If delete all, error on creating first.)
•Remove all Requests EXCEPT 1. (Not sure if that has the same issue, but being safe.)
•Remove all Changes.
•Remove all records from Task SLAs table
•Remove all kb_submissions
•Remove all Search Queries
•Remove all Ratings
•Remove all knowledge feedback
•Remove all knowledge articles
•Remove all metrics instances
•Remove all project tasks
•Remove all survey instances
•Remove all mail inbound and outbound
•Cancel and remove all workflow contexts
•Reset all numbers — Number Maintanance

Hope these help someone out there.
Stacey

[Rick Mann]

Hello Sbaily

I was reviewing your checklist (very good info!) and noticed the information under 4.1.1.3 regarding the Glide_email_test property.

GLIDE LIST GROUP: When enabled: Recipients of all outbound emails are verified before sending and only those that exist in a matching group called "glide_email_test" are sent

Is this a custom property that you created? Is this something you can share? Thank you.

Rick

[sbailey1]

Our incredible Service-now consultant, Bobby Edmonds, created this for us to prevent emails from going out to clients, executives, and other unsuspecting customers from non-production systems. It has been a life-saver for us and has saved us on numerous occasions.

. We have a group called glide_email_test where we identify users who may receive emails from the system.
We have a system property to enable or disable this safety net.

If an email is targeted to a user who is on the glide_test list, it goes through fine.
If an email is targeted to go to a user who is not on the glide_test list, it gets redirected to the user who triggered the email with a note at the bottom indicating the original intended recipient(s).

It sounds like this could be a very valuable enhancement in a future release.

[Jim Coyne]

@sbailey: I've been trying to figure something out for the same problem and this sounds like a really nice solution. Is it something that could be shared? 🙂 I'm assuming there is some Business Rule on the email table.

Thanks

[cdugas]

This is a great checklist. Have you managed to script it or automate it in any way?