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

Sophos Patch Management Assessment - remote cache

Hi,

Just looking for some help from anyone who might be familiar with the Patch Assessment tool.

I have a central install of the Sophos Enterprise Console, and a number of remote sites where the Update Manager is installed. I tried following the instructions here - https://community.sophos.com/kb/en-us/117121 - in order to configure remote caches for the mcescan.cab which is currently around 202MB in size. I can't get this to work however, and so my central install server tries to update every remote PC over our site VPN's... not good when we only have a 10Meg link and 200 computers to update. It only updates a couple of times a month so I can probably live with it.

Does anyone know how to set this up properly?

I've got a support case open with Sophos, but they've been unable to help.

Regards,

Richard



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

    which of the three methods (explicit, transparent, reverse) do you use? And, BTW, the central server doesn't try to update - it's always the endpoints doing the download.

    Christian

  • Hi Christian,

    Thanks for your reply. I'm using the 'explicit' method which I rolled out using Group Policy Preferences. Since the instructions on the KB article weren't particularly clear I wasn't sure whether I needed to remove the 'PrimaryServerUrl' key after adding the 'PrimaryProxyServerUrl' key, or whether the 'PrimaryProxyServerUrl' key should be prefixed with http:// as 'PrimaryServerUrl' is. So I basically have both keys set, and one with the http:// and one without.

    Thanks also for clarifying that the client initiates the download from the server.

    Best regards,

    Richard

  • Hello Richard,

    PrimaryProxyServerUrl
    works with the http:// prefix, just tested. And BTW, it's a value, not a key.

    tries to update every remote PC
    the pull/push question aside - did you indeed see the traffic over individual VPN connections or did the aggregated traffic suggest that each endpoint is downloading? And the question that should always be asked: Is the cable plugged in (in this context: Is the proxy actually serving the requests from the cache or does it forward them to the PrimaryServer)?

    Christian

  • Hi Christian,

    Yes sorry, I did create string values, not keys.

    Are you saying that it works with or without http:// or should I be using that?

    When I was logged into my central install server, I was watching Resource Monitor/Network/Network Activity and could see connections from multiple workstations - with each connection being the download of the mcescan.cab file. I'm certain of this as connecting to the individual workstations I could see the mcescan.cab file appearing in the folder after the network activity with that workstation ended. So at this point I don't know whether the client is going to the proxy server but getting forwarded to the central install, or whether the client is bypassing the proxy. Either way, it's certainly not doing what I need it to do...

    Should I have both registry values set on a client? Or should it just be the 'PrimaryProxyServerUrl' value?

    Cheers,

    Richard

     

  • Hello Richard,

    it works with http:// (I didn't test without) so unless you are the adventurous type use it. A request to an explicit proxy must contain the final destination so you need the PrimaryServerUrl as well. If there are connections from multiple workstations then they don't pick up the PrimaryProxyServerUrl ... oops! I just notice that article 117121 is in error as it advises to set the values on the 32bit (Wow6432Node) node. Actually it's always HKLM\SOFTWARE\Sophos\Sophos Patch Agent\ and as I assume you have 64bit endpoints this might be the reason for the direct connections (and this would also explain why you've asked about setting the PrimaryServerUrl).

    Christian

  • Hi Christian,

    Right, I've just updated a 32bit client (at a remote site) so that the PrimaryProxyServerUrl value starts with http:// - I then deleted the mcescan.cab file and forced a policy update. I can now see on my central server that the client has checked in and is downloading the mcescan.cab file from the central server and not the proxy server again, so that change hasn't helped.

    We have a mix of 32bit and 64bit clients, so thanks for pointing out the error with the KB. I'll change the policy to only update the key that you said.

    Do you have more details on how the proxy works? As it may help me to figure out why this isn't working. For instance, I assume that a client needing the file would contact the Proxy server first, which then checks to see if it has the latest file cached locally, and if it does sends it straight back to the client. If it doesn't it then contacts the primary server and downloads the file which is then passed on to the client? Is the cached file stored in memory or in a folder somewhere?

    Is there any additional configuration needed on the proxy server to get this working? Registry keys or shared folders etc? The proxy servers I'm using only have Sophos Update Manager installed and not the SEC.

    Regards,
    Richard

  • Hello Richard,

    I have no knowledge of the internals, running another test suggests that the Agent tries the PrimaryServerUrl as fallback. 

    The proxy servers I'm using only have Sophos Update Manager
    ... but no proxy software if I understand correctly. There's no proxy (not even a web server) functionality built into SUM or SEC. Like with WebCIDs you have to supply your own web server for this. IIS is probably not the best choice for your purpose. A viable alternative is Squid. Dunno about its footprint, it can do much more than what you need but perhaps you can find some other use as well.

    Christian

  • Hi Christian,

    You may have hit the nail on the head there. I just assumed that I could make any server the 'caching proxy' as it wasn't stated in the KB article that a full blown proxy server was required, but it makes sense now. I'll check out your suggestions and see how I get on. In the mean time, thank you for taking the time to answer my questions - it's really appreciated.

    All the best,

    Richard