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

Primary update server to secondary

Hello. Sorry if this question has already been answered and sorry for my English.

[Context] We manage our endpoints with on premise Sophos Enterprise Console. Users are now working from home and their computers are not physically on the LAN. They connect to the company’s IT through VPN. The update server policy is configured to use SEC as primary and Sophos as secondary. When the VPN is not connected, SEC cannot be joined. I know Sophos Central exists but we are not ready to move to this Cloud solution yet.

[Question] Is there a way to tune the failover process from primary update server to secondary (i.e. reduce the time so that endpoints decide to download updates from the Internet if the company’s server is unreachable) ?

[More Context] I do not find any documentation about how it works technically to determine if primary source cannot be contacted and then switch to secondary source. Our VPN has an “host checking” procedure and admits the host depending on signature age, which can be an issue after an absence.

Best Regards

Christophe



This thread was automatically locked due to age.
Parents
  • Hello Christophe,

    for each component ("product" in the ALUpdate log) AutoUpdate always tries the Primary location first. The decision to use the Secondary is made for each component in turn, i.e. it does not "switch"  the source for the whole cycle.

    There's no extra logic for determining the availability of either source.
    The latency depends on protocol (UNC vs. HTTP) and hostname. AutoUpdate uses the relevant Windows APIs to attempt the connection. If name resolution fails "immediately" (e.g. because a private FQDN is used) switching is quite fast. If the name can be resolved the subsequent connection attempt could fail immediately (e.g. with a host not reachable) or simply time out. In the latter case there's of course a significant delay. until the Secondary is tried.

    Christian

  • Hello Christian.

    Thanks for your prompt reply.
    I try to understand your information.
    Let us consider that the reference to our primary server is currently \\SERVERNAME\SophosUpdate\
    Are you suggesting some change in this “path” could improve the situation ?
    For example HTTP protocol instead of UNC, fully qualified name instead of short name (or even IP address maybe) ?

    Best Regards.

    Christophe.

  • I guess as a test, to prove QC's response, from a command prompt, if you run:

    net use \\servername\Sophosupdate\

    net use \\servername.a.b\Sophosupdate\

    It probably takes longer to timeout with the first unqualified address example.

    HTTP updating could be an option as well.

  • Hello,

    correct! Whatever path works internally and on VPN bus fails as quickly as possible "outside".

    Please note that while there is a significant latency it's normally not noticeable as updating is silent. Only when using  Update now it's visible. BTW, RMS is never updated when updating from Sophos and thus AutoUpdate will consider updates from Sophos as failed.

    Christian

  • Hello.

    Thank you again for your support.

    It seems that we indeed have some issues to access the share, probably caused by a “side problem” (not related to Sophos).

    I would like to configure our primary update server to use HTTP instead of UNC.

    I’ve found the article KB-000033542. Is this the correct procedure I need to follow ?

    Christophe.

Reply
  • Hello.

    Thank you again for your support.

    It seems that we indeed have some issues to access the share, probably caused by a “side problem” (not related to Sophos).

    I would like to configure our primary update server to use HTTP instead of UNC.

    I’ve found the article KB-000033542. Is this the correct procedure I need to follow ?

    Christophe.

Children