Endpoint Protection

Our SEP client is able to telnet to the GUP over 2967 yet the update fails with HTTP error: 407 on the Sylink monitor log.

07/20 14:03:10 [3744] Request> http://10.X.X.X:2967/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/120719021/xdelta120710035.dax
07/20 14:03:10 [3744] Unable to query return content length for SendRequest, 122
07/20 14:03:10 [3744] </CHttpConnector::SendRequest()>
07/20 14:03:10 [3744] </CHttpFileDownload::Do()>
07/20 14:03:10 [3744] <LUDownloader::GetContentToFile> completed.
07/20 14:03:10 [3744] <CHttpFileDownload::~CHttpFileDownload()>
07/20 14:03:10 [3744] </CHttpFileDownload::~CHttpFileDownload()>
07/20 14:03:10 [3744] <LUThreadProc>LU file download failed due to HTTP error:407

This can also happen on  secars test failing which results in not checking in with the SEPM.

This happenes when connection to the GUP needs to have an alter route than the default gateway, or there is not proper route to the GUP or the SEPM. In such cases the SEP will use the settings on the default browser. As far as windows is considered the only way to configure network settings it through the default browser. Moreover SEP uses the 'SYSTEM' account to initiate the communication to the SEPM and the

To verify this we need to use the PsExec.exe from Sysinternal Suite.

http://technet.microsoft.com/en-us/sysinternals/bb897553

PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe". This will open the browser with the 'SYSTEM' account

The secars and GUP thread should be tested on this browser.

Do you have a proxy server on the network?

Ar eyou going through a gateway (firewall, router, etc.) in order to get to a different subnet on which exists the GUP server?

If you have no proxy server and are not going through a gateway device...

Your default browser is Internet Explorer?  Try removing all the checkboxes in Internet Options -> Connections -> Lan Settings

* * * * * * * *

Hello,

Test SEP to GUP and GUP to SEPM communication

Check this Article:

Test SEP to GUP and GUP to SEPM communication

http://www.symantec.com/docs/TECH153328

Secondly, Are you running Proxy on the Network? Is it ISA proxy? 

If yes, check these Articles below:

Client is not appearing in Symantec Endpoint Protection Manager (SEPM), error: HTTP returns status code=407 

http://www.symantec.com/docs/TECH104926

Clients keep downloading virus definitions from SEPM via proxy when SEPM and SEP are in the same local network. 

http://www.symantec.com/docs/TECH97507

and this Thread below:

https://www-secure.symantec.com/connect/forums/gup-issues-low-bandwidth

Hope that helps!!

after it opened in system account did you disable Automatically detect settings and disable Use automatic configuration script under LAN settings?

Hi ABN ,

Please try following.

1. Make sure client which is trying to get updates from GUP are in the same group in sepm
2. Space should be enough on Client machine
3. If firewall is configured check port 2967 should be open
4. Alternatively check below

Check proxy settings for SYSTEM account. You can do it using pstool from Microsoft and running the command:

1. psexec -i -s "C:\Program Files\Internet Explorer\iexplore.exe"

   It will open IE window with system account - go and check proxy.

If you are using ISA check below thread might help

https://www-secure.symantec.com/connect/forums/sep-client-communication-isa-2004-ru5

Are you able to manually open  http://10.X.X.X:2967/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/120719021/xdelta120710035.dax from a client machine ?

does it ask for username password ? 

is local address bypassed from proxy ?

I really appreciate the responses, but intention was to notify on a peculiar situation seen.

Even though telnet to the GUP was listening the update failes and Sylink monitor log give HTTP error 407. I did try to manualy download the GUP thread using PsExec and invoking the System account browser. Thus I was able to confirm that the traffic was not getting completed.

A wireshark log did confirm that the packet was getting lost over the default gateway and since it is a HTTP request it will be directed using the IE (default browser) settings.

We have fixed this by giving a dedicated route.

Thank you for the efforts and it is much appreciated.