Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 8142 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.
  • 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
  • 0
    Do these curently "unmanaged" clients fail both to update and communicate over RMS, essentially are all channels are cut off?

    No- they are updating and communicating just fine over RMS now with the old server.

    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?

    They are computers that are difficult to identify and over which we have no administrative rights or remote administration capability.  Some may be personally-owned computers. In theory, if we had the manpower we could hunt down individual IP addresses and try to contact the users to work with them directly, but this would be a highly labor intensive effort.  We have about 400 endpoints still on the old server.  About 50/50 Windows and Mac.  The migration started over a year ago.

    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?

    The new server was set up with a separate name/IP as a completely new system.  On the Windows endpoints we used our remote admin tools to run a SophosReInit script.  On Macs, we used our remote admin tools to uninstall Sophos and re-install using an installer from the new server.

    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.

    Yes the name will be freed up.  We had to use a new name for the new server becuase there were other services running on the Sophos server that required that name after the new Sophos server was brought up.

    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.

    I'll look into this, but I'm pretty sure the new server has a different RMS certificate. It was set up and configured from scratch and nothing was moved from the old server to the new.

    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

    Yes - the kb article describes the process we used to create the Windows migration script.  We're posting info for users to manually download and run the script, but the challenge is communicating with the people who need to do this.  

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

    Regards,

    Jak

    Thanks for this info.  I'll run it by our team to see if there is anything you mention that we overlooked!

    :51196
  • 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