SEC Server to Server migration

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

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

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