1 Reply Latest reply on Sep 29, 2016 6:26 AM by cwinning

    Upgrade guidence requested

    mmajeres Rookie

      I'm planning an upgrade from 9.0  to 9.2 (Update 3).  While I'm upgrading, I'd also like to migrate from the current server running Server 2003 to a new vm running Server 2012 R2. I'd appreciate any guidance on how I can improve my plan.

       

      I think I want to upgrade my current install on 2003 to 9.1 to get the migration tools (and I can't put 9.2 on a 2003 server), then migrate to the new 2012 server, and then upgrade to the latest version.  Does that make the most sense?  Any gotchas I need to watch out for?  Anything in my plan that won't work, or is missing?  Is there a better plan?

       

      I understand that I have to accomplish at least the first upgrade in the next 3 weeks before 9.0 goes EOL; hopefully I'm close!

        • 1. Re: Upgrade guidence requested
          cwinning CommunityTeam

          Hello,

           

          Protect 9.0 was the last version that could be installed on a 32bit  system.  I would suggest migrating your current Protect 9.0 console to Server 2012 R2 then upgrade directly to version 9.2 using the latest Protect 9.2 installer: http://www.shavlik.com/support/protect/downloads/

           

           

          • Some database maintenance will help the migration and the upgrade to Protect 9.2:

           

          First, you'll need to decide how many old records to keep. A good range is 60-90 days worth, however, you may want to reduce that if your console was used to scan several times a day.

          To remove the older records, go to Manage > Items, and locate the cutoff time for the records to keep.

           

                    Screenshot_103.png

          • Due to the number of operations being run against the database during this process, it is usually beneficial to increase the database timeout period for Protect. Instructions on how to do this can be found here: How To Increase The Database Timeout Period For Protect
          • Warning! Deleting too many records at once may overload the database, especially when running SQL Express. If you have a large number of records, delete them in batches.
          • Warning! Deleting records creates SQL logs, which use up disk space. If you're running low on disk space, you may need to free up some space. If you are using SQL Express, you may need to Shrink the database after each delete operation if you're close to the 10GB limit

                    Screenshot_104.pngScreenshot_105.png

          To select multiple records, you can select the first, then hold shift and select the last, and everything in between will be selected. You can also remove Power Status results and ITScripts results, and it is recommended you do so unless you have a specific need for those records.

          While deleting scan records will delete the associated deployment records, it's still a good idea to check the deployment records to ensure there aren't any very old records that failed to delete

           

          Once you've cleared out those records, it is a good idea to re index the database. To do this, go to Tools > Operations > Database Maintenance, uncheck all boxes except for "Rebuild Indexes", and click "Run Now", then "Run Maintenance Tasks Now".

          This process takes time depending on the size of your database. You can track this through View > Event History > Database Maintenance.

          Screenshot_106.png

          Screenshot_107.png

           

          And of course our support team is on standby if you run into issues.

           

          Thanks,

          Charles

          1 of 1 people found this helpful