Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 14228 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

Help with redirecting endpoints from old SEC to new SEC

Bryan Adams

 Hi all

I'd love some advice on how we might be able to migrate the last few hundred clients from our legacy SEC to production version.

Legacy: Server 2003, SEC 5.3.0, SUM 1.5.8.11

Production: Server 2012R2, SEC 5.5.0, SUM 1.6.1.124

The majority were migrated over a period of time, using the VBScript MRreinit method, successfully. The remainder though, are:

  • Remote
  • NEVER on our internal networks - not even via VPN
  • We have no remote management methods, no remote control options (other than manually calling users one at a time and talking them through some steps), and no patch or script remote deployment methods on these particular machines - this is the real reason they haven't been migrated...

I have read a lot of posts and KBs, and I think the only method that might work is to somehow bend the rms / AutoUpdate mechanisms to redirect endpoints from the old SEC server to the new SEC server, eg:

https://community.sophos.com/products/endpoint-security-control/f/sophos-endpoint-software/1825/changing-parent-router-ip-address/2321#2321

and 

https://community.sophos.com/kb/en-us/14635

https://community.sophos.com/kb/en-us/13112

On our legacy SEC, there are 3x subscriptions, but, as far as I can tell they have all lapsed - the subscriptions status panel in UM details shows that each of the 3x subscriptions have last successful download recently, BUT under the Update Manager Status History listing it's a very long list of "Software update failed - error 80040404". I assume this is due to the subscription lapsed, but can someone please confirm? There are many popups to the effect that SEC isn't supported. I tried upgrading to 5.5.0, but not supported on S2003. It seems that 5.3.1 might be the latest version supported on S2003, but I can't find a link - it doesn't seem to be on the legacy versions download page anymore.

I picked upon the subscription used for the "Preview" version, since that has the least number of endpoints in Groups using it (none, actually) and also since I figured it would have the newest versions. Figured out this subscription saves into the following:

\\sophos\SophosUpdate\CIDs\S008

I took the mrinit.conf and cac.pem files from our Production SEC, placed into the following dir:

\\sophos\SophosUpdate\CIDs\S008\SAVSCFXP\rms

On the Legacy SEC, ran:

C:\Program Files\Sophos\Update Manager\ConfigCID.exe \\sophos\SophosUpdate\CIDs\S008\SAVSCFXP\

Output looks ok, it's mostly "Nothing to do" but it DID say:

Updating entry for \rms\cmanifest.dat

Updating entry for cmanifest.dat

Wrote a few catalog files, checked a bunch of checksums (all matched), then wrote into catalog file master.upd. Done.

At this point I should point out that our CID on the legacy SEC is published as a WEBCID, remaining clients connect remotely.

I then cautiously moved an endpoint machine into the correct group so that it would get the right modified subscription and clicked "Update computers now".

I saw the status change to "Awaiting policy transfer" as expected. Then it went to 'same as policy'. Still on the legacy SEC.

It then went offline (but didn't appear in the Production SEC), so I similarly moved into my test Group another handful, of ONLINE machines.

Some of these are still online after an hour or two, but NONE of them have moved into the production SEC.

Did I misunderstand this mechanism or process completely?

All advice gratefully received. And - if I'm attempting to do something completely impossible, then I'd rather be told instead of spending more time on it...

TIA



This thread was automatically locked due to age.
  • 0

    Hello Bryan Adams,

    *phew*, thanks for the detailed description. Nevertheless a few points aren't clear (or I might not have read carefully enough):
    no remote management methods vs. It then went offline
    so your remote endpoints can connect via RMS? For this you'd need either a message relay or allow connections to the RMS ports (8192, 8194) on the management server from "outside".
    And you have imported the certificates before installing your new server (so that the servers would have the same "identity")?

    It seems (but then I might misinterpret your post) that the reconfiguration works (that's why the endpoint goes offline) but the new server's RMS ports aren't externalized like for the old.

    Christian

  • 0

    Hello Bryan Adams,

    forgot to add - the SUM error is perhaps caused by the failed update to SUM 1.6.1.

    Christian

  • 0 in reply to QC

    Thanks for your reply Christian

    no remote management methods = I am talking about Windows here. ie we do not have any unattended remote control methods to be able to attach to the machine in question, install updates, install software, run scripts, edit registry etc. This is the sense in which these machines are isolated. The Sophos endpoint software is the ONLY point of reference that we have on these machines, and that Sophos endpoint appears to be working completely normally, as expected and communicating with SEC perfectly well.

    it then went offline = user (most likely) turned the machine off, but I have no way of knowing this. Could equally be back online right now, or maybe tomorrow - whenever the user turns the machine back on.  As at last night all of the machines I attempted to migrate were offline (expected if not in use) but this morning some of them are back online (also expected).

    ie I have no reason to think that ANY of the machines i attempted to move have "left" the legacy SEC and migrated to the production SEC.

    Yes, all our remote endpoints connect fine via RMS. Yes, the ports 8192 and 8194 are allowed through the firewall to the legacy SEC, but the remote clients connect to an HTTP:\\WebCID address - this is specified in the mrinit.conf for legacy endpoints.

    We have a mirrored setup (different published WebCID) to a different HTTP:\\WebCID for the production SEC, and firewall forwards ports 8192,8194 to the different LAN IP of the production SEC server.

    No, the certificates were NOT imported to the new SEC server when we set it up - we wanted to make a "clean start", but from your question here, perhaps this was a mistake?

    So, the servers have a different "identity" - is this my issue?

    Can I do anything with importing the Production SEC certificates into the legacy server?

    If it helps, both SEC servers are on the same network segment internally, and I can setup either to be able to write files to each other's CID shares (but I'm not sure what approach to take here).

    Thanks for your input tho!

    Cheers,

    Bryan

  • 0 in reply to QC

    I think you are correct.

    From my reading, the SUM cannot upgrade to 1.6.1 as Server 2003 is simply not supported. Further, the old version of SUM is no longer supported / cannot fetch updates anymore.

    Cheers,

    Bryan

  • +1 in reply to Bryan Adams

    Hello Bryan,

    the certificates were NOT imported
    so the servers have a different (cryptographical) identity. Once initialized RMS communicates only those (but also all) servers that present the same identity, furthermore it accepts only an mrinit.conf (for a possible reconfiguration) created by a server having the correct identity (BTW, mrinit.conf applies only to communication and management and does not contain the update location).
    To make the endpoints talk to a "different" server you must either reinstall or use the EMU. The challenge is to execute the .vbs on the endpoints - well, if your users have admin rights they could probably download it from somewhere and run it.

    Christian

  • 0 in reply to QC

    Thanks Christian

    Understood about the purpose and content of the mrinit.conf file.

    I was hoping that by changing that on the clients, they would start to communicate with the Production SEC, and then be managed by it so that I could push the update policy and they would then be fully migrated across.

    That makes sense about the certificates being different, therefore the clients are not able to connect. Our decision several years ago to start completely afresh was therefore unwise and perhaps ill-informed.

    Is there any way of changing the cryptographical identity of the legacy SEC, to "match" the cryptographical identity of the current production SEC?

    Or - would doing so simply cause all the clients currently managed by the legacy SEC to cease communicating with it? I guess the legacy SEC would (in the interim) need to have two cyrptographic identities / sets of certificates and I've no idea if that's possible...

    As you say, reinstall or use the EMU are the supported methods, but we have no easy means of getting that done, remotely. No, the users don't have admin rights, and we won't give it to them either. Looks like this is going to be a painstaking, manual process for someone :(

    I absolutely appreciate that help though - thanks very much :)

    Cheers,

    Bryan

Unfiltered HTML