Endpoint Protection

This post is very similar to https://www-secure.symantec.com/connect/forums/applications-running-network-shared-folder-extremely-slow-after-installing-sep-121, which has been locked and tagged as "solved". However, I don't quite understand how "do not use this software" can be marked as a solution, hence this new post. We have in our company some executables that: * are available on network shares and executed from that place * requires admin rights, so prompt for UAC * are less than 300kB * takes tens of seconds to just prompt for the UAC, usually like 40 seconds but sometimes up to 3 minutes The very same file, once copied on the local drive, is run in less than a second. When on the network share, 40 seconds. When all modules from SEP are deactivated (Auto-protect, Download Insight, SONAR, IPS, ...), still 40 seconds. After uninstalling SEP however... it comes back to an instant execution. We are using RU1.

can you use only AV and test.

Disable the firewall and re-test it. See what the result is.

Sorry, should have mentioned it: with all modules including the firewall deactivated, we still have the same latency problem

So just to confirm:

• SEP disabled - latency issue
• SEP uninstalled - no latency issue

Is that correct?

As a quick test, can you try disabling the "Insight Lookups" under the "External Communications Settings" of the group containing your (test) clients and see if this affects the start-up speed?

Hi Can you check your AP settings for network scan, what options have you enabled?

Well the first thing that really got my attention here is that you stated that you were on RU1

 

I don't have the info handy at this moment, but I do recall that 12.1 RTM and RU1 and I believe that RU1 MP1 had some issues with honoring exceptions.

 

I would start with an upgrade (if this ends up going to support anyways, I don't think engineering will work on an older platform), get the SEPM to RU4, and toss it onto a couple of test clients. The upgrade may help; there has been engine changes themselves on how the individual components work and the newer verisons will be the first ones to get those updates should they be released via LU.

 

Now what I am curious about is are you removing the other components or are you just disabling/turning them off - there is a difference, drivers still load and still affect the system. Simply withdrawing or disabling features by policy do not unload drivers.

 

If this persists despite removing components of SEP - you can also go down to the CORE only set of SEP (which "has no technologies installed" - but isn't really true) - once we get that far, we can start individually looking at which drivers themselves is the cause.

Or if you would also be willing and tackle it on the policy end - scanning network files, etc. can cause issues too.

 

Hi

Its always recomended to be on the latest version i.e SEP 12.1.4 which has many fixes

Regards

 

Hello, and thank you all for your answers. Previously we tried to deactivate the components using the policy, so we did not try to install the AV only, without the firewall &cie. However we have run a few more test cases, and the conclusions are as follow: * the same issue occurs even with the client updated to RU4 * another executable that does not require admin rights trigger the same latency * the same issue occurs with only the auto-protect core installed with a specific package, without SONAR, the IPS, the firewall... (I believe this is the default "basic package for servers that require the best performances") * we still have the same issue when deactivating the "scan network" option on SEP, *and* deactivating auto-protect *and* without the other modules installed In all those test cases, completely removing SEP allowed us to launch instantly the remote executables.

Thank you for your proposition. We tried both to uncheck the "Scan files on remote computer" and to deactivate the whole auto-protect module without success.

Best option, check with support:

How to create a new case in MySymantec

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

Phone numbers to contact Tech Support:

Regional Support Telephone Numbers:

    United States: https://support.broadcom.com (407-357-7600 from outside the United States)
    Australia: 1300 365510 (+61 2 8220 7111 from outside Australia)
    United Kingdom: +44 (0) 870 606 6000

Additional contact numbers: http://www.symantec.com/support/contact_techsupp_static.jsp

As unlikely as it may seem, that is correct. We reproduced this issue on several computers on our network, several geographical locations, several RU of SEP 12.

This was a bug in RU2 MP1 which was than corrected in RU3. It was determined to be the firewall. Sounds like somethign else is going on. In either event, I would suggest opening a support case.