Ron, One side project I've worked on recently but haven't had time to finish is a refresh of testing data. For example, I set up some Migrator scripts to move Product Catalog data from Production to testing. It was kind of a pain because of all the different forms, but it may be an easier way to keep the data synchronized over time. Traditionally I've used the database refresh technique and just ran a SQL function to replace all instances of the server and mid tier server names with the new versions. That messes up Asset Management and the CMDB records for the specific Remedy servers, but that's not a huge deal for testing purposes.
Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Thursday, July 19, 2012 12:01 PM To: arslist@ARSLIST.ORG Subject: Non-production environment refresh. ** On a periodic basis, we want to make sure our non-production environments match production for valid testing. Over time they seem to drift apart. In any case, the various folks at BMC weren't able to give much of a procedure for making this happen. I know there are many differences in environments, but a reasonable starting place would have been nice. In any case, I've come up with a procedure that might be useful to some so I thought I share. I know I've received a lot of benefit from this list. We're on AR server 7.5 and this should probably be taken as a starting point and not necessarily a perfect process for your environment, but it worked for us. Also, the forms that I modified were from a list I did get from someone at BMC and it may or may not be exhaustive. Enjoy! On occasion we want to refresh the data within the non-production Remedy environments. This aligns all the data/configuration between environments. This is the process that we've developed. 1. Take a VMware snapshot of the database server in the environment to be refreshed. This is in the event things go wrong. 2. Disable the Email Engine service 3. Disable the AR server service 4. Disable the Server Intelligence Agent in the Central Configuration Manager for Business Objects. Done on the RKM box. 5. Have a DBA backup the following 6 pre-refreshed tables (for Business Objects) for later restoration. § dbo.CMS_Aliases6 § dbo.CMS_IdNumbers6 § dbo.CMS_InfoObjects6 § dbo.CMS_LOCKS6 § dbo.CMS_RELATIONS6 § dbo.CMS_VersionInfo 6. Have a DBA Restore current production Remedy database onto the destination DB server. 7. Have a DBA restore the 6 backed up tables from above on top of the newly restored database. This keeps the Business Objects environment working as it was before. Both BO and Remedy use the same database and have their tables intermixed. 8. Start the Server Intelligence Agent in the Central Configuration Manager for Business Objects. Done on the RKM box. § Good to validate that BO is working correctly and reports from the newly restored data. 9. Start the AR server service. 10. Log into the thick client for further modifications 11. Change the server in the records of the following forms: 1. AP:Rule Definition ([Description: NOTE] nothing changed for accounts payable - maybe revisit) 2. AR System Searches Preference (modified all records with new ar server) 3. AR System Server Group Operation Ranking (modified all records with new ar server) 4. AR System User Preference (Server = $NULL$) ([Description: NOTE] not changed) 5. BMC.CORE.CONFIG:BMC_FederatedDataInterface ([Description: NOTE] nothing to modify) 6. BMC.CORE.CONFIG:BMC_FederatedInterface (modified all records with new ar server) 7. CAI:AppRegistry<http://docswiki/doku.php?id=sa:appregistry> (modified all records with new ar server) 8. EIE:CommonDialog<http://docswiki/doku.php?id=sa:commondialog> (Help File Path) ([Description: NOTE] cant change host/internal instance) 9. KMS:Administration_Integration (modified all records with new ar server) 10. Report (modified all records with new ar server) 11. SRD:STAGE:MasterDataMappingList<http://docswiki/doku.php?id=sa:masterdatamappinglist> ([Description: NOTE] no records to modify) 12. SRM:ApplicationSettings<http://docswiki/doku.php?id=sa:applicationsettings> (SRM Application Settings) ([Description: NOTE] no form) 13. SHARE:Application_Properties (Help files web location to point to the correct Mid-Tier) ([Description: NOTE] modified all the appropriate entries - Help File Path) 14. SYS:Integration Management ([Description: NOTE] nothing to modify) 1. Remove any unsent mail from the Remedy mail queue. 2. Remove all support group members. Don't want to confuse people from non-prod environments. Seem to have to go back to the service desk group. May have something to do with fixed licenses. It'd be nice if you could remove more than one member at a time. 3. Remove all the distribution lists from support group notification configuration. More user confusion from non-prod environments. 4. Update the email box configurations per the table below. Passwords can be found in the password vault. 5. Possibly clean up the actual Exchange inbox if necessary (unlikely). This will only be the case if the environment has been down a while and can't catch up. 6. Update the license entries per the table below. 7. Check the alert ID for the pop-up messages. ID found in CTM:SYS:Access Permission Grps form. Modify the entry in the Procmail configuration if necessary. 8. Change the email address of the 'remedy email' faceless account (People record) to be appropriate for the environment. § This address MUST match the address of the sender of the incoming mail (per mailbox configuration). If they don't match, the returned error will be "missing ar system user information" 1. Change the email address of the 'cab user" faceless account (People record) to be appropriate for the environment. 2. Remove the distribution list from the service desk support group. Probably redundant from above. 3. Update the pager configuration to have the appropriate 'sender' email address for the specific environment. 4. Start the email engine service 5. Send a message to the environment service desk email to validate default tickets are being created correctly. 6. Send a message to Procmail to validate those tickets are being created correctly. 7. Clean up mail queue, remove all old production messages from the non-production environment. This will take quite a while and probably should be done overnight. _attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<inline: image001.png>>
