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

Migrate/move SEC server from 2003R2 to 2012R2

Hi

Been doing a lot of reading of KB articles and on these boards trying to find the correct way to go about migrating/moving our SEC server but can't seem to find exactly what I need.  So thought I would ask directly, our setup is

5.3 SEC - 2003R2

DB is on separate SQL cluster - SQL 2008r2

need to move just the SEC part to 2012R2

So from what I've read as long as I take the reg key

HKLM\SOFTWARE\Sophos\Certification Manager\CertAuthStore\

to the new server prior to installing SEC everything should function with regard to Endpoints being able to authenticate with the new server. New reg key will be HKLM\SOFTWARE\[WOW6432Node]\Sophos\Certification Manager\CertAuthStore\

My initial thought process was to keep the same IP, HOSTNAME for the new server, but I see from the Sophos KB this isn't supported, I thought this would avoid, having to reprotect all the Endpoints.  We have 2500 Endpoints in 4 Countries and spread over 20 sites, probably not an idea setup but its kind of just grown that way, so the thought of having to reprotect them either from the console or via a script is less than appealing.

We use a http:// address and a DNS alias for our update policies and I noticed in a few threads the metion of using a DNS alias for the Router RMS also, didn't know if this was leading me down the wrong path or not

What is the best approach to take? New server - new hostname/ip? or new server - old hostname/ip?

Regards

Jon W

:57326


This thread was automatically locked due to age.
Parents
  • Hello Jon,

    there's more than one way to skin a cat. I've never followed the migration guide to the letter (but always kept the CertAuthStore). The guide describes one scenario, guess it's the most common for "basic" installs (IIRC there was a time when it was assumed that you use the same name). Describing all the variants would likely be more confusing than helpful.

    I hope the following is (still) correct:

    If there is already an (imported, remote or existing local) database when the rest of SEC is installed the new server is "put in place" of the old one in the database (I' would have assumed that the computer with ID=1 is considered the management server but I have one instance where it has ID=2) ... it looks like actually the check is done every time the management service starts (with additional consistency checks when a console is started). Anyway a changed name is apparently the general case with the special case same name not being an exception.

    I forgot to mention the SecureStore ... I've always entered credentials manually ...

    Christian

    :57340
Reply
  • Hello Jon,

    there's more than one way to skin a cat. I've never followed the migration guide to the letter (but always kept the CertAuthStore). The guide describes one scenario, guess it's the most common for "basic" installs (IIRC there was a time when it was assumed that you use the same name). Describing all the variants would likely be more confusing than helpful.

    I hope the following is (still) correct:

    If there is already an (imported, remote or existing local) database when the rest of SEC is installed the new server is "put in place" of the old one in the database (I' would have assumed that the computer with ID=1 is considered the management server but I have one instance where it has ID=2) ... it looks like actually the check is done every time the management service starts (with additional consistency checks when a console is started). Anyway a changed name is apparently the general case with the special case same name not being an exception.

    I forgot to mention the SecureStore ... I've always entered credentials manually ...

    Christian

    :57340
Children
No Data