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

Server to Server Migration

For a variety of reasons, we want to migrate our Sophs console install (management console, server and database) to another server and rebuild the original server as a console only.


I've found the "Server to Server Migration Guide for 5.0" and it seems fairly straight forward, but I do have a few questions.

Can we use the old install packages created on the old server, just copy them to a new location?

Do we have to recreate teh permissions groups we have?

Is there anyway to move the database off of the local SQL install to our SQL Server?

:23201


This thread was automatically locked due to age.
Parents
  • HI,

    What do you mean by "old install packages"?  Are these client installers packaged up?  If so, I would think the Remote Management Conponent (RMS) is configured to point at the "old" SEC server.  Most likely by IP address first (if the old SEC server had a static IP ), then FQDN and then NetBIOS.  Therefore machines protected from these packages would be pointing at the wrong location (old SEC Server).  Mrinit.conf in those packages would reveal all and I would probably re-create the installers rather than trying DNS tricks.

    I would maybe suggest moving the database after the migration to the new server (as the migration guide only really covers the "all on one machine" scenario so that that should make things easier).  I wouldn't try and combine the two steps in one thought.

    As for groups, it depends if they are domain or local groups.  I would image you are in a domain and the old SEC server and new SEC server are just member servers?  As is your SQL server?

    For moving the SQL role after the migration, I assume you have domain and you have a domain "Database" account?

    The "Database" account is that mentioned under here:
    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\DatabaseUser  

    After the migration, on your new management server there will be a local "Sophos DB Admins" group of which the "database" account is a member. Therefore to move the database I would:

    1. Run the SEC installer on the new SQL server and choose just the database component.
    2. Choose the "database" domain account (mentioned earlier) to give this access to the database.  This way when the installer creates the local "Sophos DB Admins" group on the new SQL server it will add this database account to it.

    So after running the installer on the SQL Server you will have:

    Two sophos databases in the instance (SOPHOS50 and SOPHOSPATCH).  A local group called "Sophos DB Admins" of which the "database" account the management service will use as a member.  

    Then at the management server:
    1. Stop the Sophos Management Service and Patch Services (To prevent updates to the databases).
    2. Run:
    C:\sec_50\ServerInstaller\DB\Core \backupdb.bat C:\windows\temp\SOPHOS50.BAK .\sophos SOPHOS50
    C:\sec_50\ServerInstaller\DB\Core \backupdb.bat C:\windows\temp\SOPHOSPATCH.BAK .\sophos SOPHOSPATCH

    This will create you 2 backup files, one for each database in \windows\temp\.

    3. At the new server copy the 2 backup files (SOPHOS50.BAK and SOPHOSPATCH.bak) to \Windows\Temp\ and run:

    C:\sec_50\ServerInstaller\DB\Core \restoredb.bat C:\windows\temp\SOPHOS50.BAK .\sophos SOPHOS50
    C:\sec_50\ServerInstaller\DB\Core \restoredb.bat C:\windows\temp\SOPHOSPATCH.BAK .\sophos SOPHOSPATCH

    In both of these cases I've assume the SQL instance to be called SOPHOS.  I assume the instance on the new server is not SOPHOS so adjust ".\sophos" as required.

    Now you have the databases restored you need to re-map the SQL login to the Windows Group:
    http://www.sophos.com/sophos/docs/eng/migration/sec_50_mgeng.pdf
    Section 10, part 6 has a script to run to do this.

    Once done. You need to point the management server at the new SQL location.  To do this, on the management server run:
     C:\sec_50\ServerInstaller \setup.exe

    This will start a modify where you can choose the new SQL server.  This will in essence update the registry keys which hold the connection strings.


    The local SQL instance on the management service should then probably be stopped and even uninstalled when you're happy it's all working.  I'd probably just disable the SQL service just incase I needed to move the databases back to a local instance.

    Hope this helps.

    Regards,

    Jak

    :23207
Reply
  • HI,

    What do you mean by "old install packages"?  Are these client installers packaged up?  If so, I would think the Remote Management Conponent (RMS) is configured to point at the "old" SEC server.  Most likely by IP address first (if the old SEC server had a static IP ), then FQDN and then NetBIOS.  Therefore machines protected from these packages would be pointing at the wrong location (old SEC Server).  Mrinit.conf in those packages would reveal all and I would probably re-create the installers rather than trying DNS tricks.

    I would maybe suggest moving the database after the migration to the new server (as the migration guide only really covers the "all on one machine" scenario so that that should make things easier).  I wouldn't try and combine the two steps in one thought.

    As for groups, it depends if they are domain or local groups.  I would image you are in a domain and the old SEC server and new SEC server are just member servers?  As is your SQL server?

    For moving the SQL role after the migration, I assume you have domain and you have a domain "Database" account?

    The "Database" account is that mentioned under here:
    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\DatabaseUser  

    After the migration, on your new management server there will be a local "Sophos DB Admins" group of which the "database" account is a member. Therefore to move the database I would:

    1. Run the SEC installer on the new SQL server and choose just the database component.
    2. Choose the "database" domain account (mentioned earlier) to give this access to the database.  This way when the installer creates the local "Sophos DB Admins" group on the new SQL server it will add this database account to it.

    So after running the installer on the SQL Server you will have:

    Two sophos databases in the instance (SOPHOS50 and SOPHOSPATCH).  A local group called "Sophos DB Admins" of which the "database" account the management service will use as a member.  

    Then at the management server:
    1. Stop the Sophos Management Service and Patch Services (To prevent updates to the databases).
    2. Run:
    C:\sec_50\ServerInstaller\DB\Core \backupdb.bat C:\windows\temp\SOPHOS50.BAK .\sophos SOPHOS50
    C:\sec_50\ServerInstaller\DB\Core \backupdb.bat C:\windows\temp\SOPHOSPATCH.BAK .\sophos SOPHOSPATCH

    This will create you 2 backup files, one for each database in \windows\temp\.

    3. At the new server copy the 2 backup files (SOPHOS50.BAK and SOPHOSPATCH.bak) to \Windows\Temp\ and run:

    C:\sec_50\ServerInstaller\DB\Core \restoredb.bat C:\windows\temp\SOPHOS50.BAK .\sophos SOPHOS50
    C:\sec_50\ServerInstaller\DB\Core \restoredb.bat C:\windows\temp\SOPHOSPATCH.BAK .\sophos SOPHOSPATCH

    In both of these cases I've assume the SQL instance to be called SOPHOS.  I assume the instance on the new server is not SOPHOS so adjust ".\sophos" as required.

    Now you have the databases restored you need to re-map the SQL login to the Windows Group:
    http://www.sophos.com/sophos/docs/eng/migration/sec_50_mgeng.pdf
    Section 10, part 6 has a script to run to do this.

    Once done. You need to point the management server at the new SQL location.  To do this, on the management server run:
     C:\sec_50\ServerInstaller \setup.exe

    This will start a modify where you can choose the new SQL server.  This will in essence update the registry keys which hold the connection strings.


    The local SQL instance on the management service should then probably be stopped and even uninstalled when you're happy it's all working.  I'd probably just disable the SQL service just incase I needed to move the databases back to a local instance.

    Hope this helps.

    Regards,

    Jak

    :23207
Children
No Data