Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 16 replies
  • Subscribers 3 subscribers
  • Views 34140 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

Changeing Clients from an old Update Server to a new one

Nordfol

Hello,

we are trying to change the Sophos Update Server to a new one without success.
We have the problem that the clients are Updating from an Old Enterprise Console which we can't access anymore. I did create a Sophos Deplyoment Package which points to our new Enterprise Console.
On a clean machine which had never Sophos installed before, the Deployment package is working without difficulty and finally Sophos is properly installed.
On most of our Clients Sophos is installed and points to the old Enterprise Console. If I run my Sophos deplyoment package, Sophos is still pointing to the old Update Path of the old Enterprise Console and is downloading the Updates from there. Curiously at some Point the Client appears in the new Enterprise Console and I can move it to our "Clients" Folder. After that the Client awaits the new policy with the Update Path of the new Enterprise Console.
After a while the Client applies the new policy and has the new Update Path. Sadly in the Sophos Auto Update Cache directory are still the files from the old Update Server. If the Client starts Updating and contacting the new Server, the following Error appears in the Console: Failed to install RMSNT: Package authentication [0x0000007] and on the Client

CheckCustomManifest: invalid package:invalid custom manifest: [VE_BADCERT]: 7
ALUpdate(Install.Failure): RMSNT

I think the problem is, that the Client has still the old manifest from the old Enterprise Console and can't update from the new Enterprise Console with the old manifest file.
If I delete the Cache everything is fine and the Client downloads all files from the new Enterprise Console but this is not a practicable solution for our environment.

What I tried so far:
1. Uninstalled all Sophos components in the right order following the KB-Article, rebooted the system, erased all still existing files/folders from Sophos, erased all regestry entries from Sophos and started my Deployment package. When the Sophos AutoUpdater is installed I checked the Update Path and sadly the old Update Path appears and the Update starts to download the remaining components from the old server including the old manifest file which leads to the error above. I don't have any clue where the AutoUpdater gets the old Update Path because I erased all possible places where it might be?!

2. I did run the Sophos endpoint Migration utility described in KB-Article 116737 without success. I think even if it would work, I would have the same Problem with the existing old Update Cache.


All in all it would be nice to know from where and why the AutoUpdater gets the old Server Path although I erased all possible location.

Best regards
Nordfol



This thread was automatically locked due to age.
  • 0 in reply to Nordfol

    Hello Nordfol (and thanks for your faith in me,  [:)]),

    the DP looks ok, with this configuration setup.exe should set the Primary to the HTTP path. There should be a Sophos ES setup.log - guess in your user's %TEMP%. If the AutoUpdate install fails and is rolled back this might explain the symptoms you observer (why the install could fail when the interactive setup works I can't say).

    Christian

  • 0 in reply to QC

    If you want you can check the log file at: http://pastebin.com/fERtxFbz

     

    I did not find anything unusual in the log. Even the new Update path is in the log file included.

     

    I dont get it, why the installer is still using the old path?!

  • 0 in reply to Nordfol

    Hello Nordfol,

    agreed, everything's fine here. So ...  could you please also post the ALUpdate..., ALSvc... and ALMon.sess1... logs? Should be the oldest or only ones in \AutoUpdate\logs.

    Christian

  • 0 in reply to QC

    alc.log --> http://pastebin.com/RW6cY8FF

    ALmon*.log --> http://pastebin.com/VeSvy5pJ

    ALSvc*.log --> http://pastebin.com/zWDKbaKp

    ALUpdate*.log --> http://pastebin.com/0AxidqgA

     

    For me only the alc.log and ALmon*.log is interesting. In both log files, I can't find my new Update Path which the deployment package contains.
    It keeps using the old Update Path, but I don't know where the Setup is getting this information from ....

  • +1 in reply to Nordfol

    Hello Nordfol,

    at least your old CID contains an XML configuration file for AutoUpdate (sauconf.xml). But no, even if if an incorrect XML exists in your new CID it should cause the same behaviour with an interactive and a package install. And you seem to have location roaming enabled. No explanation but perhaps this rings a bell ...

    Christian

  • 0 in reply to QC

    Hi Christian,

     

    thanks for the hint with the .xml file. I built a deployment package manually and not with the deplyoment tool, which Sophos recommends.

    Now if I run my manually created Sophos package the AutoUpdater does not use the old Update Path of the old Server, instead it uses the Temp Path in which the archive unzipped the files to. After that my policy updates the path to the real unc and http path.

     

    Still I do not know why the old update path stays in the "system" if you use a package that was created with the GUI tool and not manually.

    But at this point I am satisified with the manually created package and can deploy all my clients.

     

    Thanks for the fast help of you guys!

     

    Best regards

    Nordfol

Unfiltered HTML