A tenet to keep in mind is that your AV solution should be running ASAP; and it should be running whether or not a User logs in.
(That essentially forces you to use a System service that is "Autostart")
You have few options when it comes to controlling System services.
If you have an idea to improve on the Windows model, perhaps by having some "McAfee" specific controls layered on top of it, please submit the ideas via the PER submission process.
However, as long as the product is dependent on monolithic DAT signature files that are many megabytes in size, and that these files must be read in order for the scanning engine to initialize, then the "hit" is unavoidable. Not just that we're reading all this data into memory, but that it's being read from disk - not exactly the fastest of data xfer methods. For example I'm sure we can agree that start up time for Windows+VSE+HDD is going to be noticeably slower than Windows+VSE+SSD .
The VSE product line certainly has plans to move away from being dependent on these massive DAT files.
I'm interested in what folks come up with as things to do "for now".
What problems could there be if McShield was set to a delayed start? it would be a 3min delay, but if the user doesn't login within that time it will start anyway.
There'd probably be little consequence...except if you were experiencing an outbreak, then the consequence could be severe.
Delaying when our scanner service starts means delaying when files are being scanned - and files can be created/modified (read: infected) by threats as soon as the network layer comes online (for remote attacks). That window of opportunity is smaller if we remain at Automatic start.
The product does scan certain key things when it initializes, to help us ensure the environment is "clean" to the best of our knowledge - but there will always be the potential for certain rootkits to dodge our post-start inspection and later scans if they're able to become resident first. This is why I say initially, there'd probably be little consequence, for most people anyways.
You may also want to verify that you aren't intentionally making things worse. Lots of people think it's a great idea to run client tasks "At Logon", but it just adds to the already bloated flurry of activity Windows is performing when a user logs in.
If you are really determined to use that type of strategy for scheduling, try setting these tasks to run at maybe 4am, and use the option to run "missed" tasks with a 10 minute delay, you should be able to distance the burden of those tasks from the burden on user logon-related activity.
Thanks wwarren, we got things runing good now. went from 4min boot times to 45sec and McShield is only down for 30sec of that. I am not sure this will work for everybody but this is what we did.
Updated "On-Access Low-Risk Processes Policies" by adding our in-house production applications.
Updated "On-Access General" policy and set "Processes on enable" to scan processes on McShield startup
Updated Artemis (Heuristic network check for suspicious files): from very low to medium.
We also disabled McShield until our process are done, which takes about 30sec. (This is why I enabled "Processes on enable" to scan all that has started up.)
Not sure why Artemis was set so low and may not have anything to do with startup time. Outlook was the biggest culprit so we had to arrange startup applications to start it sooner. I can't condone this startup procedure as our network is failry safe from virus's so please do that at your own risk. I can't be held responsible, lol
Thanks Joe, but its not McAfee task that we are working on, its regular application taks.