Endpoint Protection

When a new virus definition file arrives, defwatch takes about 40 minutes to scan, and slows everything down to a crawl in the process.

Active Scans run through the UI only takes 2 minutes.

This problem seemed to start when I installed multiple bootable partitions on the computer. I normally boot a XP partition, but there is another XP partition, a Win 7 partition and a data partition (total of 4).

Any ideas what could be the cause?

How many machines are affected? Is there anything in quarantine? When new defs arrive, the quarantine is re-scanned in hopes that new definitions can repair the files in there (if any)

Only my machine is affected (also only one with multiple partitions).

Nothing in quarantine.

You can enable vpdebug logging to see what is being scanned, follow this KBA on how to enable it:

How to enable Automatic Symantec Endpoint Protection (SEP) 12.1 Client Debugging, including WPP logs

It's possible those partitions are being scanned. You can try setting an exclusion to test it out to see what the result is.

Hi garyhoff1,

What version of SEP are you using?

There's a known issue in SEP 12.1 RU2 which can cause some machines to slow down for a period of time after definitions update due to rescanning of the AutoProtect cache.

There's a pretty simple test to determine if you're experiencing this issue: disable scanning of the AP cache after definitions update. To test this, follow these steps:

1. Login to SEPM
2. Open your Virus and Spyware Protection Policy
3. Click Auto-Protect
4. Click Advanced tab
5. Click File Cache...
6. Uncheck "Rescan cache when new definitions load".
7. Click OK
8. Click OK again
9. Force your client to pickup this new policy by right-clicking the system icon and clicking Update Policy.

If, when this new policy is applied, the issue does not occur, then you're experiencing the issue I spoke of. The fix would be to upgrade affected clients to SEP 12.1 RU3, as the issue has been fixed in that built.

Regards,

James

is this the DWH.* temp file issue ?

@James-x

Good Day James,

You said:

"There's a known issue in SEP 12.1 RU2 which can cause some machines to slow down for a period of time after definitions update due to rescanning of the AutoProtect cache.

....

If, when this new policy is applied, the issue does not occur, then you're experiencing the issue I spoke of. The fix would be to upgrade affected clients to SEP 12.1 RU3, as the issue has been fixed in that built."

Unfortunately, I can't find any mention of this fix in:

Fix_Notes_SEP12.1.3.pdf

or in

"New fixes & features in Symantec Endpoint Protection 12.1.3 (12.1.3001.165) | EnterpriseSupport | Symantec"

http://www.symantec.com/business/support/index?page=content&id=TECH206828

Could You Please refer me to where this fix is mentioned?

Maybe I missed it in the above.

Thank You Very Much,

Best Regards,

Roberta

My version is 12.1.1101.401 Release RU1 MP1

Could this still be a problem in this release?

Upgrading to SEP 12.1.3 should fix the issue.

Did you see this in the fix notes for RU3? I couldn't find anything related to it, unless I missed it.

I've had this issue since RU1. I fixed with a reg hack but an official fix would be nice.

Hi,

Upon checking fix notes of releases later than SEP 12.1 RU1 MP1 I coudn't find it as a known issue.

What did you change in the registry?

HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\AV\AdministratorOnly\General

There is a DWORD called EnableDefwatchQuickscan, set the value to 0.

You will need to disable tamper protection first if you decide to test this out.

Hi garyhoff1,

Nope, sorry, this doesn't affect 12.1 RU1 MP1. This only affected SEP 12.1 RU2. (RU2 had a new version of the AutoProtect driver which had this problem. It's a relatively rare problem and I've only heard of a couple people experiencing it.)

12.1 RU3 has a newer build of the AutoProtect driver which corrects this issue.

James

Hi Roberta,

I'm not seeing it listed in the fix notes, either.

I'm not sure why it's not there, but it may be because this issue was internally discovered, corrected, and the fix released before we had any customers report this.

To the best of my knowledge, we had the fix released before any customers reported seeing this. (It only happens on machines with heavy disk usage.)

James

I couldn't try a lot of these suggestions as I don't have admin access to Symantac config, and our internal tech support has been slow to respond on issues like this.  Those I could try didn't work.

I removed the drive letter mappings for the other two boot partitions (which I don't need access to from the active partition) to make them inaccessible.  The scan time went from 30 minutes to 10 minutes.  I can live with this.

Thanks everyone for your help.