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

Unable to update to version 5.4.1 error code 1603

I came across this error whilst trying to update the sophos enterprise console from version 5.4.0 to 5.4.1 with the sophos DB installed on an SQL Cluster.

When running the installer i got an error with no initial indication as to what was causing the problem.

In the logs I checked for "Return value 3" then above this i found this in the logs.

CheckForUnsupportedEndpoints: Checking MAC computers...
CheckForUnsupportedEndpoints: RMS found with unsupported version: 0.0.0. The threshold is: 9.4.0
CheckForUnsupportedEndpoints: Checking UNIX computers...
CheckForUnsupportedEndpoints: Checking LINUX computers...
CheckForUnsupportedEndpoints: RMS found with unsupported version: 0.0.0. The threshold is: 9.12.3
CheckForUnsupportedEndpoints: Checking vSHIELD computers...
CheckForUnsupportedEndpoints: Error 0x2: You have managed computers running a version of RMS unsupported by Enterprise Console. Aborting installation.
CustomAction CheckForUnsupportedEndpoints returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 17:05:41: CheckForUnsupportedEndpoints. Return value 3.
Action ended 17:05:41: INSTALL. Return value 3.

I had previously removed an Linux machine as it wasn't supported as per this KB https://community.sophos.com/kb/en-us/124873 

in the console i have sorted all of the machines by the AV version and everything is correct! all the versions present in the console are supported by the new 5.4.1 installation with the new RMS!



This thread was automatically locked due to age.
  • The fix for this was a bit strange, as i checked the Sophos540 DB that it referred to in the log and checked the following view dbo.Computers 

    I then exported this to excel to check the Column SAVVersion to see if i could find the version 0.0.0. and to my surprise there was nothing there, all the versions that were in the list were supported by the 5.4.1 installation!

    so i decided to clean up the DB as brutally as possible, i made sure i had a clean backup so i could restore the DB if i broke anything, then i went into the console and removed every PC / server that hadn't communicated with the sophos server in the last 2 weeks.

    then I started the installation again and it went through!

    I thought i would post this so if anyone has a similar problem they know what to try.

  • Hello SimonConstable,

    thanks for sharing this!
    To calrify - you attempted to upgrade the remote database by running setup.exe from the sec_541 folder, the prerequisite checker did not complain but subsequently the .msi failed? Did you have managed computers that did not display a version - a combination of SAVInstalled=1 and SAVVersion=NULL is possible AFAICS?

    Christian

  • Hi Christian, 

    There is no need to update the database from version 5.4.0, i only mentioned that it was a remote DB as the upgrade process is different. (normally i need to copy the sec_541 to the SQL server to run the commands manually as i cant install any other application on the SQL servers)

    When i started the update setup.exe via the sec_541 folder on the first attempt last month it did warn me that there were installations that were not supported, i then removed sophos from these old devices.

    then yesterday i started the upgrade again, but this time all the prerequisite checks where OK, i even tried to run the update with the console open so i would see the screen with all the checks and the warnings, everything was green.

    but then the installation would start, i could see in the log that it called the  Server64msi in the bootstrapper log

    16.01.2017 17:05:40, INFO : About to install Server64.msi
    16.01.2017 17:05:41, INFO : Processing INSTALLMESSAGE_TERMINATE message from MSI
    16.01.2017 17:05:41, INFO : Installation of Server64.msi failed with error code: 1603

    so i then looked in the Server64msi log to find out what was causing the issue.

    I did open a ticket but i found the solution before the support tech as they refereed me to the KB in regards to the unsupported RMS, which i already mentioned in the ticket that this isn't the case.

     

    In regards to the the version = NULL this is still the case in the DB as the Sophos server detects the cluster names from several services in AD and they dont have sophos installed but the hosts do.

    as soon as i cleared all the other objects several were put back into the DB with the value of NULL in the SAVVersion, but I was still able to install the update.

    Im guessing that there must have been an entry in the DB where SAVInstalled=1 and SAVVersion=Null.

     

    I hope this clears that up a bit.

  • Thanks, Simon,

    no need to update the database
    should have thought of this.

    SAVversion = NULL
    from the wording of the message it seems that it considers only managed computers, these likely don't have SAVInstalled=1. Hmm .. a cursory inspection of the Custom Action suggests that it selects the SAVVersion from the database for Managed computers with a certain OSVersion, treating VShield as special case. Thus SAVInstalled doesn't seem to come into play. But it seems it doesn't handle NULL correctly or at least the article is missing this information.

     

    Something completely different: SAV 10.6.4 supports enhanced exclusions (e.g. c:\foo\**\bar) - does the SEC 5.4.1 GUI permit these in the AV policy?

    Christian

  • Hello Simon (and all others),

    with the sophos DB installed on an SQL Cluster
    you have been lucky that the database is remote. I've decided not to wait any longer and deliberately left the managed endpoints that didn't show a SAVVersion visible (i.e. undeleted). The bootstrapper let me proceed, the ServerMSI failed the way you've shown. Upon deleting the offending endpoints and re-running setup I ran into an early fatal error Enterprise Console installer has detected different versions of the components installed. Rats! Rats? Not really though - the database component had already been upgraded to 5.4.1, uninstalling it does no harm at all and takes literally only seconds. The subsequent upgrade went smoothly.

    Christian