Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 2469 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

Configure Threshold for "Update Failed" Message

PeterB

Hi All,

My 1st post so be gentle :)

Apologies if this is a really dumb question but I have searched hi and low and cannot find an answer.

We are running Sophos Enterprise Console 5.1 and can find no way of configuring/controlling the "update failed" messages clients receive. As the majority of our endpoints are laptops they often get out of date by 24-48 hours, subsequently end users receive the "update failed" message and log tickets with the helpesk when there is basically nothing wrong and the client  has normally updated before the helpdesk has even responded to the ticket.

Is there a way to control when the endpoint displays the "update failed" message i.e. when the client is 7 days out of date or something?

Thanks in advance

Peter

:37999


This thread was automatically locked due to age.
  • 0

    Hello Peter,

    AFAIK this is not configurable and should only be displayed if the update actually fails and the last successful update was more than one hour ago. This could happen in either of the following scenarios:

    1. the laptop is used in an environment where it can't reach the update source
    2. the laptop is managed and uses Sophos as updating source (in which case the RMS component can't be downloaded)
    3. the first update after switching on the computer fails

    In case 3. you could postpone the first check for updates if the cause is a delay in establishing connetivity.

    It'd not be a good idea to issue this message only after 7 days as this would conceal actual problems. If you are using the suggested interval of 10 minutes it shouldn't be too hard to convince the users to wait for, say, a quarter of an hour before calling the helpdesk.

    Christian

    :38009
  • 0

    Hi Christian,

    Thanks for the reply.

    I think case 3 is definately causing some of the incidents - can you advise how to delay the first check - is it a registry tweak or something?

    Thanks

    Peter

    :38023
  • 0

    Hello Peter.

    please see this post.

    Christian

    :38027
  • 0

    You might also find that depending on how the overall scheduling works, if your SUMs are updating during the process of the endpoints downloading the updates (especially where bandwidth throttling is configured) - we have seen incidences where endpoints cannot retrieve updates and will throw errors.

    The best way to check what the cause is to review the logs on the endpoint for the AutoUpdate component, as it will provide actual detail of the error. The messages sent to the console are generally vague and rarely ever provide any useful information other than updating failed for whatever reason.

    I have often found that updating fails due to network timeouts, random authentication failures (have yet to explain that one, but suspect it is an overload condition on the server), and SUMs updating while a download is taking place resulting in a checksum match failure. Each of those messages I could only find through reviewing an SDU from an affected endpoint.

    :38145