1 2 Previous Next 18 Replies Latest reply on Nov 5, 2019 1:58 PM by Nicolas Roome

    Copy entire Service Core to test server

    Steve Marth
      Share This:

      Hello all,

       

      I finally created our test server and would like to emulate exactly how our live server is right now.  The best way I figured out how to do it is to export each workspace individually from the live server and import them in the test server, then export the live SQL database server and import it into the test SQL database.

       

      I was just wondering if anyone knew an easier way/better implementation.  Maybe just copying one giant folder over?

       

      Thanks.

        • 1. Re: Copy entire Service Core to test server
          Nicolas Roome

          BMC has KB articles on how to move a FootPrints environment app and/or database from one server to the next. You'll want to use these instructions when going from prod to dev or test.

           

          Basically...

           

          1) Backup prod SQL db

          2) Restore db backup to dev SQL (likely have to run the alter user fpscdb001_XXX with login = fpscdb001_XXX if the db changed servers.. Run for each of the 4 SQL logins)

          3) Copy prod 'conf' and 'repository' folders to dev (keep dev's footprints-environment.properties file)

          4) Start Tomcat

          • 2. Re: Copy entire Service Core to test server
            Steve Marth

            Thanks, I found them, but the articles I found did not mention copying the conf and repository folders, thanks for the tip.

             

            In the process of doing it right now.

             

            Since you mentioned the repository folder, I noted during setup that the System Settings -> Server Configuration -> Path to the Repository default is: C:\Program Files\BMC Software\FootPrints Service Core/repository (noted last forward slash), I'm assuming this is a default path typo?  Has it been noted?

            1 of 1 people found this helpful
            • 3. Re: Copy entire Service Core to test server
              Steve Marth

              So, I am running into a bit of a problem.

               

              I installed and moved over the Service Core to a different server according to:

              http://support.numarasoftware.com/support/articles.asp?how=%20AND%20&mode=detail&kcriteria=7308&ID=7454

               

              I installed and moved over the database to a new server according to:

              http://support.numarasoftware.com/support/articles.asp?how=%20AND%20&mode=detail&kcriteria=7176&ID=7322

               

              I also took note of keeping the Devs footprints-environment file like Nick said.

               

              After all that, I can not connect to the website.  TomCat states: Resource not available.

               

              I believe this is an issue with Service Core connecting to the database.

               

              I made sure I used the encryption tool and copied the info into footprints-environment correctly and I made sure we are using the same naming conventions (i.e., fpscdb001).

               

              Things I have tried to resolve:

              Uninstalled Service Core and reinstalled, telling it to use an existing database.  I was able to log into the portal, but none of the tickets were showing up (I took note that, even though I informed it to use the existing database of fpscdb001, it created users fpscdb002_adm, etc.)

               

              I then tried copying over the entire folders of repository and conf from live, but then the error presented itself again.

               

              I tried keeping the devs repository and conf folders and just changing the footprints-environment, error presented again.

               

              I changed the users in the database back to fpscdb001_adm, etc, no success.

               

              At this point, as long as I keep the devs original install repository and conf folders, I can log into footprints, but I can not see any tickets.

               

              I think tomorrow I'm going to wipe everything and start fresh, just wondering if anyone has any ideas.

              • 4. Re: Copy entire Service Core to test server
                Steve Marth

                Log, in case anyone is interested:

                • 5. Re: Copy entire Service Core to test server
                  Nicolas Roome

                  Hi Steve, haven't looked at all the log files..

                   

                  One thing I noticed, I got confused on it too. The installer's option to use an existing database is NOT designed to actually use an existing FootPrints database. Merely to use an existing database shell to then use as a FootPrints database (ie: the only difference between the options is that the 'use existing database' is for where a SQL admin has already created a blank database, so that FootPrints installer can add tables to it.

                   

                  You cannot use the FootPrints installer to point to an existing FootPrints database. What you did there may have broken your database entirely (or if not, created new tables effectively "wiping" your old stuff). I had created an idea for this but it got rejected:

                   

                  Your best bet as you said is to wipe and restart.

                   

                  About to jump on to some much awaited supper at the moment, else I'd elaborate more, but if you need any quick help tomorrow, feel free to ping me.

                  • 6. Re: Copy entire Service Core to test server
                    Steve Marth

                    Well, that makes sense.  Thanks for the info, at least i know now I'm not going TOO crazy.

                     

                    Get Outlook for Android<https://aka.ms/ghei36>

                    • 7. Re: Copy entire Service Core to test server
                      Steve Marth

                      Alright, I'm back at it and wiped both test servers and started from the beginning, and I still can't access the TEST service desk.  Tomcat wont start /footprints/servicedesk.  I've attached the log.

                       

                      If your offer for IMing you is still available, I'll take it up.

                      • 8. Re: Copy entire Service Core to test server
                        Nicolas Roome

                        Hi Steve, not sure if you missed the start of your log since it seems to be missing the start... but I see a lot of 'The padding is not supported or not available.' The only time I've seen that is when I was trying to restore a FootPrints database against a FootPrints application of a different version. Have you verified (and triple verified) your database and app are on the same version?

                        • 9. Re: Copy entire Service Core to test server
                          Steve Marth

                          I'm connected finally, this is what I did:

                           

                          Nick - thanks for the info, during my triple check, I noted LIVE SQL to be v12.0.5203 and TEST SQL to be v12.0.2269.  I think we got mismatched because I made the clone of the server long ago, it must have updated, and I made the SQL backup a little bit ago.  So, I updated the TEST SQL to v12.0.5203, still no success.  I completely deleted the database and restored the database, along with re-encrypting passwords, still no success.  Since it was a high possibility of having something to do with logging onto SQL, and I was trying to change the passwords on the TEST SQL, I decided to change all the TEST SQL passwords to what we use on LIVE SQL and copied over LIVE FP footprints.environment file.  Now it works beautifully.

                           

                          So, I must not be understanding how to change the passwords or use the encryption tool, but I figure I can try that again some other time.

                           

                          Thanks for pointing me in the right direction.

                          • 10. Re: Copy entire Service Core to test server
                            Nicolas Roome

                            The SQL minor version shouldn't matter. The SQL version itself doesn't matter either except that you cannot take a database from a SQL server of a higher version and restore it to a lower version (ex: SQL 2014 to SQL 2012).

                             

                            Glad you finally got it working. Difficult to say what the issue was - especially this late at night. The more often you do these environment moves, the easier it'll get. I can typically back-up/restore a FootPrints environment in about 10-15 minutes.

                            • 11. Re: Copy entire Service Core to test server
                              Steve Marth

                              I didn't think the minor version would have mattered either, but I was trying everything.  It apparently didn't since it didn't resolve the issue.  It obviously had something to do with trying to come up with new passwords on the TEST environment. 

                               

                              Thanks for the help :-D

                              1 of 1 people found this helpful
                              • 12. Re: Copy entire Service Core to test server
                                Linda Kirkpatrick

                                I just went through a similar process with a customer seeking to create a DR environment.  The documentation leaves a lot to be desired.  Remember your support vendor might could help as well.  Good lucK!

                                1 of 1 people found this helpful
                                • 13. Re: Copy entire Service Core to test server
                                  Don Cholish

                                  Linda Kirkpatrick  If you can give us any feedback on what needs to be improved with the documentation, we will get it updated.

                                  • 14. Re: Copy entire Service Core to test server
                                    Jacque Donald

                                    I have used this document myself, assuming this is the one you guys are talking about (How to create a FootPrints 12 test server as a duplicate of a current production environment).

                                    What I have found is that if I am using the same SQL server to host the copied database, the scripts do not work when performing the following command;

                                    -- The four entries below clear the sid assuming the defaul usernames.  Change according to the customer's DB --

                                    exec sp_change_users_login Auto_Fix,fpscdb001_adm

                                    exec sp_change_users_login Auto_Fix,fpscdb001_sec

                                    exec sp_change_users_login Auto_Fix,fpscdb001_usr

                                    exec sp_change_users_login Auto_Fix,fpscdb001_rpt

                                     

                                    The issue I have found is that the installer will create all new accounts, such as fpscdb002_xxx for them if they already exist on the sql server.

                                    The guide states;

                                    If these Users do not match those created by the installation, use the SQL query below to create new SQL Logins to match those Users from the restored database.

                                    Running this command Create Loging fpscdb001_xxx etc. does not work as the user already exists on the same SQL server.

                                     

                                    The next step is to run the following script;

                                    -- The four entries below clear the sid assuming the defaul usernames.  Change according to the customer's DB --

                                    exec sp_change_users_login Auto_Fix,fpscdb001_adm

                                    exec sp_change_users_login Auto_Fix,fpscdb001_sec

                                    exec sp_change_users_login Auto_Fix,fpscdb001_usr

                                    exec sp_change_users_login Auto_Fix,fpscdb001_rpt

                                    Running this command does not produce any changes if you do it for the existing accounts or the new ones in the copy of the production database.

                                     

                                    The database copy will have the 001 accounts, and even if you rename them, the login name will remain the 001 account and when you install footprints 12, the accounts specified were 002 (or whatever iteration is next).

                                    The section also on modifying the file footprints-environment.properties also is unclear on what to modify (step 14).

                                    Next we need to manually edit the x:\Program Files\BMC Software\FootPrints Service Core\conf\footprints-environment.properties file to ensure the usernames and TenantID have been updated.

                                    I have attempted to modify this file to use the account names that the installer created (004 in my case), and neither one will work.

                                     

                                    I feel like the documentation is missing something or I am, as I am unable to get the system to load FootPrints to load in the browser. I have tried this twice using the document step by step but I feel like something is amiss when using the same sql box, between the original accounts owning the schemas in the copied database, and the environments file specifying the passwords of the newly created accounts.

                                    1 2 Previous Next