Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 14 replies
  • Subscribers 1 subscriber
  • Views 5558 views
  • Users 0 members are here
Options
Suggested
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

Backup, Restore and Migrate Server Help

JKisner

For disaster recovery purposes, can anyone point me to the process for backing up and restoring the Endpoint Security and Control database server (version 4.0)?

Also, how would you go about migrating to a different server and still maintain connection with your endpoints and the database contents?

Thanks!

:959


This thread was automatically locked due to age.
  • 0

    Hello Patrick,

    which part does not work? Update Manager (aka SUM) usually refers to the successor of EM Library. The part on the client side is AutoUpdate. The certificate mentioned in this thread is used for the Remote Management System (RMS).

    So - what did you do besides installing a new server (same or different name?)? What doesn't work - could you describe the symptoms in detail, e.g. error messages?

    Christian

    :3113
  • 0

    Hi Christian,

    our current installation is: Sophos Enterprise Console 2.0.0.1447 with EM Library 1.3 (build 22). MSSQL is locally installed.

    We want to migrate to a new servers with a new IP and name. We will use a NEW database on a shared SQL cluster. On the new machine we use Enterprise Console 4.0.0.2362 with Update Manager 1.0.3.122

    We like to use the same certificate from the old server on the new machine. I've exported the certificate and imported it on the new machine. AFTER importing i've installed the sec_40_sfx.exe package. Installing the package on the new server with the shared database is no problem. But after installing the new Update Manager is not able to fetch the updates form the 'Sophos' host. I've also tried to use the 'http://es-latest.sophos.com/update' host.

    We get the following error: 80040401, 80040404 and 80040406.

    The new machine HAS an internet connection, i've tried with IE.

    Is there a relation between a certificate and the database? A newly installed servers with a new database and a new certificate WILL update. So maybe the certificate is not good here?

    regards,

    Patrick

    :3121
  • 0

    Hello Patrick,

    is it indeed SEC 2.0? Which SAV version do you use on the clients?

    So you don't intend to migrate the database, you just want the clients to be manageable by the new server without having to uninstall SAV on the clients - for this to work you need the certificate. But this certificate should not affect SUM.

    There is an article (66176) for 80040406, the other two codes are the general software update and threat detection update failed errors. Article 66176 only partially applies, as you have no SUM hierarchy, but you should give it a try. If deletion of the contents fails it could be that the indexing service has one or more files locked. Apart from the import of the registry keys and the database - what's the difference between the "planned" server and the "other" where it works?

    I assume you have only the "Recommended" subscription and only one or two products subscribed. You could take a look at the logs (SUMTrace2010...log), search for "failed" - it might give you a hint what goes wrong. But sometimes the exact reason is not immediately obvious. Then either post it here or call Sophos Support. In any case please keep us updated.

    Christian

    :3124
  • 0

    Hello Christian,

    it is indeed SEC 2.0 we're using. On our clients we use version 7.6.19. We don't intend migrating the database. But if that may be the problem when can try that ofcource.

    We don't want to uninstall SAV on our workstations (2500+). If we just redirect the SAV clients to the new server it WILL upgrade to new version. But the SAV client will not appear in the new Console. This has to do with the certificate.

    We've tried to install the Console several times, but without any luck. When we're doing another install we have a look at the logfiles.

    Regards,

    Patrick

    :3129