Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 2929 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SEC 5.0 Update managers

lanmanx

We are currently running SEC 4.7 with 15 SUMs (one per office). We have setup a new instance of SEC 5.0 for testing. It only has one SUM which is the Sophos server itself. I'm wondering if it's possible to upgrade one of the current SUMs and still have clients pull updates without need to upgrade client to SAV 10?

:21069


This thread was automatically locked due to age.
  • 0

    Hello lanmanx ,

    if I understand correctly you want to test the setup with an additional SUM. You should not do this with one of the production SUMs. The SUMs upgrade themselves automatically when the "master" is upgraded. Manually upgrading one of the child SUMs will cause instabilities or worse. Usually you won't notice them upgrading (unless you look for it) and I am not aware of problems there (although I won't rule them out).

    In an updating hierarchy the CID numbering (Snnn) is consistent. The Recommended subscription is distributed to S000 and the update path for clients using the recommended subscription contains CIDs\S000.  When you upgrade to SEC5.0 your existing subscriptions will not be modified (so SAV10 will not be forced on the clients). In fact you can upgrade to the next SAV version either before of after upgrading SEC (although the latter is recommended as the corresponding version of SEC is required to manage all new features of SAV).  

    Now it is possible to test what you want but it is rather tricky and IMO the potential problems outweigh the benefits (if there are any). If you insist, I could give you more details. BTW - do your SUMs also act as message relays? If so, then no dice.

    Christian

    :21087
  • 0

    Thanks for your response QC. To answer your question, our SUMs do not act as message relays.

    I must be lacking a full understanding of the upgrade proceedure. What we currently have is SEC 4.7 running on master server with a SUM in each of 15 offices. Clients are all running SAV 9.7 and there is an updating policy for each office that points them to their local file server for updates. What we have done thus far is setup a new server running SEC 5.0 and upgraded a handful of computers to SAV 10 that are local to the master server. The clients are currently using the Default update policy which is using the SUM on the master server itself.

    Since we are basically abandoning the old setup and forcing everyone over to the new server, we assumed we would have to re-install/upgrade the SUM on each office file server and then re-protect the clients to force an upgrade to SAV 10. Just to be clear, the new server does not know about the office SUMs - none appear in Update managers other than server itself.

    Do you think there is a problem in what we are proposing to do?

    :21109
  • 0
    Hello lanmanx,

    is the new server using the same certificates as the old one?
    This aside - SUMs do not advertise themselves (nor is there an "Enterprise view" (yet) comprising several management servers). A SUM reports to its master similar to a client to SEC. I
    It's late Friday here - if you can wait until next week I can give you some details.

    Christian
    :21113
  • 0

    Sounds good. Thanks QC. Have a good weekend.

    BTW: We did not import certificates from the old server. Starting completely over from scratch with this one.

    :21121
  • 0

    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

    :21171
  • 0

    Thanks Christian. Your response really clears up my understanding of how it all works. I'll check out the 4.7 migration guide in conjunction with the steps you've outlined and relocate one of the SUMs to start.

    Thanks again. Your help is greatly appreciated. Take care.

    :21183