Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 8144 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

Retiring Server and Client Update Behavior

AaronMelgares

We've migrated endpoints to a new Sophos server a while ago, but due to several factors (Higher-Ed, loosely managed endpoints) there are a a few hundred computers that won't be able to migrate to the new server before we shut it down next month.

These endpoints have our local SUM set as the primary update server and Sophos is the secondary.  I want to clarify what the endpoint behavior will be once we shut off the old server.  Here is my current understanding:

Endpoints will try to contact the primary server, fail, and then check with Sophos for updates.  Sophos will provide IDE file updates, but will not update the SAV or SAU software until the version being used is near retirement.  RMS will try to send messages to the old server which will fail becuse the message relay is not there.

Does this sound right?  Is there some timeframe at which the IDE files won't work on these orphaned endpoints?

:51182


This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    Yes it's a shame the new server has new certs and the certauthstore key from the old wasn't imported into the new server before installation.  Had that been the case and f they these computers are updating from update locations on the old server, to move them to the new server all you would have needed to do is:

    1. Copy mrinit.conf from the new CID to the "rms" sub directory of the old CID.

    2. Run Configcid.exe against the old CID to add the rms\mrinit.conf to the catalogue fle.

    3. On the next update from the CID, the clients pointing at the old CID would download mrinit.conf, RMS will re-initialise and change the clients ParentAddress to be the new server. 

    4. Once they checked in you could assign them the new updating policy.

    If there is a new cac.pem and mrinit.conf, then the migration script you mention is one way to completely re-init the clients in terms of RMS rather than just re-pointing their parent address. Anything else will require something to be run on the clients at that point there are plenty of options.

    Regards,
    Jak

    :51222
Reply
  • 0

    Hi,

    Yes it's a shame the new server has new certs and the certauthstore key from the old wasn't imported into the new server before installation.  Had that been the case and f they these computers are updating from update locations on the old server, to move them to the new server all you would have needed to do is:

    1. Copy mrinit.conf from the new CID to the "rms" sub directory of the old CID.

    2. Run Configcid.exe against the old CID to add the rms\mrinit.conf to the catalogue fle.

    3. On the next update from the CID, the clients pointing at the old CID would download mrinit.conf, RMS will re-initialise and change the clients ParentAddress to be the new server. 

    4. Once they checked in you could assign them the new updating policy.

    If there is a new cac.pem and mrinit.conf, then the migration script you mention is one way to completely re-init the clients in terms of RMS rather than just re-pointing their parent address. Anything else will require something to be run on the clients at that point there are plenty of options.

    Regards,
    Jak

    :51222
Children
No Data