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

SEC Server to Server migration

Hi QC,

 [QC:Edit] Split off the  Not Answered Promote Remote SEC to Primary SEC thread [/Edit]

I am looking at a similar situation and wanted to clarify something......

If i'm understanding it correctly, MEric's solution would provide a slow migration method but the new SEC would not have any of the group settings or policies as the previous instance? Just trying to understand how the last sentence of your reply would play out in that scenario. 

Basically, if setting up a new "Management Server" you can't slow transition, instead you would need to do a hard cutover and then once the new 2016 Management Server is setup with the imported historical data, the endpoints would need to be either redirected or reprotected so that it checks into the new management server. Please correct me if i'm misunderstanding.



This thread was automatically locked due to age.
Parents
  • Hello David D1,

    if you want to keep the settings and historical data you have to restore the database on the new one.
    Naturally you'd stop the old server before doing so and never start it again. Endpoints should queue the messages they can't send, guess the migration utility preserves them, a reprotect would delete them though. Hm, thinking about it - the messages are perhaps secured/signed and unless you use the same certificates the new server will reject the queued messages. Haven't tested this though.

    Have to think about it, it's past 6pm, so ... I'm about to migrate my SEC551 from 2008R2 to 2016 and have not yet made up my mind what to keep and how. I can definitely neither use reprotect nor the EMU, have to use the method outlined in 1.2 and 1.3 here.

    Christian

Reply
  • Hello David D1,

    if you want to keep the settings and historical data you have to restore the database on the new one.
    Naturally you'd stop the old server before doing so and never start it again. Endpoints should queue the messages they can't send, guess the migration utility preserves them, a reprotect would delete them though. Hm, thinking about it - the messages are perhaps secured/signed and unless you use the same certificates the new server will reject the queued messages. Haven't tested this though.

    Have to think about it, it's past 6pm, so ... I'm about to migrate my SEC551 from 2008R2 to 2016 and have not yet made up my mind what to keep and how. I can definitely neither use reprotect nor the EMU, have to use the method outlined in 1.2 and 1.3 here.

    Christian

Children
  • Hello David D1,

    there are undocumented and unsupported but possible variations of the migration. BTW: Didn't ask: Is your database local?

    • Using the same name (not necessarily IP) for the new server:
    A little bit tricky: You can't install SEC on new before it has its final name. You have to copy everything you need (including the certificates) from old to new, shut down old, rename new to old, then install SEC. Endpoints won't really notice a change but will locally show failed updates until the CIDs on the new old are available. In the worst case you can fall back to the old old.

    • Migrate settings and make a slow endpoint transition
    If you are only or mainly interested in the groups (including their members) and policies (note: you'll likely have to edit the Updating policies so that they point to the new server) but some loss of alerts and events is acceptable you can migrate the database, restart the old server, then start redirecting the endpoints

    Whatever method you prefer I'd suggest that you leave the CIDs on/from the old server accessible (naturally not possible when using the same name). Disable the Sophos management services instead of just stopping them before backing up the database but leave the server running. You can even restart them if you block all non-loopback access to the Sophos Message Router with the local firewall. Endpoints won't show update failures and in the second case even continue to update. Of course you won't be able to manage them until they are migrated but they will queue their messages. The important ones (alerts and errors) have a TTL of 14 days so the loss might be minimal.

    Christian 

  • QC, 

    Database is local with plans to break it out into a dedicated SQL host post migration.

  • Hello DD,

    the procedure for breaking it out is the same on old and new. Doing it on old saves you the server to server database migration. BTW: Depending on the history of SEC on old the installer might install a different local SQL Server version on new.

    Christian