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

Migrating EC v4 to new server - updates now fail

Good evening,

Recently moved an installation of Sophos EC  v4 from our old server to the new live server. Followed the Sophos Migration guide to the letter (no number just dated June 2010).

Initially tried to move everything from v4 to v4.5 but that did not work. Doh should have engaged brain first, stupid.

Then installed v4.0 on the new server and the migration seemed to go ok. EC started up fine and all the computers were present.

Selected Update Manager and tried to force an update. This went away for a while and then failed. Might have a handle on this as I realised I did not clean out the Sophos Update share between version (v4.5 and v4.0) so I have a plan on how to solve that issues.

Went to a client and tried to get it to update it failed with 'Could not connect to server'. From memory its running EP 9.0

On checking the configuration of the update I noticed it uses SophosUpdateMgr as the user with a hidden password. Now my understanding is that the EC will create this user with a random password when it is installed if it does not already exist. Does this then get changes when I restore the registry / certificates / database  or do I have to invade the AD on the old server to find the password and then set it on the new and run the Sophos 'hide' it etc.?

If its not that can anyone please provide a pointer to the probable cause of the problem.

Regards

Gary

:5531


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

    My understanding is that the passwords used by the Sophos Management Service are stored in the Windows Private store which is essentially the registry on the machine where the management service runs.

    When you run ExportPrivateStore.exe as part of the server migration, you are exporting these to XML format, so you can move them to another machine.  The same account that wrote them to the private store needs to be used to export them.  As the Sophos Management Service wrote them and runs as System, you need to run ExportPrivateStore.exe as System and for this reasons psexec is suggested as it is an easy way of running as this user.  This is also true when importing them, you need to import them as System on the new machine so the Management Service can read them back out.

    They seem to be a pair, a key and a value, the password being the value and the key being a unique identifier.  This unique identifier string can be found in the policies table in the XML.  So I assume when the Management Service encounters this unique identifier and needs to convert it into the password it makes a lookup to the private store to obtain the password.

    Under the Management Service registry keys you can see the "private" key which lists all these values.  You can see the "Begin" and "End" secure ticket markers.  

    I assume these are the same on both machines and this stage of the migration all went ok?

    To check, if you still have the old server, I would suggest running:

    ExportPrivateStore -s -e old.xml

    and then run:

    ExportPrivateStore -s -e new.xml

    on the new server and compare the outputs, this would at least be a double check that this stage went to plan.  Remembering to run the commands as system.

    I hope this gives you something to check in this area.

    Thanks,

    Jak

    :5534
Reply
  • Hi,

    My understanding is that the passwords used by the Sophos Management Service are stored in the Windows Private store which is essentially the registry on the machine where the management service runs.

    When you run ExportPrivateStore.exe as part of the server migration, you are exporting these to XML format, so you can move them to another machine.  The same account that wrote them to the private store needs to be used to export them.  As the Sophos Management Service wrote them and runs as System, you need to run ExportPrivateStore.exe as System and for this reasons psexec is suggested as it is an easy way of running as this user.  This is also true when importing them, you need to import them as System on the new machine so the Management Service can read them back out.

    They seem to be a pair, a key and a value, the password being the value and the key being a unique identifier.  This unique identifier string can be found in the policies table in the XML.  So I assume when the Management Service encounters this unique identifier and needs to convert it into the password it makes a lookup to the private store to obtain the password.

    Under the Management Service registry keys you can see the "private" key which lists all these values.  You can see the "Begin" and "End" secure ticket markers.  

    I assume these are the same on both machines and this stage of the migration all went ok?

    To check, if you still have the old server, I would suggest running:

    ExportPrivateStore -s -e old.xml

    and then run:

    ExportPrivateStore -s -e new.xml

    on the new server and compare the outputs, this would at least be a double check that this stage went to plan.  Remembering to run the commands as system.

    I hope this gives you something to check in this area.

    Thanks,

    Jak

    :5534
Children
No Data