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

Server to Server Migration Issues

DC_IT_Manager

Have about 100 endpoints.  Performed a migration of Console and DB from Windows 2003 to Windows 2008R2 and Sql 2005 to Sql 2008R2.  

While not perfect, the migration took and the console on the new machine looks just like the old machine with all exclusions in place.

Got the dreaded 1326 error and knew it was some combination of sophosupd username and password issues and proper sharing.  Took about a day and a half to resolve that.

The good:  I have gone into the console and chosen 2 servers and 2 workstations and performed a "protect computers" on them.  The endpoints properly update and can attach to the new primary server and receive files.

The bad:  All of the endpoints in the console have red x's on them, except for the update server itself which is green.  If I run "protect" on them, they show up with a brown down arrow icon for about 15 minutes.  The endpoints do receive the new package, but it appears to that do not report back to the console.  Ultimately, the endpoint icons go from brown back to red.  And while the endpoint update policy does show the proper primary server, it doesn't show "Sophos" as the secondary location - which is how it's set in the main policy.

***If I look at the properties of the endpoints on the console, the details still report that the primary update server is the old 2003 server, not the new 2008R2 server - even though the endpoints are finally talking to the new 2008R2 server.

I feel that if I can just get the endpoints to properly talk to the new console location, I can push out the protect command to the company.  

Suggestions?

Adam in DC

:34125


This thread was automatically locked due to age.
  • 0

    HI,

    Have you tried creating a VBScript file using the HTA here:

    http://www.sophos.com/en-us/support/knowledgebase/116737.aspx

    to redirect the endpoint at the new management server?  

    It would be interesting to know if that works at least on a couple of clients and therefore if it would be an option.

    Regards,

    Jak

    :34127
  • 0

    That's probably not an area I'd want to explore right now - as I think that's really a method for deployment in properly working systems - so in that respect it's interesting.  However, since my system is NOT properly working, deployment methods are not my priority at this time.  Fixing the problem is.

    I'd like to at least get one end point outside of the server itself to properly talk to the server.  They can download the updates, but the console still doesn't see the current workstation...just the one from before the server switch.

    It looks to me that all endpoints, even those few I've updated from the new server, still see their primary update server as the old one - where I've already uninstalled the console and DB.

    I'm not sure if this is a registry issue on the new server or a DB issue on the new server or what.  I tried holding for 20 minutes with tech support with no pickup.  I'm using Twitter.  I just did another 10 minute hold on tech support.  And I'm using this board, but little help.

    :34129
  • 0

    Hi,

    If the problem is with RMS, I.e. the communication system, as soon as they start to message again you can send them a policy to redirect them where required.

    The first thing I would check is that the server and client are using the same certificates/identity keys.

    As a quick test the following should align between server and client:

    Server:

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore\RouterKey

    Client:

    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Messaging System\CertificationIdentityKeys\CertificationIdentityKey

    Server:

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore\ManagedAppKey

    Client:

    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Remote Management System\CertificationIdentityKeys\ManagedApplication

    Server:

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore\DelegatedManagerKey

    Client:

    HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\Remote Management System\ManagementAgent\Private\CertificationIdentityKey

    Server:

    HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Certification Manager\CertAuthStore\cac

    Client:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\cac

    Are they the same on the server (you'll have to open the value to see the text) as on a client which isn't talking?

    The VBS file just re-initialises RMS on the client to ensure that it has the same certificates as the server, it can be used for a migration or just to repair a client that's stopped messaging.

    Regards,

    Jak

    :34135
  • 0

    Just heard back from support and they recommended......the same article you did.  It looks like I didn't read far enough down to see exactly what this tool does.

    Will give it a shot and see.

    :34219
  • 0

    Ran the VBS per the article.  No change.  I did not do the reg check like you suggested, so will try that next and re-run the vbs file (I'll probably have to adjust it to "force" since i've run it once already.  yes?

    :34223
  • 0

    Hi,

    Either that or delete the "marker" keys under:

    HKLM\Software\[wow6432node]\Sophos\

    I.e.

    ReInitRMSMarker

    ReInitPatchMarker

    These are the keys it checks to see if it should run again.

    If you run the task, ensure it's as an admin, then you could post the log (\windows\temp\sophosreinit.txt) here:

    Also worth checking that the keys metnioned before are the same.  You should also note that the 3 "identity keys" are the same in the mrinit.conf file in the ditribution points (CIDs). 

    Regards,

    Jak

    :34229