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

    Hello Nordfol,

    a little bit of quite simplified background information first. Roughly speaking the Endpoint software has two distinct parts: Protection and management. The latter, RMS, is bound to a specific management server, its identity is generated when SEC is installed (it is possible to predefine the identity in order to facilitate migration) and recorded on the endpoints during initial install. Subsequently RMSNT can only be successfully downloaded from a server with the correct identity. If you have not (or could not) preserve the identity then any of the following methods should bring the endpoints to store and use the new identity:

    1. Protect computers from the console
    2. running setup.exe from the CID
    3. installing with a suitable package
    4. using the EMU

    Note that 4. just redirects the endpoints' management component, afterwards the new policies must be applied - only then will the endpoints also update from the new location. For the other methods the update directory should be either the location of setup.exe or the one specified as parameter (once RMS connects it should request the policy).

    a clean machine vs. Uninstalled vs. delete the Cache: Bad news - I could not come up with a scenario resulting in the issues you describe. Good news - it seems to be deterministic so there's a good chance that the cause can be found.
    Migration utility [ran] without success - have you checked the log (%windir%\Temp\SophosReinit.txt)?
    run my Sophos deplyoment package, Sophos is still pointing to the old Update Path - quite strange, the old location should no longer be there unless the package install did not succeed. How did you verify that the install was successful but the location is still old? If at some Point the Client appears in the new Enterprise Console this suggests it's working as it should. Please note that messaging could have some latency, nevertheless sooner or later there should be a "final" state (of success).

    Not knowing the cause I can't offer a solution. I'd run setup.exe (from the new CID) on an endpoint which has Sophos already installed. This should work but if it doesn't, the logs might give some insight. downloading the Updates from [the old server] - do I understand correctly that it is still running? Just as fileserver or SUM and SEC too?

    Christian   

     

     

       

  • 0 in reply to QC

    Hi Christian,

     

    QC said:
    Migration utility [ran] without success - have you checked the log (%windir%\Temp\SophosReinit.txt)?

    here is the log from SophosReinit.txt:

    04.10.2016 12:01:13 INFO:  Starting Script
    04.10.2016 12:01:13 INFO:  Options:
    04.10.2016 12:01:13 INFO:      blnForceRMSRun : Falsch
    04.10.2016 12:01:13 INFO:      blnForcePatchRun : Falsch
    04.10.2016 12:01:13 INFO:      blnReconfigurePatch : Falsch
    04.10.2016 12:01:13 INFO:      blnReconfigureRMS : Wahr
    04.10.2016 12:01:13 INFO:      strSECGroupPathOut :
    04.10.2016 12:01:13 INFO:      intPauseForServiceInSeconds : 10
    04.10.2016 12:01:13 INFO:      blnWriteCacToSAUCache : Wahr
    04.10.2016 12:01:13 INFO:      strLogPath : C:\windows\temp\SophosReInit.txt
    04.10.2016 12:01:13 INFO:      strReInitLog : C:\windows\temp
    04.10.2016 12:01:13 INFO:      strManagementServerPort :
    04.10.2016 12:01:13 INFO:      strManagementServer :
    04.10.2016 12:01:13 INFO:  --> Is64()
    04.10.2016 12:01:13 INFO:  Platform is 64-Bit
    04.10.2016 12:01:13 INFO:  <-- Is64()
    04.10.2016 12:01:13 INFO:  --> MarkerFound()
    04.10.2016 12:01:13 INFO:  Script not already run.
    04.10.2016 12:01:13 INFO:  <-- MarkerFound()
    04.10.2016 12:01:13 INFO:  --> ServerClassRouter()
    04.10.2016 12:01:13 ERROR:  Router is a server router, will exit
    04.10.2016 12:01:13 INFO:  <-- ServerClassRouter()
    04.10.2016 12:01:13 INFO:  End of script
    04.10.2016 12:01:13 INFO:  --> CloseLog() - No function exit logged

    QC said:
    - quite strange, the old location should no longer be there unless the package install did not succeed. How did you verify that the install was successful but the location is still old?

    I opened SAV and checked the Update Configuration, in the Update Configuration was the old Path of the old SEC. 

     

    QC said:
    [the old server] - do I understand correctly that it is still running? Just as fileserver or SUM and SEC too?

    SUM and SEC installed.

    QC said:
    Not knowing the cause I can't offer a solution. I'd run setup.exe (from the new CID) on an endpoint which has Sophos already installed. This should work but if it doesn't, the logs might give some insight.

    I get an error "Errorcode 5: ...\CIDs\S000\SAVSCFXP\cac.pem couldn't be copied to C:\Program Files (x86)\Sophos\Remote Management System\cac.pem

     

    Best Regards

    Nordfol

     

     

  • 0 in reply to Nordfol

    Hello Nordfol,

    SophosReinit.txt
    claims that the machine is either a (the) management server or a message relay. Looking at an old SophosReInit it seems that the script insists on the exact value 10 being present in ConnectionCache. Otherwise it's either a "server" or RMS might not have worked anyway.

    checked the Update Configuration
    how else can you tell that the package installation succeeded or failed? Naturally if it flopped the old values won't get cleared.

    Errorcode 5
    Access denied if I'm not mistaken (and I think the write fails). You were running it as an administrator, weren't you? Did you use the GUI or setup.exe with parameters?

    Christian

  • 0 in reply to QC

    QC said:
    claims that the machine is either a (the) management server or a message relay. Looking at an old SophosReInit it seems that the script insists on the exact value 10 being present in ConnectionCache. Otherwise it's either a "server" or RMS might not have worked anyway.

     

    I wanted to check ReportData.xml from the RMS to verify the router type of the client is 'endpoint'. I found out that on the Clients with the old Update server, Sophos Remote Host is not installed! So there is no *.xml. I think that is the reason why the *.vbs is not working at all.

     

    QC said:
    Access denied if I'm not mistaken (and I think the write fails). You were running it as an administrator, weren't you? Did you use the GUI or setup.exe with parameters?

     

     

    I mounted the SophosUpdate Path as network drive with the SophosUpdateMgr credentials and did run the setup.exe as admin. After that I entered the SophosUpdateMgr credentials as you can see in the image.

     

    QC said:
    how else can you tell that the package installation succeeded or failed? Naturally if it flopped the old values won't get cleared.

     

    I didn't know that Sophos had some kind of fall back, if the new Sophos package failed to install. If I understand you correctly, it is normal that even if you uninstalled Sophos completed before and run your new sophos deployment package and the package install fails, Sophos restores the old previously uninstalled Sophos?? This sounds very weird to me.

     

    Looking forward to hear from you.

     

    Best regards

    Nordfol

Reply
  • 0 in reply to QC

    QC said:
    claims that the machine is either a (the) management server or a message relay. Looking at an old SophosReInit it seems that the script insists on the exact value 10 being present in ConnectionCache. Otherwise it's either a "server" or RMS might not have worked anyway.

     

    I wanted to check ReportData.xml from the RMS to verify the router type of the client is 'endpoint'. I found out that on the Clients with the old Update server, Sophos Remote Host is not installed! So there is no *.xml. I think that is the reason why the *.vbs is not working at all.

     

    QC said:
    Access denied if I'm not mistaken (and I think the write fails). You were running it as an administrator, weren't you? Did you use the GUI or setup.exe with parameters?

     

     

    I mounted the SophosUpdate Path as network drive with the SophosUpdateMgr credentials and did run the setup.exe as admin. After that I entered the SophosUpdateMgr credentials as you can see in the image.

     

    QC said:
    how else can you tell that the package installation succeeded or failed? Naturally if it flopped the old values won't get cleared.

     

    I didn't know that Sophos had some kind of fall back, if the new Sophos package failed to install. If I understand you correctly, it is normal that even if you uninstalled Sophos completed before and run your new sophos deployment package and the package install fails, Sophos restores the old previously uninstalled Sophos?? This sounds very weird to me.

     

    Looking forward to hear from you.

     

    Best regards

    Nordfol

Children
  • 0 in reply to Nordfol

    Hello Nordfol,

    if RMS is not installed the ReInit, naturally, fails. But then - how did you manage your endpoints without RMS? BTW, the XML file is a report, nothing more. It's not consulted by ReInit.

    setup.exe as admin
    Looks ok, wonder if the Access denied is contrary to my initial assumption for the source    .You access the share non-elevated, setup.exe runs elevated and needs to access this share. Depending on the Windows security settings it is necessary to re-enter the credentials (note: the credentials you enter in the GUI are for AutoUpdate's settings, not for the installation bootstrapper) and perhaps you don't get a prompt at all. Process Monitor is one way to determine the path which encounters the error.

    Sophos restores
    no. Definitely not after an uninstall. MSI failures are rolled back. And there are no persistent changes when the bootstrapper setup.exe (whether running from the CID or a package) errors out early.Thus working installation shouldn't get damaged by a reinstall, whether successful or gracefully failing. There's no secret recovery store, wormhole, or whatever which after an uninstall preserves settings for a potential new install.

    Christian

  • 0 in reply to QC

    Hey guys,

    QC said:
    You access the share non-elevated, setup.exe runs elevated and needs to access this share. Depending on the Windows security settings it is necessary to re-enter the credentials (note: the credentials you enter in the GUI are for AutoUpdate's settings, not for the installation bootstrapper) and perhaps you don't get a prompt at all. Process Monitor is one way to determine the path which encounters the error.

    I found out that the *.vbs script for migrating to a new enterprise console was still open on my admin client. The *.vbs script did lock the access to cac.pem and mrinit.conf. Thats the reason why the error message 'access denied' for cac.pem appeared.

    As desired I did run the setup.exe as admin with SophosUpdateMgr credentials. Sophos gets installed properly with the right Update Path of the new Server. Updating after that works also (no invalid custom manifest error because it only access the new Update Server).

     

    So still I need a solution to deploy Sophos with my deployment package.

    Something has to be wrong with my Sophos deployment package.

    Here a Screenshot of the deplyoment package:

     

     

    If I run the package, Sophos first uninstalls the old Sophos, after that it installs the AutoUpdater which appears as a system tray icon. I quickly click on that icon and opened the AutoUpdater Properties which you can see in the Screenshot. And in Update-Path is the old Update Path :(

     

     

    If I run the setup.exe directly from the UNC-Path, in the screenshot above is the correct Update Path and not the old as in the deployment package.

     

    I hope you understand me ;)

     

    Best regards

    Nordfol

  • 0 in reply to Nordfol

    I have one suggestion - let the primary update location be UNC to start off and then try an installation using the package.

    After the machine is green in SEC, change the policy to the HTTP location? 

  • 0 in reply to Vikas

    Vikas said:
    I have one suggestion - let the primary update location be UNC to start off and then try an installation using the package.

     

    I tried a deployment package with the UNC Path for the new SEC and still at the installation process the old update path stays.

    Is there any log of the installation which I can check why it is keeping the old Update Path of the old Sophos even if I uninstalled it?

  • 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