Install new Server with Enterprise Console and manage all preview Endpoints

Hello FFN,

so, Protect Computers did (does) work from the old console but it fails from the new? If you don't intend to use Protect Computers during regular operation (for deployment of new endpoints or correcting ptoblems) you could follow article 116737 as mentioned in chapter 13 of the guide. Otherwise - could you describe the protect failure and the error you get?

Christian

Yes everything works fine with the old enterprise console. But I'd like to turn this server off and install the sophos management on a new windows 2012 server. And if I have to install everything new anyway I'd like to start from zero. So I will not have any old stuff, missconfigurations, dead policies etc. But I'm not willing to reinstall sophos on every endpoint again.

So I'm asking if I can add all the old endpoints to the new enterprise console on the new 2012 server?

The way described in the guide (right click to a folder or endpoint and choose "protect computer") didn't work. 

The selected endpoint stayed a while in the state of installation (yellwo houreglass), then after several minutes (felt very a very long time) I got an error.

I can't tell you the correct error anymore because I already reinstalling the Win 2012 VM.

I'm downloading the CIDs to a DFS Share. This won't change with the new 2012 server. So I assumed all endbpoints wil appear as "managed" (green Icon) in the new console automatically.

Hello FFN,

whether you want to reprotect your existing computers (if the same set of credentials can be used for all it can be done with one call of the wizard, furthermore of all clients are "healthy" it won't have a significant impact on them) or not isn't the important matter - the question is, will you have to Protect Computers in the future for new (or replaced) clients. If so, then you'd want it to work so sooner or later you'd have to address this issue.

Putting this aside for now - a some details how it all works and a few remarks: DFS is, IIRC, ok as long as you don't use replication. As it works now it'll likely do so later. It's not clear what exactly you did interim - you expected the clients to appear as "managed" [...] in the new console automatically. Obviously it can't be that the clients will flock to a new server once it's there (and when it's gone ruefully scuttle back to the old one). There has to be some change the clients can observe so that they know they have to switch servers.

A SUM (not necessarily the one on the management server) writes the CIDs to one or more shares. The management server instructs the clients to update from one specific share or webfolder (the secondary location is a fallback and assumed to have identical contents). As you've mentioned DFS - are you thinking of letting the new server write to the same location as the old one and thus effecting the switchover? If so, how will you test (or did test) - having to SUMs write to the same location is calling for troubles. If you use different locations then you'd have to tell the clients to use the new one. As they are still manged by the old one this has to be done from there.

About management (RMS) and how a client "appears" in SEC. When being installed a management server takes on an imperishable identity. It is not determined by name and/or IP but a private key and associated certificate. If these are already present at install time (see Chapter 7 in the Guide) they are used and not replaced or modified. The main purpose is that the server remains "the same" if you have to repair or restore an installation. The additional is uses are for planned server migration and to have several "identical" servers. 

When RMS is installed on the client for the first time it makes note of the server's identity and also gets instructions how and where to reach the server (by means of mrinit.conf). All subsequent communication (whether to the server directly or through a message relay) is subject to verification. Although a modified mrinit.conf can instruct the client to use a different upstream router, the client will not establish (direct or indirect) a connection to a server with a different identity. Thus to direct a (Windows) client to a different management server with the same identity it suffices that it downloads the applicable mrinit.conf. If the identity is not the same then the client has to be reprotected (either from SEC or with a local install, in case of a non-Windows OS it's necessary to uninstall Sophos first).

A client appears (as managed) in the console only when it establishes connection with the server. As written above two conditions mus be met:

1. the update location must contain the appropriate mrinit.conf
2. the server must have the same identity

Of course a client communicates only with one server at a time. You can mange it only from the one where it appears as managed and connected (it does not disappear from the old when it connects to a new one).

I hope it is clearer now. It's up to you which path you pursue. Of course feel free to ask if you have additional questions.

Christian

QC: As you've mentioned DFS - are you thinking of letting the new server write to the same location as the old one and thus effecting the switchover? If so, how will you test?

FFN: Yes, my plan was to use the same DFS Share for the new server. But this can’’’’t be a problem, because I never user both server at the same time. I stop the services on the old server and start the new server. So there will never be 2 server using the same DFS share.

QC: Having 2 SUMs write to the same location is calling for troubles. If you use different locations then you'd have to tell the clients to use the new one. As they are still managed by the old one this has to be done from there.

But this is contrary to what you said before. I tell the old server to use the new update share (configured in the new server), so in this moment I’’’’m going to have 2 servers using the same share!

QC: When RMS is installed on the client for the first time it makes note of the server's identity and also gets instructions how and where to reach the server (by means of mrinit.conf).

FFN: But then I have no chance to install a new server. Because the only one who can edit this mrinit.conf is the old server, because this server manages all endpoints. So how do I tell the endpoints to listen to the new server via the old server? This seams to me impossible?!

QC: A client appears as managed in the console only when it establishes connection with the server. As written above two conditions must be met:

1. the update location must contain the appropriate mrinit.conf

2. the server must have the same identity

Of course a client communicates only with one server at a time. You can manage it only from the one where it appears as managed and connected.

(it does not disappear from the old when it connects to a new one).

FFN: So whats your succestion? What is the easiest way to solve my problem? New DFS Share, new installation on new server and just reprotect all clients?

This morning I followed the migration guide 1:1, so I’’’’ll have the exact same on the new server. BUT this din’’’’t work out so well. I can start the console and I can see everything. But its frozen. I can’’’’t click anything. After a while I found out, that this error message is shown (was not a message in front of everything):

http://www.sophos.com/de-de/support/knowledgebase/53965.aspx

Hello FFN,

how will you test?

Assuming everything works with the old server. You turn it off and let the new one take over. It rewrites the CIDs (unless it balks at overwriting) - but if this doesn't work as intended your clients won't be able to update. This is not what I call a test :smileywink:.

write to the same location

SUM verifies the consistency of the CID but when "someone else" modifies the contents SUM might (again might, I've never tested it) fail to update the share next time.

When a server creates a CID it writes the appropriate mrinit.conf (which, BTW, you can edit) to it. After creating the inital mrinit.conf a server doesn't modify (or edit) it. The server also can't tell the clients to turn to a different management server. As said, for "redirecting" to work the servers must use the same credentials (otherwise the clients will not accept the reconfiguration). What the "old" server can do is telling the clients to update from some other CID (which is maintained by the new server and contains the appropriate mrinit.conf ). This CID must have the mrinit.conf also in the \rms subdirectory though. Otherwise you'd configure the CID maintained by the old server with the mrinit.conf for the new one. As said, I'd recommend different "old" and "new" shares.

As for the error - you should be able to work after acknowledging the popup.

Christian