Enterprise console migration

Hello nf,

there's more than one way to skin a cat.

Installing a blank SEC takes less than one hour, with a restore/migrate of the database it shouldn't take more than two.

not really concerned about losing history
History might not be of interest, the database also contains your subscriptions (actually not hard to reenter though), your policies (might be a few, might be many), and the group structure and policy assignments, and last but not least the computers with their group-membership. You can either backup/restore/migrate (it's not rocket science) the database with all this information or you have to re-do and re-type everything (except the computers which could - depending on the path you take - "appear by themselves" in the Unassigned group or have to be discovered/re-protected or by some other means told to re-install). 

The IMO most important aspect is that your endpoints aren't marooned. Re-protect from the console requires (apart from discover) that the endpoints are online.

Some possible scenarios (OS already installed on the new server):

1. Backup and export all necessary data (including the certificate store) on the old server, turn it off. Change name and IP of new to old's values. Import certificates, start SEC installation - if you follow the database import procedure almost everything will be there (and work) when the install is complete, otherwise the endpoints will gradually appear.
2. Backup and export all necessary data (including the certificate store) on the old server, if you want to migrate the database turn off the Sophos services before the final backup and leave them off. If the new server is ready you could configure the CID(s) on new and trigger a "move" of the endpoints (Windows, possibly Linux) to the new server by changing the updating policies or a temporary (DNS) alias.
3. Install SEC on new not migrating anything, then re-protect, re-install, or re-direct your endpoints.

Each has pros and cons, 1. is simple provided everything works (and you can easily change name and IP for a machine). I've left out most details (too many trees and you won't be able see the wood), feel free to ask.

this statement
couldn't find it here - anyway, the last sentence doesn't make sense [:)]

Christian

Hello nf,

there's more than one way to skin a cat.

Installing a blank SEC takes less than one hour, with a restore/migrate of the database it shouldn't take more than two.

not really concerned about losing history
History might not be of interest, the database also contains your subscriptions (actually not hard to reenter though), your policies (might be a few, might be many), and the group structure and policy assignments, and last but not least the computers with their group-membership. You can either backup/restore/migrate (it's not rocket science) the database with all this information or you have to re-do and re-type everything (except the computers which could - depending on the path you take - "appear by themselves" in the Unassigned group or have to be discovered/re-protected or by some other means told to re-install). 

The IMO most important aspect is that your endpoints aren't marooned. Re-protect from the console requires (apart from discover) that the endpoints are online.

Some possible scenarios (OS already installed on the new server):

1. Backup and export all necessary data (including the certificate store) on the old server, turn it off. Change name and IP of new to old's values. Import certificates, start SEC installation - if you follow the database import procedure almost everything will be there (and work) when the install is complete, otherwise the endpoints will gradually appear.
2. Backup and export all necessary data (including the certificate store) on the old server, if you want to migrate the database turn off the Sophos services before the final backup and leave them off. If the new server is ready you could configure the CID(s) on new and trigger a "move" of the endpoints (Windows, possibly Linux) to the new server by changing the updating policies or a temporary (DNS) alias.
3. Install SEC on new not migrating anything, then re-protect, re-install, or re-direct your endpoints.

Each has pros and cons, 1. is simple provided everything works (and you can easily change name and IP for a machine). I've left out most details (too many trees and you won't be able see the wood), feel free to ask.

this statement
couldn't find it here - anyway, the last sentence doesn't make sense [:)]

Christian

Thanks Christian!

I think I will follow your advice and go with option 1 and follow the "server to server migration guide" for the steps on backing up the DB and restoring. Although I'm not sure what you meant by the certificate store? I don't see that referenced in the guide.  If its related to encryption, we have not used that ...yet.

One last thing, does it matter that I don't have the Update Manager password?  took over this position from someone and have no idea what they used.

First timer to Sophos here also migrating from 5.1 on Win2003 32-bit to Win2012 64-bit. I've downloaded the migration PDF and the steps seem to match well with what I have. The only question I have is regarding what happens when I've stopped the Sophos services to migrate the configuration to the new server. If I hit a snag, or wish to back out, or if re-directing the clients to the new server is going to take a while, is it OK to restart the services on the old server until (a) the new server is fully ready and (b) all the endpoints are using the new server?

I recently renewed our Sophos subscription and we received the Update Manager credentials with the licence, so you'll probably find it there.

Hello nf,

certificate store
related to encryption, yes - but not the withdrawn Full Disk Encryption. RMS communication is cryptographically secured. Upon installation the management server generates (or re-uses) keys and certificates (please find some related articles here). These are what establishes the server's identity, name and/or IP are "only" used to locate the potential server - thus if you (re-)install a server from scratch existing endpoints won't communicate with it even if it has the same name and IP. The store is among the things backup up by the DataBackupRestore tool.

the Update Manager password
the account is required to provide clients read access to the distribution location share. It's set in the Default updating policy and also used to pre-populate the credentials in a newly created policy. Please note that credentials are stored and not referenced in the policies. Thus when you restore the database the policies will contain the password from the old server. You can either change the password on the old server or create a new account (which you would then use as the SUM account on the new server) as per chapter 6.1 of the migration guide.

One subject I have not yet addressed: You probably want to upgrade to SEC 5.4, don't you? To my knowledge an upgrade-migration is not a supported scenario but possible. You'd use the sec_540 installer to install the database component. Instead of DataBackupRestore you'd use RestoreDB.bat to restore SOPHOS521, SOPHOSPATCH52, and SophosSecurity. You'd then proceed installing the server components. After importing the registry (chapter 11) the Initial Catalog in DatabaseConnectionMS must be (re-)set to SOPHOS540.

Do not forget the changes necessary for 32-bit to 64-bit migration if applicable.

Christian

Hello LinkToThePast,

SEC 5.1 (retired) is not supported on 2012 - what is your intended procedure?

is it OK to restart the services on the old server?
Well, naturally it updates the old database, there's no way to transfer the delta to the new one. Another backup/restore is of course possible - you'd have to re-apply the necessary changes.

If you don't need to keep history data you can run both servers in parallel provided everything is configured correctly.

Christian
NB: I think nf did not refer to the license credentials

Thanks QC. I'm going from 5.1 on 32-bit Windows 2003 to 5.4 on 64-bit Windows 2012. I've been referring to the migration guide PDF, which is actually for 5.3 to 5.3 but the steps seem to match what is in 5.1 anyway.

I think I'll just do the one backup/restore to capture the policies etc, but the history of what happens between that and final shutdown of the original server wouldn't be critical, as far as I can see.

We are also using SEC to manage SafeGuard Encryption on laptops. What potential pitfalls should I be looking out for with that? Please tell me it won't be necessary to re-encrypt everything... [:'(]

Much appreciated. I will the migration starting next week.

thanks for your assistance.

Hello LinkToThePast,

5.3 to 5.3
in principle the steps match. You can't install 5.4.0 on 2003 or 5.1 on 2012. I've mentioned a migrate-upgrade scenario in today's reply to nf and that it's not supported (but, as said, possible).

using SEC to manage SafeGuard Encryption
If you're talking about Sophos Full Disk Encryption (SafeGuard 5.61) this feature has been retired, sorry [:(]

Christian

So there is now no encryption option and systems will have to be decrypted before being migrated, and we will need to source a new encryption product? Why does the license we purchased still say "and encryption"? [:@]

Hello LinkToThePast,

don't shoot the messenger [:)] (I'm not Sophos BTW)

The Downloads section will show you the products available with your license. If there isn't any Encryption (I'm on a legacy "hybrid" license so I can't tell what you should see) you should take this to your reseller (or whoever supplied the license) or customercare@sophos.com.

IIRC a custom SafeGuard 5.60/5,61 (FDE or SDE or by whatever name it went at this time) integrated with SEC was shpped with SEC 5.1 for select licenses. I took part in the Beta and at GA time it already looked like it wouldn't be pursued in the future (my opinion/observation only). 5.61 can't handle BitLocker and doesn't support post-W7 platforms so the retirement wasn't unexpected. BTW - looks like the free Encryption products have been withdrawn as well ...

Christian