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

SUM cannot download Mac OS X subscription

Hi All,

We have a Windows 2008 R2 domain network (with Windows 2008 R2 servers, Windows 7 workstations, Mac OS X 10.9.4 workstations and CentOS 6.5 servers/workstations) that access the internet via a proxy (Squid). I have set up a Sophos Server on Windows Server 2008 R2 and have successfully subscribed to Windows and Linux subscriptions and have protected all Windows and Linux machines. However, whenever I add the Mac OS X 10.6+ subscription, the SUM throws errors saying there is an issue with the proxy/gateway and the HTTP response code is 502. We do not have any issues with the proxy as we can get to the internet without issues. Our paid subscription includes Windows, Linux and Mac OS X.

Anyone else experienced this? I can't seem to find any related posts on Google.

Edit: We are using SEC 5.1.

Thanks in advance,

Vlad

:52615


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

    won't absolutely rule out an error on the backend CDN which acts as d1 but then, wouldn't others encounter the same error? I've just sent the request for the "problem file" to 125.56.204.80 and it correctly responded with application/octet-stream. Squid claims it received a text/html reply though - I wonder if the result codes on this log line really indicate success, text/html suggests an error reply from the CDN (but this should be accompanied by a HTTP response other than 200).

    While it looks like the problem occurs only when Squid is involved I can't fathom what's the cause - there's no reason that the backend should behave differently when precisely Squid (and "your" Squid) requests this very file, OTOH why should (just "your") Squid fool around with this very request (but maybe I'm unimaginative). Makes me wonder if it's an external (network) component ...

    Christian

    :52837
Reply
  • Hello Vlad,

    won't absolutely rule out an error on the backend CDN which acts as d1 but then, wouldn't others encounter the same error? I've just sent the request for the "problem file" to 125.56.204.80 and it correctly responded with application/octet-stream. Squid claims it received a text/html reply though - I wonder if the result codes on this log line really indicate success, text/html suggests an error reply from the CDN (but this should be accompanied by a HTTP response other than 200).

    While it looks like the problem occurs only when Squid is involved I can't fathom what's the cause - there's no reason that the backend should behave differently when precisely Squid (and "your" Squid) requests this very file, OTOH why should (just "your") Squid fool around with this very request (but maybe I'm unimaginative). Makes me wonder if it's an external (network) component ...

    Christian

    :52837
Children
No Data