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

Update failing with Failed to install savxp: uninstalling an older product failed.

We have an endpoint that is failing on an update. In the past we've had our share of failed to install due to a previous version could not be installed, but this is the first time we've had this error message. I've had no luck in googling it.

 

If I try to uninstall the Sophos Endpoint Agent via the control panel, I get an error message saying that the I need to reboot the computer first. When I reboot and try again, I get the same error message. 

I've noticed in the Sophos anti-virus uninstall log, that there's a variable called  RebootYesNo set to yes. Are we able to set that to no? 

 

Would setting that to no, allow us to uninstall? 

 



This thread was automatically locked due to age.
  • Hello Navar Holmes,

    quite a lot of things, IMHO some of the conclusions (and suggested actions) aren't absolutely correct though.

    Windows Installer error
    most can easily be corrected. In some environments re-imaging is a cinch and SOP so learning to understand MSI logs might not be justified. Nevertheless there are mainly only a few different cases.

    • Installer fails with 1618 - Another Installation already in progress. Often the other installation is a Windows update or some other software install that starts right after boot but for whatever reason does not complete - neither successful nor with a failure. Not really the fault of the product that can't acquire the mutex. Killing the msiexec.exe that holds the mutex permits subsequent Installer runs, for a permanent solution it's necessary to identify the install that automatically commences but gets stuck. Again, this is not an issue of the Install that gets blocked.
    • An update/upgrade can't be performed because the required uninstall fails with 1612 - The installation source for this product is not available. The cached MSI (xxxxxx.msi) has "disappeared" from %windir%\Installer\. Management of the cached packages is the responsibility of the Installer, a software can request that a package that is no longer needed is removed (normally when it has been used for Uninstall and the uninstall succeeded). Either it's some obscure defect in the Installer that results in premature removal of a package - can't say - or someone/something else "cleaned" the cache. Normally an "old" package with the appropriate product-code is available and can be put in place of the missing one.
    • Failed CustomAction - required .INF files or the native.exe for driver replacement no longer in the Sophos Anti-Virus program directory. Might be caused by an interrupted install/uninstall. Copying the needed files form the AutoUpdate cache solves the problem. Similar for missing or corrupt registry keys (SSP is known to be affected).
    • For Endpoint Defense I have seen cases where AutoUpdate's cache for SED was corrupt. AutoUpdate could be more thorough when checking the cache consistency, but simply clearing the cache causes a redownload and results in a successful update. 

    You're perhaps correct that a shutdown at an unfortunate moment (i.e. when an install is in progress) might leave the computer in a broken state. This is, I assume, an Installer limitation (why do Windows Updates tell you to not turn off the computer?). Just because it's easy to correct the errors as stated above doesn't mean the software can do it - introspection only goes so far.

    Why and how should some software be able to deal with a polluted DNS?

    firewall - sorry, more than a few customers will complain if some software automatically fiddles with the (I assume you're talking about the local) firewall. The required settings are documented.

    UAC, common locations, run as administrator - AV software has to integrate with the system. It's not your average end-user application or some portable program.

    installed manually before the PC was joined to the domain - admittedly it should be noted that (if you intend to use AD Sync) the install should be performed after joining the domain.

    [after install] it is normal for it to say “Update Failed” - AFAIK the only component that causes a subsequent update failed is HitmanPro.Alert. For all other components the warning is in the log but updates don't fail and aren't shown as failed.

    the default Computer OU should have nothing to do with the endpoint installing or updating. And all AD Sync does w.r.t. updating is that an endpoint will receive the appropriate policy. Normally the endpoint should have a working updating policy after install - only if you install locally from a copy of the CID or a package and the computer appears in the Unassigned group it will not have a working policy. 

    nested security groups
    it is documented how the Sophos groups are populated and used. In a non-domain environment only users and built-in security principals can be added. In a domain environment it works with groups. But if your administrator is a local administrator that has been added after Sophos has been installed it is as you described. It's a Windows restriction.

    Christian