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

    If the primary update location becomes unavailable the clients will fail over to the secondary of Sophos as you say.  They will continue to get updates which includes major versions eventually.  Essentially they will not be left unprotected.

    Do these curently "unmanaged" clients fail both to update and communicate over RMS, essentially are all channels are cut off?

    Are they essentially either locked away, out of the office for an unknown peiod and either won't return at all or possibly at some time in the future?

    Out of interest how did you migrate the computers from the old to new server?  

    1. Reprotect from the new SEC.
    2. Use a script to re-direct them.
    3. Use a custom mrinit.conf in the CID to redirect them?
    4. Maybe a combination of the above?

    If you decommision the old server? Is the name/IP freed up?  I assume as the old and new are co-existing they have different names.

    If the new and old have the same RMS certificates, i.e. the certauthstore was imported prior to installing on the new server: When you decommision the server, could you put just a DNS record in place that effectively points the clients at the new server using the old address.

    Presumably the old update location was:

    \\<ServerA>\sophosupdate\

    and the RMS Parent address of the client's (hklm\software\sophos\messaging system\router\parentaddress) was:

    OLDIP,ServerA.domain.local,ServerA

    IP will be in the list if the management server had a static IP at install time.

    When ServerA is turned off, as long as the clients can resolve ServerA to be ServerB, then RMS will work (as long as the same certs are in place).  As would updating in theory.  At this point, you can send them new updating policies to point them to a new CID, and put a custom mrinit.conf in the CID to correct their RMS address to be ServerB's details so you no longer have to rely on the DNS 'hack'

    Another options, if these computers, when they return have to run a system startup script you could redirect them at that point, either by:

    1. Running setup.exe from the new CID.  Quite a heavy weight approach, certianly on bandwidth

    2. Re-init them using a script: http://www.sophos.com/en-us/support/knowledgebase/116737.aspx

    They key is regaining RMS management so they can be managed in SEC; at that point you can configure their update location.

    Regards,

    Jak

    :51188
Reply
  • 0

    HI,

    If the primary update location becomes unavailable the clients will fail over to the secondary of Sophos as you say.  They will continue to get updates which includes major versions eventually.  Essentially they will not be left unprotected.

    Do these curently "unmanaged" clients fail both to update and communicate over RMS, essentially are all channels are cut off?

    Are they essentially either locked away, out of the office for an unknown peiod and either won't return at all or possibly at some time in the future?

    Out of interest how did you migrate the computers from the old to new server?  

    1. Reprotect from the new SEC.
    2. Use a script to re-direct them.
    3. Use a custom mrinit.conf in the CID to redirect them?
    4. Maybe a combination of the above?

    If you decommision the old server? Is the name/IP freed up?  I assume as the old and new are co-existing they have different names.

    If the new and old have the same RMS certificates, i.e. the certauthstore was imported prior to installing on the new server: When you decommision the server, could you put just a DNS record in place that effectively points the clients at the new server using the old address.

    Presumably the old update location was:

    \\<ServerA>\sophosupdate\

    and the RMS Parent address of the client's (hklm\software\sophos\messaging system\router\parentaddress) was:

    OLDIP,ServerA.domain.local,ServerA

    IP will be in the list if the management server had a static IP at install time.

    When ServerA is turned off, as long as the clients can resolve ServerA to be ServerB, then RMS will work (as long as the same certs are in place).  As would updating in theory.  At this point, you can send them new updating policies to point them to a new CID, and put a custom mrinit.conf in the CID to correct their RMS address to be ServerB's details so you no longer have to rely on the DNS 'hack'

    Another options, if these computers, when they return have to run a system startup script you could redirect them at that point, either by:

    1. Running setup.exe from the new CID.  Quite a heavy weight approach, certianly on bandwidth

    2. Re-init them using a script: http://www.sophos.com/en-us/support/knowledgebase/116737.aspx

    They key is regaining RMS management so they can be managed in SEC; at that point you can configure their update location.

    Regards,

    Jak

    :51188
Children
No Data