7 Replies Latest reply on Jan 16, 2017 8:13 AM by dsears

    2016 Upgrade Questions

    mmajeres Apprentice

      Hello all, I'll probably end up opening a support ticket on this, but wanted to get community feedback as well.  We are preparing to do a side-by-side migration from LDMS 9.6 SP1 to 2016/10.0.  I really like the document at How to do an EPM (Formerly LDMS) Side by Side Migration Process (All Versions) for a high level plan, but still have a few concerns.

       

      Questions to be resolved

      Where do the packages live? We know the installation files for packages are in the file share, which can be copied from old server to new.  But does the package configuration, etc. live in the database (and would thus be migrated with that) or in some other Landesk file that is (or could be) migrated?

       

      Do we need a migration server (as suggested by this post: Re: Best practice for migrating data in a side-by-side upgrade) to move packages/queries/etc?

       

      If clients on a subnet are partially migrated can an old client act as a peer to a new client and vice-versa?

       

      Will the new core require an additional addresses and external IP(s) for the Cloud Services Appliance?

       

      What sorts of configuration (especially around patch) will migrate, and which will have to be recreated?

       

      I'd love to hear your thoughts, and would especially welcome comments of people who have already upgraded, if they've collected any lessons learned!

        • 1. Re: 2016 Upgrade Questions
          LANDeskWizrd SSMMVPGroup

          Where do the packages live? We know the installation files for packages are in the file share, which can be copied from old server to new.  But does the package configuration, etc. live in the database (and would thus be migrated with that) or in some other Landesk file that is (or could be) migrated? Packages live in the database but you can export\import them from the old core to the new core.

           

          Do we need a migration server (as suggested by this post: Re: Best practice for migrating data in a side-by-side upgrade) to move packages/queries/etc? You don't need a "migration server" though it may make the whole process much easier. In essence, the migration server is just another 9.6 SP1 server pointed to a copy of your original database. You would then run the upgrade on that server so that when it is done, you will have a 10.0 server with the exact same data as your original 9.6 SP1 server. Copy the original client cert to the new server and then you can push the new agent to them. I'm sure I may have missed some things but you get the idea.

           

          If clients on a subnet are partially migrated can an old client act as a peer to a new client and vice-versa? Clients can only be a peer if they are both on the same core server

           

          Will the new core require an additional addresses and external IP(s) for the Cloud Services Appliance? If I understand your question correctly, you do not need another CSA as a CSA can be utilized by multiple core servers.

           

          What sorts of configuration (especially around patch) will migrate, and which will have to be recreated? If you upgrade using a "migration server" everything is the same

          1 of 1 people found this helpful
          • 2. Re: 2016 Upgrade Questions
            mmajeres Apprentice

            Thanks, Wizard.  Just a couple of follow ups, so I know that I'm clearly understanding.

             

            Packages live in the database but you can export\import them from the old core to the new core.

            If I've migrated my database over, and the packages are there, why would I want/need to export/import them?  Can't I only export/import across the same version?

             

            If I understand your question correctly, you do not need another CSA as a CSA can be utilized by multiple core servers.

            I get that, I'm wondering if I need a different external address (and IP for that address) so that my migrated endpoint can talk to the new core, and my old clients can still talk to the old core while I'm migrating.  Does that make more sense?

            • 3. Re: 2016 Upgrade Questions
              LANDeskWizrd SSMMVPGroup

              Packages live in the database but you can export\import them from the old core to the new core.

              If I've migrated my database over, and the packages are there, why would I want/need to export/import them?  Can't I only export/import across the same version? Sorry for not being clear on that one. If you migrated the DB then you don't need to export\import. They would all be there. One thing you may need to do is change the actual path of each file within the package since the server may have a new name.

               

              If I understand your question correctly, you do not need another CSA as a CSA can be utilized by multiple core servers.

              I get that, I'm wondering if I need a different external address (and IP for that address) so that my migrated endpoint can talk to the new core, and my old clients can still talk to the old core while I'm migrating.  Does that make more sense? Yeah, it does. No need to use different external address. You just need to add the CSA to your new core and it will add it's certificate to the CSA. That's all that would be needed.

              • 4. Re: 2016 Upgrade Questions
                saeidans Apprentice

                core Sync.JPG I receive the error message shown in picture when I try to stablish core sync from 9.5 SP# core server to 2016.3 core server

                .

                any Idea?

                thanks

                • 5. Re: 2016 Upgrade Questions
                  Apprentice

                  You can't core sync if the cores aren't on the same version. Something i would recommend (we did it for Field Test).

                   

                  Build a Dev core that is running the version of your current core.

                  Upgrade the dev core to your new version.

                  Core sync from the dev core to your new core.

                  • 6. Re: 2016 Upgrade Questions
                    saeidans Apprentice

                    what I had in mind was to clone my 9.5 DB and then install LDMS2016.3 on diffrent server and upgrade the cloned DB during installation and then import the newlly upgraded DB to my Production LDMS 2016.3 Server.

                    • 7. Re: 2016 Upgrade Questions
                      Apprentice

                      If by import you mean to Core Sync to the new core, we are both saying the same thing with a different process of upgrading the current data. I would strongly recommend you use a new, clean, database for your new server. I would strongly caution pointing the new server at the upgraded database. One of the biggest benefits to doing side-by-side is that you can keep using clean databases. We have always done side-by-side due to us not being able to have LANDesk down for any period of time (short or long).