Despite the modern virus protection is based on prevention by scanning network traffic and by real-time protection, many companies still have policies, that full scans must be performed regularly. Since hard drives are getting bigger and bigger, this kind of scans takes longer and eats up resources. Also, if users turns off their computers when leaving office, the scans must be scheduled at times when they should be using the computer for something more meaningful.
I've come to a solution, that it's best to make a compromise by setting virus scanner process ProcessorAffinity to just one or two cores, allowing the user to use the rest of the resources. That allows to fulfill the strict policy of regular scans without frustrating the users with the slowdowns, not to mention the unnecessary problem reports caused by it.
I don't have any problem setting this up: I can easily automate it by deploying a scheduled task currently triggered by user logon, e.g. for F-Secure (Scanner Manager process):
schtasks /create /tn "F-Secure Affinity" \
/tr "PowerShell '$Process = Get-Process fssm32; $Process.ProcessorAffinity=2'" \
/sc onlogon /delay 0001:00 /ru System
Here, the affinity is set when the user logs in, since before that there's no other need for the resources on regular workstations.
I'm just curious whether this is best practice or has any disadvantages.
- Is this giving malware a potential head start? Is this a notable risk?
- Should I have different triggers than logon and should I set it back after the scan finishes?
- Is there a better way to achieve the goal of satisfying both: the company policy and the users?
While an appealing idea at first, you should consider than antivirus scans are generally bound by disk I/O performance, rather then CPU speed.
In other word, with PC using classical mechanical disk, change antivirus affinity is not going to have a significant impact on user experience: its PC will remain slow, due to very poor IOPS provided by the underlying storage.