Install new Server with Enterprise Console and manage all preview Endpoints

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

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