Central Update Caches failed to update since 12th November

Support received a number of reports from customers of their Central Update Caches failing to update after the 12th November.

This issue was caused by a missing file in the Sophos Warehouses – this was fixed at 09:30 GMT on the 13th November.

Update Caches and affected Endpoints should recover on their next update.

Affected customers will have seen that their Update Caches are marked as ‘Stale’ in Central and their Endpoints will instead update from Sophos rather than their local Update Cache.

Customers can confirm that they were affected by this issue by reviewing the downloader.log located in C:ProgramdataSophosUpdateCacheLogs. The below errors would be seen:

[2019-11-13T07:09:30Z] [<main>] Info: [Downloader::Impl::ProgressLogFunction:468] [I96736] sdds.WIN_MTR_1-0-1-44.1: adding primary package WindowsCloudMDR baseVersion=

[2019-11-13T07:09:32Z] [<main>] Error: [Downloader::Impl::ProgressLogFunction:471] [E83521] 404 Not Found: http://d1.sophosupd.net/update/catalogue/sdds.SSPL_telemsupp_1_0_0.1.xml

[2019-11-13T07:09:32Z] [<main>] Error: [Downloader::Impl::Synchronise:163] SULException: SU_synchronise failed: [4] unspecifiedFailure

For most customers the impact would have been minimal and Endpoints will fail over to download their updates from Sophos warehouses directly. For air-gapped customers their downloads would fail to complete and Linux Endpoints may report as out of date.

Applies to the following Sophos product(s) and version(s)

Central Server Update Cache 1.4.0

The warehouse has been republished and the issue should be resolved.

Affected customers should find that their Update Caches automatically recover from this issue on their next update.

No further updates are expected.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.


  • No Related Posts

[ADC] db queries through ADC are getting timed out after 180 seconds

The issue was caused due to the nature of db query being made by the client. In which query once made to the server, it takes time for server to gather and send its response.

Unfortunately, the application was not designed to send any keepalive packets. So for this complete duration, there is no packet exchange between client and the server.

Once this period of silence reached 180 seconds, netscaler will consider this session as idle and close the connection, as per the default idle time out settings.


  • No Related Posts

FAQ: ShareFile Reports

Q: Can I See a Report for a Single Folder?

A: The activity log will show all activity in a specific folder for the last 3 months, and can be viewed by navigating to the folder in question, using the drop-down menu beside the folder name, and clicking the View Activity Log link. Sub-folders in a specific folder can also be included in this report. This will allow you to see what people have been doing inside the folder.

Q: How Long do Reports Take?

A: After clicking Create Report, your report has been placed in the ShareFile queue and will be processed in the order that it has been requested. This may take several minutes. If the report is still listed as “pending” after 30 minutes, please contact ShareFile Customer Support. While the report is being run, it will report as Pending. Once it has completed, the status will change to Success.

Q: Can I View message History for Other Users?

A: Employee users with the proper permissions can see all the File Boxes and Sent Messages for the employees on the account.

Q: Can I change the time zone used in my Report?

A: Reports cannot be generated in specific time zones. Reports will default to EST.

Q: Can I create and run customized reports?

A: Customized reporting cannot be requested and is not supported.