6 Replies Latest reply on Apr 19, 2011 4:25 AM by peter.mannion

    Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?

      An obvious question in itself.  But, moving ePO 4.0 on win2K to ePO 4.5 on win2K3 and replicating host (all virtual), so removing most issues.

       

      So, 100% correct route is:

      1. Backup/export all existing config of ePO 4.0 on win2K.
      2. Power down existing win2K serving ePO 4.0.
      3. Bring up win2k3, install ePO 4.0 restoring config as per "KB51438".
      4. Do an in-place upgrade to ePO 4.5.

       

      But, what would happen if someone did the following:

      1. Backup/export all existing config of ePO 4.0 on win2K.
      2. Power down existing win2K serving ePO 4.0.
      3. Bring up win2k3, install ePO 4.5 restoring previous config.
      4. Restore relevant key's previously exported from ePO 4.0 install, overwriting new/existing key's in ePO 4.5 install.

       

      Granted, not the recommended route - yet all appears 'okay'?

       

      1. Leave as-is, it is working after all?
      2. Go back to step one and do as correct route outlines?
        • 1. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?
          JoeBidgood

          Unfortunately this will fail at step 3 - you can't restore an ePO 4 config to a 4.5 server. (It must be done to exactly the same environment that it was taken from.)

           

          HTH -

           

          Joe

          1 of 1 people found this helpful
          • 2. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?

            Hi Joe,

            But, what if when I said "Bring up win2k3, install ePO 4.5 restoring previous config." that this merely translated to:

            1. Relevant Software Packages Checked In
            2. Relevant Extensions installed
            3. Old ePO Policies Imported
            4. Systems Tree Rebuilt to exact same folder structure

            ?

             

            You see the things is, that what did occur was as follows:

            1. Backup/export all existing config of ePO 4.0 on win2K.
            2. Power down existing win2K serving ePO 4.0.
            3. Bring up win2k3, install ePO 4.5 restoring previous config (just recreating structure and restoring policies et cetera).

            All fine, but no agents registering in new ePO 4.5 install.

             

            So, I brought up the old server and exported the key's, then imported them into the new server.  Hey-presto, all the agents now calling home fine.  Now, we are missing the DR's et cetera, but these can be added back in again.

             

            Am I missing something else obvious?  Or might this just work (though messily)?

            • 3. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?
              rackroyd

              You may well have problems down the line as a consequence step 3.

              Restoring policies from ePO 4.0 to an ePO 4.5 server is going across some major schema version changes that could generate unpredictable results to the applied policies.

               

              As Joe suggests, you should bring the new server on at the same version and patch level as the old server, migrate the data and then make the upgrade of the new server to ePO 4.5 so the installer can migrate all the settings automatically.

               

              It's really not a good idea to try and cut corners on this i'm afraid.

               

              Rgds,

               

              Rob.

              1 of 1 people found this helpful
              • 4. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?

                Joe, Rob - my thanks.

                 

                I'm in agreement, if I were looking at a long-term implementation.  I'll elaborate.....

                 

                The scenario outlined is only to be a 'temporary' solution to bring the ePO install up to ePO 4.5 on win2k3 (from ePO4.0 on win2k), in order to allow the organisational site be redirected to a parent ePO 4.5 master server (new organisational architecture).  Then, relegating the local organisational site's ePO server to merely being an agent handler (AH server currently sitting in readiness).

                 

                As the new target architecture was/will be making the existing policies (repositories, exclusions - everything really) etc cetera redundant, it was felt that inconsistincies in the schema's causing potential policy issues were unimportant - as they would be blown away anyway?.  The new build of ePO 4.5 on win2k3 was/is only to act as an intermediary step, to migrating all nodes to a new parent/master server on a higher tier in a new organisational model.

                 

                Again, and as usual from you folks, thanks for the clarity.  Much appreciated.

                • 5. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?
                  JoeBidgood

                  My worry here is that you could wind up unable to perform certain functions in a hurry. Purely as a hypothetical example, imagine a scenario where you have an infection and are sent an extra dat, and you configure an emergency update task to update dats, engines and extra dats - but because of a mismatch between the two environments the "apply extra dat" switch never makes it to the client machines. Obviously this is a hypothetical worst-case scenario, but you get my point, I'm sure.

                   

                  The risk, I believe, is really quite small - but crucially it's non-zero. If it's only temporary, and you're prepared to live with the risk, then I think you'll be OK. You'd have to be pretty unlucky.

                   

                  I still don't like it though

                   

                  Regards -

                   

                  Joe

                  1 of 1 people found this helpful
                  • 6. Re: Migrate ePO 4.0 on win2k, to ePO 4.5 on win2k3?

                    I know, I know.......

                     

                    And obviously you're 100% right.  But, time and resource constraints dictate the risk.

                     

                    Besides, I can alway's do a panic rebuild from scratch if needs be:-)

                     

                    Thanks again folks.