SEC 5.0 Update managers

Hello lanmanx ,

first a few words about these certificates. If you import the keys before installing SEC the server will have the same "identity" in terms of RMS. With a small addition to the CIDs you can "move" the clients between management servers by just changing the update location.

So you want to migrate you installation to the new server eventually. While the 5.0 migration guide is not yet out most of the current (47) version applies anyway. As you are using different certificates you'll have to re-protect or re-init your clients at a certain point. 

Management server and download location

Clients don't have to download/update from a location managed by their management server (otherwise you couldn't use Sophos as secondary location).  Although you get warnings when configuring the update policy you can specify (almost) any UNC or HTTP path (except when using location roaming). Thus you can use a CID deployed by a SUM from another hierarchy. As the subscription defines the short tag (Snnn) you have to edit the subscriptions on the two different hierarchies accordingly. The least confusion arises when you use the same short tags - i.e. you set Recommended to 9.7 in both the hierarchies and create one additional subscription for 10.0 (which should get S001 - unless you have already defined additional ones on your "old" hierarchy).

Management server and SUMs

The management server is used to configure the SUMs it knows if (which are usually the ones installed from its SUMInstallSet share). As RMS for all its functions only talks to one management server (potentially using a relay) only a SUM can only be part of one hierarchy. All the SUM's configuration is done from its management server's console.  

Management server and endpoints

Clients "know" their management server from the CID used for the initial install (using the information in mrinit.conf and cac.pem). They talk to and accept messages from this server only - even if they update from a CID belonging to a different hierarchy the won't re-configure RMS (unless the keys match because you've made the two servers to appear the "same"). 

There's more (and more than one way to skin a cat) but for now this should suffice (it is already complex so far). One possible scenario:

1. Create a new subscription on your new server (check if it goes to S001, from the console View->Bootstrap locations)
2. Select 10.0 for this subscription
3. Create an new updating policy to use this subscription and assign it to your new server and its (already existing) clients 
4. Make sure that all endpoints have updated from the new location (in other words, none are updating from S000)
5. Select 9.7 for the Recommended subscription
6. "Relocate" one of the SUMs to the new server. I have achieved this by (re-)installing it from the new server's SUMInstallSet. (might also work if you just follow the instructions in 6.1.7 of the Migration Guide). If it is also protected (which I assume) you should disable automatic updates during this time. Once it appears in the new console put it in the relevant group it should then resume updating SAV from the new location (Note: I can't re-test this right now, I've done that a few weeks ago and it worked).
7. You now have one of the child SUMs in the new hierarchy, its Recommended CID (S000) containing 9.7. The "old" clients should continue to update from there but refuse to make changes to RMS and thus will still be managed by the old server.

At this point take a break :smileywink: 

This should confirm that the new hierarchy is working (with SUM version 1.3.1.168). You can now either selectively apply the steps in 6.1.5/6.1.6 for the clients updating from this SUM (or use Jak's script from this thread), or "relocate" your other SUMs first, or - if you are confident - "relocate/redirect" the rest of your network "at once".

Note that the clients will remain on 9.7 throughout this process.

It is not as complicated as it may sound though (and I hope I didn't make any mistakes ).

Christian

Hello lanmanx ,

first a few words about these certificates. If you import the keys before installing SEC the server will have the same "identity" in terms of RMS. With a small addition to the CIDs you can "move" the clients between management servers by just changing the update location.

So you want to migrate you installation to the new server eventually. While the 5.0 migration guide is not yet out most of the current (47) version applies anyway. As you are using different certificates you'll have to re-protect or re-init your clients at a certain point. 

Management server and download location

Clients don't have to download/update from a location managed by their management server (otherwise you couldn't use Sophos as secondary location).  Although you get warnings when configuring the update policy you can specify (almost) any UNC or HTTP path (except when using location roaming). Thus you can use a CID deployed by a SUM from another hierarchy. As the subscription defines the short tag (Snnn) you have to edit the subscriptions on the two different hierarchies accordingly. The least confusion arises when you use the same short tags - i.e. you set Recommended to 9.7 in both the hierarchies and create one additional subscription for 10.0 (which should get S001 - unless you have already defined additional ones on your "old" hierarchy).

Management server and SUMs

The management server is used to configure the SUMs it knows if (which are usually the ones installed from its SUMInstallSet share). As RMS for all its functions only talks to one management server (potentially using a relay) only a SUM can only be part of one hierarchy. All the SUM's configuration is done from its management server's console.  

Management server and endpoints

Clients "know" their management server from the CID used for the initial install (using the information in mrinit.conf and cac.pem). They talk to and accept messages from this server only - even if they update from a CID belonging to a different hierarchy the won't re-configure RMS (unless the keys match because you've made the two servers to appear the "same"). 

There's more (and more than one way to skin a cat) but for now this should suffice (it is already complex so far). One possible scenario:

1. Create a new subscription on your new server (check if it goes to S001, from the console View->Bootstrap locations)
2. Select 10.0 for this subscription
3. Create an new updating policy to use this subscription and assign it to your new server and its (already existing) clients 
4. Make sure that all endpoints have updated from the new location (in other words, none are updating from S000)
5. Select 9.7 for the Recommended subscription
6. "Relocate" one of the SUMs to the new server. I have achieved this by (re-)installing it from the new server's SUMInstallSet. (might also work if you just follow the instructions in 6.1.7 of the Migration Guide). If it is also protected (which I assume) you should disable automatic updates during this time. Once it appears in the new console put it in the relevant group it should then resume updating SAV from the new location (Note: I can't re-test this right now, I've done that a few weeks ago and it worked).
7. You now have one of the child SUMs in the new hierarchy, its Recommended CID (S000) containing 9.7. The "old" clients should continue to update from there but refuse to make changes to RMS and thus will still be managed by the old server.

At this point take a break :smileywink: 

This should confirm that the new hierarchy is working (with SUM version 1.3.1.168). You can now either selectively apply the steps in 6.1.5/6.1.6 for the clients updating from this SUM (or use Jak's script from this thread), or "relocate" your other SUMs first, or - if you are confident - "relocate/redirect" the rest of your network "at once".

Note that the clients will remain on 9.7 throughout this process.

It is not as complicated as it may sound though (and I hope I didn't make any mistakes ).

Christian