This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Enterprise console upgrade from v2.0

Hi folks,

I've been asked to help out a fellow college, who are running console 2, EM Library 1.3, endpoints on 7.6.

They have a new server available, running 2003, and want their console upgraded and moved to this.

My question is, is it worth it to plough through all the required upgrades, followed by a server transfer?  Or could I just install console 4 or 4.5 on the new server, turn off the console on the old server (still required as a DC) and try to find and protect the clients on the network?  Just trying to save some time and possible headaches....

Thanks

:5270


This thread was automatically locked due to age.
  • Hi,

    I would suggest starting from scratch on the new server: the amount of useful data you would preserve doesn't seem worth the multiple upgrades and a migration.  With the new updating mechanism being SUM, rather than EMLibrary, I would start afresh with that in mind.

    You might like to take a backup of the current database, just incase you ever needed to query any historical data.  You could even run a few reports now and save them as required.

    The bigger question is if you don't mind re-protecting the clients is order to get them pointing at the new server with the right certificates.  If you can, I'd recommend that as it's less prone to error. The only problem is, the machines are required to be on when using SEC to deploy: It sounds obvious but can you wait until the clients "appear"?  Are all the machines you need to protect always on or is this approach going to take a while?  

    You can always configure an AD start-up script to run setup.exe from the new distribution point maybe based on some condition; you might even be able to use a WMI filter to only run it on the machines with the old version only?  I've not looked into this exactly but a script which queries the current major version of SAV from Windows Installer could be another solution to save a re-protection loop, at least until you've managed to re-protect all of the machines.

    The alternative, is to use the technique in:
    http://www.sophos.com/sophos/docs/eng/ugguides/sesc_95_mgeng.pdf

    this relies on the currently installed AutoUpdate on the machines pulling down a custom mrinit.conf from their current CIDs to point the clients at the new server.  In order to do this, you need to Export the certificate of the current SEC2 server (see guide) and import it on the new server before installing SEC 4.5, this way, the clients will be able to communicate with the new server when they are redirected without being rejected with an unknown CA error in the logs.

    From experience I would only recommend this redirection approach if you have many clients which are rarely on and are unable to use a method like a start-up script or use some other management tool that is able to execute a task.  This approach is worth while if the only management of the machines is via Sophos itself and if the delta download would be low. As you're moving from SAV 7.6 to, I presume SAV 9.5, the saving in bandwidth for redirecting rather than re-protecting will not be felt and another reason why I would suggest re-protecting if you can and it is practical to do so.

    I hope this offers some guidance.

    Good luck,

    Jak

    :5274
    • The bigger question is if you don't mind re-protecting the clients is order to get them pointing at the new server with the right certificates.  If you can, I'd recommend that as it's less prone to error. ... You can always configure an AD start-up script to run setup.exe from the new distribution point maybe based on some condition

      Personally I wouldn't say that it's less prone to error but that's because we have administrative rights on about 15% of our (potential) clients and in turn only a small fraction of "our" machines is in AD and we rarely use the AD techniques. I've always used the mrinit.conf approach (basically you can either point the machines to the new server which then provides them with the new updating policies or assign new policies from the old server to direct them to the new CIDs) - once I had to "reincarnate" a server using also a DNS alias. It probably depends on the available tools and expertise.

      But no - I'm not disagreeing with you, Jak :smileywink: 

      Christian

      :5281
      • Thanks for your help Jak and Christian, much appreciated.

        :5283