We refresh our DEV and TEST environment frequently. We want our Test environment most like production to reduce issues, come time moving DEV customizations over it makes it more thorough. If they fail in TEST they will fail in production, or at least you can get your steps noted and mastered for the import to production. Here are the steps I take.
Steps prior to a DB refresh 1: Export the Licenses to a file. 2: Note Email mailbox configurations and settings. (server user and password, etc) Steps after a DB refresh 1: Copy Production REMEDY DB to Server B on correct port (our Oracle DBA does this step) 2: Restart AR Service 3: Reimport the correct ARSYSTEM.LIC file from Backup License file done in Steps prior to a DB refresh. 4: Change the Server Name information on forms CAI Application Registry, CMS Configuration Management 5: Change AR system Email Mailbox Configuration ? Change the incoming configuration server user to correct Test or DEV mail user and password. Double check the Outgoing mailbox address to make sure it reflects the TEST email instead of PROD. 6: SYS:Attachments form ? Change the Survey Link to show correct server names. 7: AP:Notifications - Check any custom notifications with Server links.. 8: EIE:Applications Settings form 9: Restart all Services that are automatic. Don't forget Midtier 10: Log into the Midtier Configuration console and Flush Cache. Hopefully this helps. JK Pat Zandi <remedy...@gmail.com> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 03/06/2010 07:36 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Refreshing the DB for ITSM 7.1.0 ** Good thing ur not using srm the only way we have found to move stuff is db level. Migrator and def files do not work. Pain pain pain Sent from my iPhone On Mar 6, 2010, at 1:49 AM, Joe D'Souza <jdso...@shyle.net> wrote: ** I meant it always helps (and not never helps) in my last significant paragraph in my previous mail...... Friday night.. that's my excuse.. Joe -----Original Message----- From: Joe D'Souza [mailto:jdso...@shyle.net] Sent: Saturday, March 06, 2010 1:43 AM To: ARS Discussion List Subject: RE: Refreshing the DB for ITSM 7.1.0 Shyam, There is no real formal list to such forms if you ask me. It really depends on what you got installed. I wish every application really did have that kind of a list *you would think that this should have been a part of admin documentation* but welcome to the real world. The real world is that there are some obvious areas you should be looking at, in terms of form data such as AIE configuration SRM configuration, etc. The rest is like fire fighting. Fire fighters do not get a documented list of steps you should be performing to complete their rescue operation. Its just enough to expect problems for a while - you can only hope that the precautions you have taken based on your knowledge and that of what others had to share so far have minimized the occurrences of those problems.. A similar thread this month listed some data forms.. That should be a good beginning point to reduce these problems by about 75 to 80%. Maybe 100.. But it never helps to screen definitions by taking def files and looking for hard coded server references even while you nail things down on application /configuration data. In my experience XML exports are ideal for this, as you can replace server references found with @ directly without really having to account for the string length. In fact I rely solely on XML exports ever since I realized with one of the team I have worked with in the past, that it is a really safe and ideal way of doing so.. Hope this helps Cheers Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Shyam Attavar Sent: Friday, March 05, 2010 9:40 PM To: arslist@ARSLIST.ORG Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Chris, I would still be interested to know the LONG list of places to update that you refer to in your response. Would it be possible to share that information? Thanks, -- Shyam From: strauss <stra...@unt.edu> To: arslist@ARSLIST.ORG Sent: Fri, March 5, 2010 12:17:11 PM Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Customizations to the app are best moved with Migrator. You can build a fresh test server, migrate the customizations to it from development or production, then apply a patch or run an upgrade to see how it affects those customizations. Then later you can apply the same patch (or upgrade, but good luck with that) to development or production and then migrate the customizations back over from test. Typically I refresh development from production by restoring the db from a backup of production. Then there is a LONG list of places you have to update the clone on development to remove server and mid-tier references to the production environment (and remove notifications that are waiting to go out). Next you can apply a patch, then re-migrate customizations from production. Once you document everything that you have to do to restore customizations after patching, you can patch production and migrate the customizations back from development. That is essentially how we got from ITSM 7.0.03.007 to 009. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Shyam Attavar Sent: Friday, March 05, 2010 2:00 PM To: arslist@ARSLIST.ORG Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Thanks for the suggestion Saby, But I am looking for a way to move customizations only and not the data. Thanks to Joe D'Souza for his suggestion and I will most likely be using that for our needs. Regards, -- Shyam From: Sabyson Fernandes <sebyr...@yahoo.com> To: arslist@ARSLIST.ORG Sent: Fri, March 5, 2010 6:08:39 AM Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Hi Shyam, Have you looked into rrrChive? Its a great utility for copying over data from one server to another. I use it currently for copying data from a production server to a archive server and will shortly be using it to copy production data to our UAT environment so that users can test enhancements/fixes with production data. Regards, Saby From: Shyam Attavar <atta...@sbcglobal.net> To: arslist@ARSLIST.ORG Sent: Thu, March 4, 2010 4:59:45 PM Subject: Refreshing the DB for ITSM 7.1.0 ** Dear Listers, I have a need to refresh the production database back onto a test environment we are building. Since there have been quite a few customizations, we would like to get to a point where we can start leveraging the Test environment without having to individually migrate the customizations over. If refreshing the DB from production environment is considered risky due to the various notifications, escalations and approvals that might be pending, we can even refresh from our development server. Here's the environment: ITSM 7.1.0 (except SRM) ARS 7.1.0 Patch 6 running in a server group with four nodes on RHEL Oracle 10gR3 RAC running on RHEL Has anyone attempted something like this and has been comfortable with the refresh process. I have done this in the past on ITSM 6.x running on Oracle. I do realize exporting the ARADMIN schema from one instance and importing into another instance would get me started. However, I am more concerned with the data driven nature of ITSM 7.1.0 and there is more to the refresh process than meets the eye. I have never attempted this on ITSM 7.1.0 - hence my concern and posting to the list. Any words of advice, things "to do", things "not to do", things to "watch out for", or not do this at all. Any feedback is welcome. Thanks in advance, -- Shyam _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ ************************************************************* This e-mail message, including any attachments, is for the sole use of the addressee(s) to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Dunkin' Brands Inc. makes no warranty that this e-mail is error or virus free. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
