Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 1 subscriber
  • Views 794 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

Migrate SEC 3.0

Dario

Hi,

I know I'm a bit late but I'm trying to migrate (move) a SEC 3.0 from a server to another (Win2003 32 bit), then I'd like to upgrade it on the destination server to version 4.7.

I've found how to upgrade it but not how to move it to the new server; I'd like to move and then upgrade because the SQL Server of the source server is managing other instances I don't want to involve.

Please can anyone point me to a link or step by step guide to move the SEC 3.0?

Thanks

Dario

:17625


This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    Moving SEC 3.x rather than SEC 4.x should be easier, as SEC4.x has more steps.

    The main thing to get right first is to backup on the source machine the "certauthstore" registry key, I..e.

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore

    and import that on the new server before installing SEC3 on the new server.  This way the existing certificates will be re-created. Note: You suggest that they are both 32-bit so you will not need to change the path in the reg file

    In an ideal world you wouldn't want to loose any data during the switch over; therefore you would want to stop the Sophos Management Service and Sophos Message Router service on the "Source" machine.  This will backup messages on the clients and prevent new records being written to the database, leaving you with a database backup that is getting out of sync.

    You can then take a backup of the SOPHOS3 database. 

    So the steps would look something like this:

    1. On the new server, import the key "HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore " first.
    2. Install a new SQL 2005 Express (or full) SOPHOS named instance (I can't remember what version of SQL Express SEC 3 Supported, I don't think 2008 so I would still with 2005 at this stage).  This will save upgrading MSDE later.
    3. Install SEC 3 on the machine to use the SQL 2005 SOPHOS instance.
    4. Stop the 2 services on the source: management service and message router.
    5. Backup the SOPHOS3 database on the source. I would suggest using "\program files\sophos\enterprise console\DB\backupdb.bat". This will create you a database file, e.g.. "SOPHOS3.bak" you can restore to the new server using the RestoreDB.bat (same dir) later.
    6. Stop the Management service on the new server
    7. Restore the backed up SOPHOS3 database over the new SOPHOS3 database on the new server using restoredb.bat.
    8. Start the management service on the new server.
    9. Configure EMLibrary and get all the CIDs configured on the new server
    10. Protect the new server from it's own CID and ensure that's all working OK. 

    You should now be in a position where the new server is working and has all the configuration of the old server in terms of polices and groups and SAV on the local machine is updating OK locally.  Obviously all the updating polices on the new server will be pointing at the CIDs on the old server.  I assume you want to move the updating locations to the new server.  So you can update your updating policies to point to the new server.

    The next problem is the clients, they are all pointing at the old server.   The good news is that you can still backout at this point if everything isn't working as it should, all you need to do is start up the management service and router on the source server but hopefully that's not required.

    To point the clients at the new server you have a couple of options which you choose could depend on the number of clients you have, if they are always on, etc,,,

    1. Reprotect the clients from the new server. 

    2. Re-bootrap them through a scripted install, i.e.. Running setup.exe from the new CID with the necessary switches.

    As the compute records in the database, the machines should re-appear in the same groups they were in before and you can ensure they have all the polices.

    3. Run a script on all the existing clients to point them at the new server.

    I wrote a HTA available here:

    /search?q= 8939  

    which will generate a vbs file you can run on all clients to re-initilise them in terms of RMS.  You just reference from the tool the new cac.pem and mrinit.conf files of the new server.  You can use the files in the CIDs on the new server, those files are the same everywhere on the new server.

    4. Use a custom mrinit.conf in the existing CID to point them at the new server.  I would avoid this method unless you have to.

    Which ever you choose, attempt the approach on a couple of test clients, and ensure you can send policies to them and they update ok and send in status messages.  IDE count is updated etc...

    Once migration is complete I would let it bed in for a day or 2, make sure everything works and all the clients are happy.

    Then consider upgrading to SEC 4,  You still have the old server at this point so that's a useful backup.

    I hope this gives you a solution.

    Regards,

    Jak

    :17637
Reply
  • 0

    Hi,

    Moving SEC 3.x rather than SEC 4.x should be easier, as SEC4.x has more steps.

    The main thing to get right first is to backup on the source machine the "certauthstore" registry key, I..e.

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore

    and import that on the new server before installing SEC3 on the new server.  This way the existing certificates will be re-created. Note: You suggest that they are both 32-bit so you will not need to change the path in the reg file

    In an ideal world you wouldn't want to loose any data during the switch over; therefore you would want to stop the Sophos Management Service and Sophos Message Router service on the "Source" machine.  This will backup messages on the clients and prevent new records being written to the database, leaving you with a database backup that is getting out of sync.

    You can then take a backup of the SOPHOS3 database. 

    So the steps would look something like this:

    1. On the new server, import the key "HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore " first.
    2. Install a new SQL 2005 Express (or full) SOPHOS named instance (I can't remember what version of SQL Express SEC 3 Supported, I don't think 2008 so I would still with 2005 at this stage).  This will save upgrading MSDE later.
    3. Install SEC 3 on the machine to use the SQL 2005 SOPHOS instance.
    4. Stop the 2 services on the source: management service and message router.
    5. Backup the SOPHOS3 database on the source. I would suggest using "\program files\sophos\enterprise console\DB\backupdb.bat". This will create you a database file, e.g.. "SOPHOS3.bak" you can restore to the new server using the RestoreDB.bat (same dir) later.
    6. Stop the Management service on the new server
    7. Restore the backed up SOPHOS3 database over the new SOPHOS3 database on the new server using restoredb.bat.
    8. Start the management service on the new server.
    9. Configure EMLibrary and get all the CIDs configured on the new server
    10. Protect the new server from it's own CID and ensure that's all working OK. 

    You should now be in a position where the new server is working and has all the configuration of the old server in terms of polices and groups and SAV on the local machine is updating OK locally.  Obviously all the updating polices on the new server will be pointing at the CIDs on the old server.  I assume you want to move the updating locations to the new server.  So you can update your updating policies to point to the new server.

    The next problem is the clients, they are all pointing at the old server.   The good news is that you can still backout at this point if everything isn't working as it should, all you need to do is start up the management service and router on the source server but hopefully that's not required.

    To point the clients at the new server you have a couple of options which you choose could depend on the number of clients you have, if they are always on, etc,,,

    1. Reprotect the clients from the new server. 

    2. Re-bootrap them through a scripted install, i.e.. Running setup.exe from the new CID with the necessary switches.

    As the compute records in the database, the machines should re-appear in the same groups they were in before and you can ensure they have all the polices.

    3. Run a script on all the existing clients to point them at the new server.

    I wrote a HTA available here:

    /search?q= 8939  

    which will generate a vbs file you can run on all clients to re-initilise them in terms of RMS.  You just reference from the tool the new cac.pem and mrinit.conf files of the new server.  You can use the files in the CIDs on the new server, those files are the same everywhere on the new server.

    4. Use a custom mrinit.conf in the existing CID to point them at the new server.  I would avoid this method unless you have to.

    Which ever you choose, attempt the approach on a couple of test clients, and ensure you can send policies to them and they update ok and send in status messages.  IDE count is updated etc...

    Once migration is complete I would let it bed in for a day or 2, make sure everything works and all the clients are happy.

    Then consider upgrading to SEC 4,  You still have the old server at this point so that's a useful backup.

    I hope this gives you a solution.

    Regards,

    Jak

    :17637
Children
No Data