Just wondering what challenges everyone else is facing as far as doing DAT updates. It seems discussion to move DAT update times is a double edge sword. I am curious when everyone else is doing updates and what type of business they are in.
1) Type of business; Healthcare
2) Hours of operation: 24x7
3) Clients: 11,000
4) Percentage Mobile devices: 20%
5) DAT update time: 1:30 pm (when most devices are turned on) (randomization intervalxxx) run missed task (most mobile devices) on logon with 10 minute delay.
Other questions I have are is anyone else getting complaints about CPU usage, etc when doing DAT checkin? If so what did you do to resolve, I'd rather not move DAT times and have less clients with the newest DAT.
My environment is similar to yours. I'm currently investigating performance complaints which are believed to be associated with VSE DAT updates, but am yet to obtain firm proof.
Please forgive me if I'm telling you things you already know... I was not aware until recently that the VSE local update task is controlled by policy and is different from the update performed by an ePO assigned task through the agent. In the VirusScan Enterprise 8.7.0 User Interface Policy, the default policy has "Display managed tasks in the client console" and "Disable default AutoUpdate task schedule" unchecked. If the latter is not checked, your VSE update task will run independently and in duplicate of any server applied task. The former option allows you to see server applied tasks in the VirusScan console. In testing, I also determined that update attempts were occurring at every policy enforcement for me because my VSE deploy task was scheduled to run at every policy enforcement. (http://community.mcafee.com/message/110886)
One of the performance issues I encounter on laptops was believed to be McAfee related but I was later able to rule VSE out as the cause. At this point, the root cause appeared to have been Window's "Client Side Caching".
When troubleshooting reported McAfee performance issues (that I am able to witness) I like to use ProcMon to see what's truly being accessed while the CPU is pegged. Be aware that running ProcMon will also take a fair chunk out of the processor. (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) This is nice because you can see if files are being accessed, and if processes are running, that have nothing to do with McAfee.