Dustin,
If I want to replicate a server I will typically just spend a day or two rebuilding a new environment and then do a database restore. When you do a database restore there are a handful of forms that have server references, you need to refresh the ARSystem database owner to ARAdmin for the new database, and then update ar.cfg with any of the AREA configurations you have. You can then use tools like rrrchive to sync the data. You can clone the system at the VM level and rename the box and the ips. I haven't played around with the rename tool yet, but it supposed to take care of all the references. I would imagine the intent of that tool is for moving a server from staging to production. Sometimes the time spent troubleshooting a missed variable change is longer than the couple of days it would take to do a new system build and database restore. Just my two cents. The challenge with moving and building systems is it is not something people typically do all the time, so inevitably you miss a bunch of steps. I would recommend if you want to get more experience doing moves and system builds you document the steps and test them a bunch of times on a dev box over and over again. I have done countless builds over the years and I still following build documents step by step. It helps take the thought process out and ensures the systems are built the same way every time. Good luck, Brian ________________________________ From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Fawver, Dustin <faw...@mail.etsu.edu> Sent: Monday, February 20, 2017 8:26 PM To: arslist@ARSLIST.ORG Subject: Re: ARS 9.1.02 Dev to Prod Clone ** Brian, I rebooted the server after modifying the ar.cfg file. I am currently not using server groups. I went through the instructions that Dmitry pointed me to. It found a few things that I had missed. I had it update the database, the files and the registry as per the documentation. For some reason, it ended up deleting the registry keys that defined the AR service and the Email Engine service. I fixed that by simply exporting from the dev server, editing the server names, and then importing into the upcoming production server. I ended up finding out that the crux of the problem was that mid-tier on the production server was still configured to work with the dev AR server. Once I added in the production server to its configuration and set it to be the default AR server, things started working as I would have expected. I have now (trial) licensed the server and I'm using rrrChive to migrate data over from the current production server to the new one. I'll be allowing selected users to perform their own testing. I hope this helps someone else who may run into this. Either that or it was just my lack of experience. I had been reading the discussion from a little bit ago where folks were comparing tools for migration and such. I read where people would do database restores from prod to dev. When things didn't turn out quite so easy for me, I was wondering what I was doing wrong. Thanks to everyone for their input! Dustin Fawver Sr. Help Desk Technician Information Technology Services P: 423-439-4648 faw...@etsu.edu<mailto:faw...@etsu.edu> ________________________________ From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Brian Pancia <panc...@finityit.com> Sent: Monday, February 20, 2017 7:20 PM To: arslist@ARSLIST.ORG Subject: Re: ARS 9.1.02 Dev to Prod Clone ** This may be a silly question. When you modified the ar.cfg file did you restart the BMC services immediately after or did you login to the Admin Console first? Are you using server groups? Brian From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Fawver, Dustin Sent: Friday, February 17, 2017 6:48 PM To: arslist@ARSLIST.ORG Subject: ARS 9.1.02 Dev to Prod Clone ** Greetings! So I'm pushing to try to meet a deadline to get ARS 9.1.02 live in our production environment. I have a development environment set up the way I'd like it, at least for launch. I wanted to avoid having to figure out again how to properly configure AREA LDAP, SSL, redirections and such. Hoping to shave some time on things, here's what I did, thinking it would work. - Had my sysadmin clone the dev VM and database. Database was backed up from the dev SQL server and restored onto the prod SQL server. Due to naming conventions in place here, the names of the databases are different. - The new prod VM was renamed accordingly and placed onto the domain. - Edited the ar.cfg file on the prod VM to make it point to the production SQL server with the correct DB name, DB username and password in plain text. - When logging into the prod VM and going into the AR System Administration: Console, I look at the Database tab and it has values for the development server. I had SQL Server Management Studio export the data into SQL files. I searched for the name of the dev server in the SQL files and updated the values accordingly on the production DB server. This took me a little while to do. - I started the ARS service back up and it still points to the dev database. I can log into both system separately, but any changes that I make to the config on one is reflected on the other. - I attempted an "upgrade" to ARS 9.1.02. It was successful. The installation program even had the values for the production database server as its defaults. Unfortunately it still seems to want to access the development database server. Do any of you think that this is salvageable and that I'm just overlooking something? Some of the things that I was able to get running on the development server have been set for so long that it may take me a little bit to get things back to running. Thanks! Dustin Fawver Sr. Help Desk Technician Information Technology Services P: 423-439-4648 faw...@etsu.edu<mailto:faw...@etsu.edu> _ARSlist: "Where the Answers Are" and have been for 20 years_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
