Endpoint Protection

Hi Guys,

 

I'm noticing on some but not all of my 2008 R2 Sp1 clients that were upgraded from 12.1.4100.4126 to 12.1.5337.5000 that the scheduled daily scan no longer runs.  When I start the GUI on the client I can see in the scan for threats window that my custom scan is still defined.....my client shows the next scheduled scan as today, yet it has not run for 2 weeks since being upgraded and restarted. The Scan log on the servers are blank and I have also checked the symantec registry keys and see that the LocalScans is still there with the correct information for the custom scan.  No other changes have been made to the clients yet so I'm not sure what is going on?

 

The other issue is that I'm experiencing delays waiting to logon to the SEPm server console remotely.  Logging into the SEPm console directly on the SEPm server works fine though so this may be local client/java issue.

 

Please advise,

 

Larry

 

 

Was it canceled perhaps? Does anything show in the log to give that indication?

check the accounts used by SEP sevices in services.msc? Did you change the logon type?

Cancelled everyday since 10/30/14.  Highly unlikely, I remember way back in I think 11.X there was a bug where custom scans corrupted after an upgraded but they left weird GUIDs in the registry making it wasy to detect.

Would there be any other logs on the client that would indicated a cancelled or failed scan?  As mentioned the scan log is empty.

 

Yea it was a bug when upgrading from one version of 11.x to a later release.

The only one is the scan log or possibly the system log may show something as well. You can enable VPdebug log but it no scan ever kicks off, this won't show anything.

Rafeeq,

 

The clients use the local system account to reun the SEP services.  And I use the SEPm admin account to logon to SEPm locally or remotely....not sure which question you were replying to.

 

Thanks,

Brian,

Just checked the SEPC log in event viewer and only the new defs scan runs since the upgrade.  The full scan is no longer there.  Weird that according to the event logs the startup scan is still running yet that should also show up in the Scan log which is blank this is happening to about half of my upgraded servers so far. I will try changing some settings with the scan...after that I may have to contact support.

 

Thanks,

 

May want to try creating a new group and moving one affected PC into the group, let it grab a new policy, then move it back. Perhaps something is "stuck"

But calling support may be the quickest way here.

Hi!

Anyone who knows how to disable all symantec services?

when i right click on the services its all grayed... how can i make it clickable?

 

thanks!

You need to unlock the lock icons in each of the policies for the corresponding components. This will allow you to disable them when doing the right click and disable SEP

Hi,

Thank you for posting in Symantec community.

Could you try the following steps and see if it makes any difference.

1) Change the scan time

2) Disable scanning of compressed files under advanced options. 

3) Create a custom scan that excludes the COMMON_APPDATA directory from scan.

 

We are upgrading more servers to RU5 this weekend so I will try your steps on any servers that seem to have the issue.  I will run another scan report today to see how it's going.

I have found so far that a complete uninstall\reinstall of the client also addresses the issue.  We are also seeing some servers that are running scans get "hung up" and not have the scan complete. Though we do run daily full scans with scan compressed at level 10 and tuning set to best app performance.  It is strange that these servers were running fine on RU4 without any scan settings changes needed.

 

Chetan - I know what I will lose by removing scanning of compressed files, but what will I risk not scanning Common_appdata? Mgmt may not want to stop scanning folders as a fix for this.  Has RU5 changed the scan logic somehow?

 

I do understand your concern but you just follow it for testing purpose so we can isolate possible root cause.

OK I will advise, I running a full scan on one of the affected machines to see where the scan hangs at.  Then I will try the steps you provided.

Enabling VPdebugging would also show advanced details of the files scanned and where it may be hanging.

How to enable "Vpdebug Logging" on Symantec Endpoint Protection 11.0, 12.1, and 12.1 RU1

I'm running scans with the settings advised above.  I should have results tomorrow.  In the meantime, I'm  watching 5 different 2008 r2 clients that are all upgraded to 12 1 ru5 that each appear to have the scan process hung up on small .dll files. By hung I mean the scan is on the same file for at least 20 mins. These are not compressed files, nor do they appear to be in the common_appdata path:

server a C:\Program Files (x86)\Common Files\microsoft shared\VC\amd64 msdia80.dll 894KB

server b (same file) C:\Program Files (x86)\Common Files\microsoft shared\VC\amd64 msdia80.dll 894KB

server c C:\Windows\SysWOW64 bitsprx4.dll 9KB

server d (same file) C:\Windows\SysWOW64 bitsprx4.dll 9KB

server e C:\Windows\inf mdmcpq.PNF 228KB

So this is a bit concerning, I will run a full scan report tomorrow to see how many machines completed their scans how many are stuck.  This would definely indicate an issue with RU5 all 5 of these servers were running scans completing withing about an hour up until the upgrade over the Sat-Sun maintenance window.

Has there been any change to scan tuning with RU5?  Maybe best app performance waits for complete idle before scanning now?  I'm going to run some servers set to best scan performance to see if they hang up also.

 

Hopefully a new scan policy is all they need....

 

 

Interesting issue you're having. Running RU5 as well but not seeing this problem. Perhaps a call to support is warranted as well.

Brian,

 

Did you upgrade from 12.1.4100.4126 as well?  Also if you RDP to a server before the scheduled scan and watch it kick off it doesn't hang up for you?  Servers that are not left with an RDP session active or disconnected seem to run the scan slow but OK.  This is just an observation on a couple machines I won't know until the report runs tomorrow.

 

Chetan,

I'm watching a scan run with the settings you specified and the it appears to have not moved from below in 15 minutes:

 

C:\Windows\System32\DriverStore\FileRepository\prnep00l.inf_amd64_neutral_f1fa021d2221e2c7\Amd64 EP0LVRA5.DLL 354KB.  Let me know if you have any more suggestions.

 

Thanks guys

 

Ok I think I found something, the symantec reputation site is being blocked by my company firewall and we have insight lookup enabled for the scans.  I set a scan and unchecked insight lookup and set tuning to best scan performance and it's running fine.  Does it sound feasible that could be the issue?

Very possible, does the system log show timeout or connection errors trying to upload files for a reputation check?

You also allow the insight URLs out thru your firewall if you choose per this article:

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

I did upgrade from that version. However, I do allow insight lookups...

Yes but the link is dead, I see drops for a bunch of servers getting dropped in the firewall logs.

Log Name:      Symantec Endpoint Protection Client
Source:        Symantec Endpoint Protection Client
Date:          11/24/2014 7:18:22 PM
Event ID:      69
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      Description:
 

Scan Failure: Enhanced scan failedApplication has encountered an error.
For more information, please go to: http://www.symantec.com/techsupp/servlet/ProductMessages?product=SAVCORP&version=12.1.0.0.sepe&language=english&module=0000&error=0024&build=symantec_ent

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Symantec Endpoint Protection Client" />
    <EventID Qualifiers="49407">69</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-11-25T00:18:22.000000000Z" />
    <EventRecordID>11011</EventRecordID>
    <Channel>Symantec Endpoint Protection Client</Channel>
    <Computer></Computer>
    <Security />
  </System>
  <EventData>
    <Data>

Scan Failure: Enhanced scan failedApplication has encountered an error.
For more information, please go to: http://www.symantec.com/techsupp/servlet/ProductMessages?product=SAVCORP&amp;version=12.1.0.0.sepe&amp;language=english&amp;module=0000&amp;error=0024&amp;build=symantec_ent
</Data>
  </EventData>
</Event>

Guys, finally got a resolution on this after working with tech support for months.  They won't admit that RU5 changed something about how idle state is detected on SEP clients but my scans (manual,scheduled, and defwatch) needed scan tuning changed from best application performance to best scan performance.  Vpdebug logs showed that even on servers with no users connected or accessing them that scans were sleeping becuause they did not detect an idle state.  As the scans waited and waited they would run into other scan windows, retry missed scans interval would come into play, and eventully enough scans would pile up on a client that the ccsvchst service would have to be killed for the client to work again.

Manual and scheduled scan tuning was addressed via SEPm policy but the defwatch tuning needed registry keys put on every client. These were the keys needed on 64-bit servers:

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\LocalScans\Defwatch CScan Repair Options]
"ScanTuning"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\LocalScans\Defwatch QuickScan Options]
"ScanTuning"=dword:00000000

Now my scans are running at normal speed, and completing within normal daily scan times.

 

Thanks for the update.