Update from HTTP CID failing after updating to SAV 10.7.6 and SAU 5.10.139

The irony of a component failing it's one and only job is not  funny in this case ... SAU 5.10.139 appears to be flakey!

Needless to say we have the same issue here, and its not limited to a HTTP CID. What we have seen is that on any machine where SUM is installed with SAU 5.10.139 the update/install process flunks 100% of the time. This manifests with a stalled download on the 3rd download in the sequence and a high CPU usage for the ALUpdate.exe process.  As the downloads never complete, the installs never begin, and thus prevent the updates. The only way to stop the process also appears to be via the Task Manager, it does not end on it's own. This occurs regardless of if the CID is being accessed via HTTP, UNC or locally.

The SUM itself maintains the warehouse and the CID's fine, but in terms of it's own Endpoint it is toast.

This has been seen on the following:

• O/S: Windows Server 2008 R2 and Windows Server 2012 R2
• SAU: 5.10.139
• SUM: 1.6.2.186.

Sophos needs to fix/pull it urgently and devise some method to kill the hung download process so an endpoint can successfully update itself. Visiting 1000's of endpoints is not an option.

Hello DeanThompson,

[I'm not Sophos]
please open a case with Support, whatever the cause it doesn't seem to be a general issue. I have some 5000 endpoints among them more than 150 servers, mostly the ones you mention, with the Recommended subscription (thus SAU 5.10.139.139) - no problems of this kind.

Christian

A little update.

The endpoints are only able to connect to one of the HTTP CIDs. For this CID I deleted the SAVSCFXP folder during my initial testing to check SUM would recreate it. It took a couple of days for the HTTP to start working again.

I did the same for the non-working CIDs yesterday. Hopefully, they start working tomorrow afternoon.

Hello Ahsan Amin,

IIS is running on the server that hosts the CIDs? Once the update manager is idle (you can see it in the SUMTrace log) the CIDs should "work".

Christian

SUM and SEC run on one server and IIS hosting the CIDs on another. I haven't figured out yet what copies the files from the SUM server to the IIS server. The guy who is off sick is in the process of starting from scratch on Server 2016, he's nearly done so we're hoping he'll be back soon :)

Sophos also now have log files from various endpoints and servers.

Hi Amin,

thank you very much! Deleting the SAVSCFXP folder resolved the issue for me. After doing so I forced the Update Manager server update and it immediately recreated the store. Clients then started downloading the files correctly and updated themselves to the correct version. Thank you again!

The recreated CIDs are now working OK but I now need a solution to fix all the Endpoints with are unable to connect. They can't be updated from the SEC.

I'm hoping there is a file or two I can replace on the endpoint which will get them talking to the CID.

Hello Ahsan Amin,

unable to connect
do the have the correct (paths to the) CIDs in the updating policy or not? If the issue was with the contents of the CID they should start to update - depends on the updating interval how long it could take. If the path needs to be corrected this can be done by editing the policy  or assigning a different one.

Christian

Hello Ahsan Amin,

unable to connect
do the have the correct (paths to the) CIDs in the updating policy or not? If the issue was with the contents of the CID they should start to update - depends on the updating interval how long it could take. If the path needs to be corrected this can be done by editing the policy  or assigning a different one.

Christian