Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 6393 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

software update failed

Fiona Johnson

Hello

 

We have two update managers and both are reporting as Software update failed. I only noticed today but it seems to be there for a few weeks. When i check the log viewer it gives the following

 

06/02/2020 16:22:28 Error Sophos Update Manager failed to update from product release 'Payload-SDDM' with version 84.18 as the installer returned an error: 1603

 

In the %windir%temp% i find the following error messages in the MSI logs

 

Property(S): IS_NET_API_LOGON_USERNAME_TOKEN = SophosUpdateMgr
Property(S): InstallShieldTempProp = 0
MSI (s) (68:E8) [15:24:09:153]: Note: 1: 1729
MSI (s) (68:E8) [15:24:09:153]: Product: Sophos Update Manager -- Configuration failed.

MSI (s) (68:E8) [15:24:09:153]: Windows Installer reconfigured the product. Product Name: Sophos Update Manager. Product Version: 1.7.1.19. Product Language: 1033. Manufacturer: Sophos Limited. Reconfiguration success or error status: 1603.

MSI (s) (68:E8) [15:24:09:153]: Closing MSIHANDLE (1) of type 790542 for thread 3304
MSI (s) (68:E8) [15:24:09:185]: Deferring clean up of packages/files, if any exist
MSI (s) (68:E8) [15:24:09:185]: MainEngineThread is returning 1603
MSI (s) (68:0C) [15:24:09:185]: No System Restore sequence number for this installation.
=== Logging stopped: 06/02/2020 15:24:09 ===
MSI (s) (68:0C) [15:24:09:185]: User policy value 'DisableRollback' is 0
MSI (s) (68:0C) [15:24:09:185]: Machine policy value 'DisableRollback' is 0
MSI (s) (68:0C) [15:24:09:185]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (68:0C) [15:24:09:185]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (68:0C) [15:24:09:185]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (68:0C) [15:24:09:185]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (68:0C) [15:24:09:185]: Destroying RemoteAPI object.
MSI (s) (68:74) [15:24:09:185]: Custom Action Manager thread ending.
MSI (c) (D8:E4) [15:24:09:185]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (D8:E4) [15:24:09:185]: MainEngineThread is returning 1603
=== Verbose logging stopped: 06/02/2020 15:24:09 ===

 

I checked and the latest ides are there from today. Does anyone have any idea what could be causing this issue?

 

 

Thanks



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

    Hello Fiona Johnson,

    I re-read my post, I do think it is clear but perhaps it isn't. And one more question (stupid as it might seem)

    1. two SUMs (of several) managed by the same SEC server?
    2. the shares in the error message are \\SOPHOSSRV5\SophosUpdate and \\SOPHOSSRV6\SophosUpdate respectively?
    3. the servers do not cross-deploy (i.e. SOPHOSSRV5 doesn't write to SOPHOSSRV6 and v.v. - I vaguely remember a thread where such a configuration was mentioned)?

    Christian

  • 0 in reply to QC

    Hi Stephen,

     

    We only have 2 SUMS. They run on seperate sophos enterprise console servers and they do not cross deploy.

     

    The two shares are as you mentioned

    \SOPHOSSRV5\SophosUpdate and \\SOPHOSSRV6\SophosUpdate

     

    We have 3 seperate endpoint management servers which we use just to have our clients report into but all clients point to these two update servers as their primary update source.   Both of these SUM on both servers are reporting this issue.

     

    I have tried a number of steps so far, including the ones mentioned for permissions on the share. I have checked the registry setting mentioned to make sure it is the right account and password which is being used but so far nothing has worked, they both continue to report a failure to update software.

     

  • 0 in reply to Fiona Johnson

    Hello Fiona Johnson,

    thanks. As far as I can see from a SUM 1.7.0 MSI log (late October 2019) there haven't been changes in the installer logic lately.

    The SelfUpdater logs (C:\ProgramData\Sophos\Update Manager\Logs\SUMSelfUpdaterLog.txt) should tell when this started to fail, and whether at the same time for both servers (BTW - the SUM on the third management server doesn't have this issue?). 
    The Failed to load the security descriptor for \\SOPHOSSRV5\SophosUpdate might indicate a corrupted ACL - OTOH it'd be a strange coincidence that it just happened on two servers. Can PowerShell display the ACL?

    Get-Acl \\SOPHOSSRV5\SophosUpdate|Format-List

    Christian

  • 0 in reply to QC

    Hello Christian,

    Unfortunately i cannot run that command on this box.

     

    I am not reallly sure what i am searching for in the self updater file but from what i can see i was getting successful messages

    topTheService finished at 2019-12-04 11:16:34Z
    StopTheLogViewerIfRunning started at 2019-12-04 11:16:34Z
    StopTheLogViewerIfRunning finished at 2019-12-04 11:16:34Z
    RunTheInstaller started at 2019-12-04 11:16:34Z
    SUM version before upgrade: 1.7.1.19
    Running the installer...
    About to run the installer, path = C:\ProgramData\Sophos\Update Manager\Working\Decoded-SDDM\A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1\SUM.msi parameters = REINSTALLMODE=vdmus REINSTALL=ALL SELFUPDATE=1 REBOOT=ReallySuppress
    RunSUMInstaller: MsiInstallProductW returned 0
    Installer finished with result: 0
    SUM version after upgrade: 1.7.1.19
    RunTheInstaller finished at 2019-12-04 11:17:14Z
    UpdateTheStatusFile started at 2019-12-04 11:17:14Z
    Status File Update: Status File Path = C:\Program Files (x86)\Sophos\Update Manager\SUM_Status.xml
    Status File Update: Tag to replace = Self-UpdateResultForActionAt:2019-12-04T11:16:33
    Status File Update: Replacement string = 0
    Opening the status file...
    File opened.
    Status file size = 20802
    File read. BytesRead = 20802

     

    The the next entry is as follows

     

    Pre-execution step starting...
    Found update triggered flag value: Self-UpdateResultForActionAt:2020-01-20T12:23:05
    Removing the update triggered flag...
    Detected Windows major version: 6
    StopOtherSumSelfUpdaterIfRunning started at 2020-01-20 12:23:05Z
    StopOtherSumSelfUpdaterIfRunning finished at 2020-01-20 12:23:06Z
    Pre-execution step finished successfully.
    Execution starting...
    StopTheService started at 2020-01-20 12:23:06Z
    Stopping service SUM
    Service stop pending...
    The service is already in the expected state.
    The service is now in stopped state.
    StopTheService finished at 2020-01-20 12:23:07Z
    StopTheLogViewerIfRunning started at 2020-01-20 12:23:07Z
    StopTheLogViewerIfRunning finished at 2020-01-20 12:23:07Z
    RunTheInstaller started at 2020-01-20 12:23:07Z
    SUM version before upgrade: 1.7.1.19
    Running the installer...
    About to run the installer, path = C:\ProgramData\Sophos\Update Manager\Working\Decoded-SDDM\A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1\SUM.msi parameters = REINSTALLMODE=vdmus REINSTALL=ALL SELFUPDATE=1 REBOOT=ReallySuppress
    RunSUMInstaller: MsiInstallProductW returned 1603
    Installer finished with result: 1603
    SUM version after upgrade: 1.7.1.19
    RunTheInstaller finished at 2020-01-20 12:23:26Z
    Installation failed. Installer return code: 1603
    UpdateTheStatusFile started at 2020-01-20 12:23:26Z
    Status File Update: Status File Path = C:\Program Files (x86)\Sophos\Update Manager\SUM_Status.xml
    Status File Update: Tag to replace = Self-UpdateResultForActionAt:2020-01-20T12:23:05
    Status File Update: Replacement string = 1603
    Opening the status file...
    File opened.

     

    Is this the error message i should be looking for.

     

    I know it seems likely its a network problem but i just checked with our networks team and nothing has changed on these boxes recently. They are both open internally amongest all our networks and externally over 443 and 80. Is there something else that would be blocking this?

     

    Thanks,

    Fiona

  • 0 in reply to Fiona Johnson

    Sorry i meant to add this is the exact same on both boxes. There are only two boxes, not three so there is no third one that is working.

  • 0 in reply to Fiona Johnson

    Hello Fiona,

    the log confirms that on 2019-12-04 the update from 1.7.0 to 1.7.1 worked and the next (and all subsequent) run failed.

    i cannot run that command
    no PowerShell? Sometimes but AFAIK not always the GUI (Explorer/Computer Management/Server Manager) notifies of ACL errors if you display the share properties. It's not networking but Windows object permissions. Usual operations (local or remote access) are unaffected.
    Of course unsharing and recreation of the share is interruptive and even I would not do it without confirming that something's indeed broken. Although most clients might not really notice.

    Christian

  • 0 in reply to QC

    You are a superstar!! Thank you so much.

     

Unfiltered HTML