Video Screencast Help

SEP Scanning External USB 2.0 Storage

Created: 01 Dec 2010 • Updated: 02 Dec 2010 | 4 comments
This issue has been solved. See solution.

Hello all!

I have a customer whose weekly scan time is 12-14 hours. This is a FULL Admin scan that cannot be modified or canceled by the customer.

The machine specs: Dell M4400, SEP RU6MP1, XP Pro, lots of RAM, 150 GB onboard drive, two external USB 2.0 drives with about 600MB of total data, hardware encrypted, ~4,300,000 files.

My questions are:

1) Would faster external storage (eSata) improve his scan time? Not sure how I can tell if SEP is scanning faster than the USB 2.0 transfer rate or not??

2) The file cache has a ceiling of 65,000 files...I was hoping that I could increase that to help the situation, but I obviously can't. Is there a downside to a higher file cache other than some loss in disk space?

3) Any other ideas/thoughts for improving his scan time?

Thanks,

-Mike

Comments 4 CommentsJump to latest comment

Go_Beavs's picture

I think your best bet would be to configure that machine to run more than one scan, however scan less data at a time.

For instance you could do 3 different scans:

  1. On Monday night scan the machines Hard drive
  2. On Tuesday night scan external drive #1
  3. On Wednesday night scan external drive #2

You need to configure this locally from the client though is the only catch, and then remove the scan set by the SEPM.

iamadmin's picture

The problem is that the weekly 'Full System" scan is defined at the SEPM and cannot be changed. (As per corporate policy). That said, what I did do for the customer is move him to another OU and set a new policy to do the full scan scan over the weekend. At least that way his work time would not be impacted.

Thanks for the suggestions!

-Mike

Tyler Frans's picture

Great question. Ben's suggestion is a good one. It boils down to finding where you want the cost established, which can be a bit of a balancing act. This can require some testing in the environment and I don't know how intrusive you want to be on a production system and a user.

I would suggest benchmarking the current system setup to determine where the bottlenecks lie and tweak to best suit the situation. You can run a scan without the externals attached to establish the baselines and add each one so you have your knowns. You can then throttle the scan in the product to meet the business needs.

Hardware:
Going the hardware route, I'm not sure you'll necessarily get the return on time and monetary investment for this approach. Especially if it is only a single system you are dealing with. You could setup PerfMon to monitor the throughput during the scan to get an idea if you are anywhere near impacting the USB 2.0 throughput for a baseline there. My initial guess would be no. Some USB controllers will have CPU overhead and eSATA can boost the throughput three-fold while reducing the CPU overhead. System disk and CPU specs are another consideration in the performance equation. One product adjustment you could test is multi-threaded scans. We generally suggest the multi-threaded scans for servers with high performance CPUs and storage devices, but if you're up for testing it may help.

Product:
The largest gain will be through determining optimal scan time and throttling the scan options. Keep in mind what is happening on the system at the time of the scan. We generally suggest scheduled scanning during non-peak usage of the system for best performance results. 3rd party application security and maintenance cycles can also impact performance (backup snapshots, system updates, security scans, etc...). If you have a user that is using a lot of applications along with a lot of IO hitting the external drives and then a full system scan kicks off, there's going to be competition for CPU cycles and disk IO. By default the product gives preference to other applications (Best Application Performance setting). The scan tuning options will determine how demanding the scan can be. In the same vein as Ben's suggestion above, you could break up the scanning into multiple scans through out a specific time frame (weekly) by directory.

Some documents you may want to review:

Symantec Endpoint Protection scan tuning options
http://www.symantec.com/business/support/index?page=content&id=TECH105706

Enabling multithreaded scans
http://www.symantec.com/business/support/index?page=content&id=TECH101387

I hope that helps.

Tyler Frans - Enterprise Support Services, Symantec

SOLUTION
iamadmin's picture

For the most part, the machines in our environment can finish their scan in just a few hours...our schedule is set for after hours so that by morning, 95% of our population has completed a full scan. With this particular customer we have a few things working against us.

1) External Drives

2) Hardware Encryption

3) LOTS of files

The suggestion of using PerfMon to monitor the throughput during a scan is a good one...but I agree that it is probably not where any big gains will be found. His machine is pretty stout for a laptop and that is probably not hurting us much either.

When he scans, it's after hours, and no other apps are running (no competition from backups or defrag utilities)...one thing I can do is change the policy from Best Application to Best Performance mode...that may help a little bit.

Breaking up the scans, as Ben mentioned would be good in some situations...but because our SEPM still kicks off the full scan (as per our unchangeable policy) we would still have an issue. One thing we have always wished is that the SEPM could look at a clients local scan logs an "see" that a full scan had been run (and completed) recently and then automatically skip the scheduled admin scan. Sometimes the timing of when the full scan kicks in is less than optimal, especially on laptops who may not be powered up when the scan is scheduled to run. If the SEPM knew that a full scan was recently run (within x number of days), then even if the laptop was powered off when the scheduled time came, it could skip the scan until the next scheduled time. Hope that made sense...

Thanks again for all the information...we will do some more testing and see what we can learn.

-Mike