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

Move clients to a new server

Eps

Hi All,

A company I look after has just had their SEC server fall over and die. All the 300 clients are still fine, but they are now server-less. The plan is to permanantly move the clients to a new server which is already named and will not be renamed as the naming convention is required for other software.

I have setup SEC on the other server and have my 300 clients imported from AD. My question now, is how can I get them all to connect to this new server and update from 7.x to 9. I have set update policys and everything. I just need to wrap my head around getting these clients to report to this server.

Any help is appreciated :)

:9929


This thread was automatically locked due to age.
  • 0

    Also, I was looking into the script here:

    I have a feeling that it wont work though.

    :9931
  • 0

    Hi,

    There are a couple of things here to consider.

    1. the certificates

    2. where the clients are pointing.

    If you install a new SEC afresh, it will have new certificates, therefore all the existing clients will not be able to talk to the new server.  If the new server has a different address, the clients will also fail to find the new server.  If the previous server had a static IP address, the clients will be currently configured to address it using, IP, failing that FQDN an failing that NetBIOS address.  Had it had a dynamic address all the clients would be looking for it using FQDN and then NetBIOS.

    So essentially we need to:
    1. Point the clients at the new server.

    2. Get the clients new certificates.


    Once the above has been done, you will have management of the machines again in SEC.  This will enable you to send policies to them and essentially point them at the new update locations etc.

    The way the clients were initially set up was as follows:

    1. setup.exe from the CID was run.

    2. setup.exe copied to the clients the file cac.pem and mrinit.conf.

    cac.pem is the certificate of the certification manager. Mrinit.conf contains, details that will be used to configure the client message router which will enable it to find the server.  It also has a few identity keys which play a part in the certification stage.  During the install of the RMS package these 2 files are used to configure the client.  Based on the 2 files and knowing where the server is the client is then able to get a certificate for the agent and the router.

    We essentially need to redo this step to point them at the new server and get the machines new certificates.  To do this you could.

    1. Reprotect all the clients, in affect this will run setup.exe again, which will copy down the new cac.pem and mrinit.conf from the new CID.  RMS will reinstall and install the new cac.pem and the router will be pointing at the new server when it reconfigures the machine with the new mrinit.conf.  

    2. Just copy down the new cac.pem and mrinit.conf, delete the existing certificates and run clientmrinit.exe (this is a little exe that gets called during the installation of RMS to transfer the cac.pem and mrinit.conf to the registry)

    I've put together a little HTA to help with point 2 as I belive this is a quicker solution and saves a lot of bandwidth:

    To use:

    1. Run the HTA.

    2. Locate the new cac.pem and mrinit.conf in the new CID and use those for the 2 fields.

    3. The other defaults should be ok.

    4. Generate a script.

    The resultant VBS script file should then be run on all clients to reconfigure them.  I would suggest trying it on a couple first and ensure they become visible back in SEC and manageable.  Once happy you could roll it out to the other machines.

    Good luck,

    Jak

    :9935
  • 0

    Thanks for the help Jak!

    On another note, the clients are also being upgraded from v7 > 9. Can I just tell sophos to reinstall on them all? if so can you point me n the right direction? Much appreciated. I am yet to decide between the two.

    :10121
  • 0
    Hi,
    You should be able to redeploy be it via:
    1. A protect from SEC (downsides being a bit slow and the clients need to be on and you need to be able to connect to them to create a scheduled task so a few dependencies)
    2. Running setup.exe from the central installation directory manually
    3. Running setup.exe from the central installation directory with switches to automate it
    The switches can be found on this article:
    http://www.sophos.com/support/knowledgebase/article/12570.html
    I find the easiest way to get the right command is to protect a test machine from SEC, monitor its scheduled tasks and as soon as the install job is created open the properties of it and grab the command line.  This will give you all the switches including an obfuscated username and password, which I find quicker than fiddling around with obfuscationutil.exe
    You might find it easy to deploy this command with a startup script.  There was one example here:
    http://www.sophos.com/support/knowledgebase/article/13090.html
    which details how to deploy with an AD statup script but not to keep running setup.exe by checking for the presence of Alsvc.exe.  Obviously you would need to change this check to a file that only exists on 9.5 otherwise it would not re-run.
    Checking for:
    C:\Program Files (x86)\Sophos\AutoUpdate\SingleGUIPlugin.dll
    C:\Program Files\Sophos\AutoUpdate\SingleGUIPlugin.dll
    might be one option taking a quick glance.  This only exists on a 9.5+ install.
    I would suggest only linking such a GPO to an OU of clients rather than all machines on the network initially until proven to work. :)
    Which ever way you do, be it the VBScript method or re-running setup.exe, I would suggest trying the method on 1 or 2 machines to ensure it works before rolling it out to others.
    Regards,
    Jak
    :10125
  • 0

    Eps,

    We use a central default Domain Policy script to install Sophos on all of our clients. If a new machine (or any machine for that matter) boots up and is not found to have Sophos client, it will auto install on first boot. We haven't had a single hitch. You can test it by putting this in a .bat for your Windows Startup script on an OU. If it works then it should work domain-wide. Like Jak said though, you would need to check for the ALsvc.exe. If it's already there, you'd have to omit those lines that check for it or either modify it.

    There is also a tool that you can use to obfuscate the domain admin username and password as well in the script so it's not in plaintext.

    @ECHO OFF
REM --- Check for an existing installation of Sophos AutoUpdate
if exist "C:\Program Files\Sophos\AutoUpdate\ALsvc.exe" goto _End
if exist "C:\Program Files (x86)\Sophos\AutoUpdate\ALSVC.exe" goto _End

REM --- Check for servers not to install to
if %COMPUTERNAME% == <COMPUTER YOU DON"T WANT SOPHOS ON HERE>goto _End
if %COMPUTERNAME% == <COMPUTER YOU DON"T WANT SOPHOS ON HERE> goto _End

REM --- Deploy to Windows 2000/XP/2003
\\SERVERNAME\SophosUpdate\CIDs\S000\SAVSCFXP\Setup.exe -updp "\\SERVERNAME\SophosUpdate\CIDs\S000\SAVSCFXP" -ouser "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" -opwd "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" -mng yes
REM --- End of the script
:_End

    P.S. - Make sure there is no word-wrapping being done on the script or it won't run correctly. The line which references your setup.exe file is one HUGE line.

    :10203
Unfiltered HTML