Sophos Enterprise 5.2 migration

Hello svdb,

article 33980 is in my opinion not the right one

you are correct that it does not describe the process of moving the management component. Basically you have two options (Note: the original server must be turned off before you install the new one and must stay turned off):

1. Just make a fresh install (without the database component) and point the installer to the existing database. Make sure you have all the required credentials (e.g. database user) available. You'd then have to reprotect your clients from the new server
2. Export (backup) everything except the database, import on the new server as specified in the migration guide, then install (again w/o the database component)

If the new server does not inherit the old name/IP then the tricky part for option 2 is to "move over" the clients (unless you reprotect/reinit them). There are several ways. You could assign the new updating policies while the old server is still running. The clients would fail to update until the new server is active (although you could pre-load the CIDs there). The obvious drawback is that clients not online at this time will not receive the new policies. To overcome this you could configure the old CID for either AutoUpdate (using sauconf.xml with the new update location) or RMS (with an appropriate mrinit.conf). In any case the RMS components should be configured in the CIDs on the new server. Special considerations apply if you are using Patch Assessment

Feel free to ask if you need more details.  

Christian

Thanks for your answer, i will look what's the best sollution for our organization.

1. Just make a fresh install (without the database component) and point the installer to the existing database. Make sure you have all the required credentials (e.g. database user) available. You'd then have to reprotect your clients from the new server 

but all the Policies and Setttings will be lost, right? What could be done in this option to keep them?

2. Export (backup) everything except the database, import on the new server as specified in the migration guide, then install (again w/o the database component

Exported. Installed Server & Console Components and pointed it to the DB. Imported using DataBackupRestore. Right?

Please point wherever I'm wrong. :catsad: 

Hello Vikas,

the database has almost all the information, endpoints and their grouping, policies, events. You don't have to restore the database (as long as its and SEC's version match), you continue to use the existing (remote) database with a newly installed management server.

The difference between method 1 and 2 is that the latter keeps the identity of the management server. The identity is not IP or name but kinda ID card the server presents to the endpoints. When the software is installed the endpoints make note of this ID and from then on they only talk (that is communicate via RMS) to a server presenting this very ID.

Method 1 is simpler but (arguably) less elegant and requires that all endpoints are reprotected.

What's not working? When installing the management server the old database (whether it has been pointed to in the dialog or imported after installation of the database component) must be present so that the entry for the old management server can be updated to reflect the new one. If you restore the database after the management server has been installed it won't be consistent.

Christian

 Thanks!

I would be grateful if you could shed some light on the highlighted part. I have tried to understand from various sources but everything got mixed up.

cac.pem - contains the root certificate. Significance? Which registry key contains it?
mrinit.conf - contains certificate strings, ports and parent address.

I have seen cases where they just say to backup the "SecureStore"which is the certAuthStore so that the endpoints know that THIS is the server I should be talking to. Then what about the RMS keys?
Significance ? which files contain them?

I know it's a hassle for you but I'd request you to share some of your knowledge. :catsad:

Hello Vikas,

I have tried to understand

academic interest? An in-depth understanding is not necessary to successfully use and manage SESC.

As far as practical use goes the following is IMO relevant:

• If the CertAuthStore does not exist the server generates its keys, otherwise the existing ones are used
• From these cac.pem and (parts of) mrinit.conf are generated for endpoint use
• When an initial install is performed (i.e. setup.exe from the CID is run by whatever means - manually, Protect computers, or from a package) these data sets up the mutual trust (note that you can perform such an install regardless of the existing data)
• From then on the endpoint verifies the server's identity with this information (both for RMS and AutoUpdate)
• V.v. the endpoint proves it has been installed from a CID managed by this server

So much for this week ... Christian

Hello Christian,

mm, well I've been freshly inducted into Sophos TAC Support :catsad: 

And going through this forum is really knowledgeable. 

Thanks for your reply :)

Hello Vikas,

Thanks for your reply

I'll charge it against the upcoming license renewal :smileywink:

Christian

Hi Christian,

would have loved to have you as a colleague! 

Sophos is confusing. McAfee was far more simplified.

Anyways, how do we DM in this community?

Thanks,

Vikas

Hello Vikas,

how do we DM

I don't do DM (guess you don't mean Direct Marketing), PM (private message) perhaps? If so, the details are in About SophosTalk. 

Sophos is confusing

It is? Isn't it Security made simple?

Christian