Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 0 subscribers
  • Views 11834 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

Migrating Console to another server

nesdog

I have the KB articles about the process, however it's a bit convoluted. What is the effect if I simply build another server with the same domain name, install the console and go from there? (I would take the old server offline, of course.)  Each of the clients is already coded to update from that UNC name so it would seem from their point of view, no change would have taken place.

I would also set up the Active Directory synch to get all the computer names. Just seems like an easier method than doing all of the various registry, database backups and restores.

Feedback?

Thanks...

:56794


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

    Hi,

    There are certiany a few things to consider to trade off speed vs effort vs what you want to retain.

    Firstly, clients can only message to the new management server (SEC1) if the certificates are the same as on (SEC2).

    There is nothing to stop you installing SEC on a new server and re-ptotecting all the clients.  This will work.

    Maybe this option would mimise effort but still provide something:

    1. Backup the certauthstore from SEC1, i.e. HKLM\SOFTWARE\[Wow6432Node]\Sophos\Certification Manager

    2. Import into SEC2 server respecting the wow6432node.  Important this is done first before installing.

    3. Install SEC on SEC2 and setup SUM, packages etc, protect the server.  Essentially get a full functionaly SEC.

    4. On SEC2 import from AD to re-create the structure of computers/group etc.. If this is the way you want to operate the structure of computers.

    5. Create relevant policies and link them to the groups.

    At this point you just need to get the clients pointing at SEC2 as they are all still point at SEC1 - Note ParentAddress registry key of the router.

    3 options are available:

    1. Re-protect from SEC, either a pull by running setup.exe from the client as part of a script or a push using the SEC protect wizard.

    2. Use the script here: https://www.sophos.com/en-us/support/knowledgebase/116737.aspx to essentially create a VBS file you would need to run on all the computers, apart from SEC1 and SEC2.

    3. Take the mrinit.conf file from SEC2 server (e.g. from a CID) and put it into the rms sub directory of the CIDs on SEC1 and run configCID - https://www.sophos.com/en-us/support/knowledgebase/13112.aspx.  The next time the clients check in to SEC1, they will pull down this file and cause the clients to re-configure RMS to point at SEC2.  As the certificates should be the same, they should report their SEC status in and in effect fill in all the detail about the devices on SEC2. If the computers are pre-staged from an AD import they should just appear as managed in their correct groups. If you are using patch at the clients, this method will not point the patch client at the new server, but option 1 and 2 would.

    Obviously without migrating the database you will lose previous event history but this may not be a concern.

    If you plan on keeping SEC1 as a computer, once all the clients are reporting in you can uninstall all the Sophos components off of SEC1 and re-protect it from SEC2.

    Hope it helps,

    Regards,

    Jak

    :56800
Reply
  • 0

    Hi,

    There are certiany a few things to consider to trade off speed vs effort vs what you want to retain.

    Firstly, clients can only message to the new management server (SEC1) if the certificates are the same as on (SEC2).

    There is nothing to stop you installing SEC on a new server and re-ptotecting all the clients.  This will work.

    Maybe this option would mimise effort but still provide something:

    1. Backup the certauthstore from SEC1, i.e. HKLM\SOFTWARE\[Wow6432Node]\Sophos\Certification Manager

    2. Import into SEC2 server respecting the wow6432node.  Important this is done first before installing.

    3. Install SEC on SEC2 and setup SUM, packages etc, protect the server.  Essentially get a full functionaly SEC.

    4. On SEC2 import from AD to re-create the structure of computers/group etc.. If this is the way you want to operate the structure of computers.

    5. Create relevant policies and link them to the groups.

    At this point you just need to get the clients pointing at SEC2 as they are all still point at SEC1 - Note ParentAddress registry key of the router.

    3 options are available:

    1. Re-protect from SEC, either a pull by running setup.exe from the client as part of a script or a push using the SEC protect wizard.

    2. Use the script here: https://www.sophos.com/en-us/support/knowledgebase/116737.aspx to essentially create a VBS file you would need to run on all the computers, apart from SEC1 and SEC2.

    3. Take the mrinit.conf file from SEC2 server (e.g. from a CID) and put it into the rms sub directory of the CIDs on SEC1 and run configCID - https://www.sophos.com/en-us/support/knowledgebase/13112.aspx.  The next time the clients check in to SEC1, they will pull down this file and cause the clients to re-configure RMS to point at SEC2.  As the certificates should be the same, they should report their SEC status in and in effect fill in all the detail about the devices on SEC2. If the computers are pre-staged from an AD import they should just appear as managed in their correct groups. If you are using patch at the clients, this method will not point the patch client at the new server, but option 1 and 2 would.

    Obviously without migrating the database you will lose previous event history but this may not be a concern.

    If you plan on keeping SEC1 as a computer, once all the clients are reporting in you can uninstall all the Sophos components off of SEC1 and re-protect it from SEC2.

    Hope it helps,

    Regards,

    Jak

    :56800
Children
Unfiltered HTML