Be sure you are running the 5400 engine.
EngineServer.exe is responsible for providing scanning services for ScriptScan, and Outlook Scan - scanners that in prior versions loaded the Scan Engine and DATs into the running process; EngineServer provides an out-of-process scanning mechanism, one benefit being if the scanner has issues it can fail and not bring down the application. This process also handles the scanning for the add-on product "VirusScan Enterprise for Storage".
If you notice the process using high CPU, it is likely that scanning activity is underway, or loading of the engine and DAT signatures.
If an update has just occurred, then it is likely reloading the DATs and engine.
This process runs at normal priority, so any activity from it could be noticeable to the user...
An issue that might lead to an undue amount of activity following an update, is if EngineServer is initializing an instance of the Engine/DATs and it fails to utilize the RunTimeDat for memory management, in which case it reverts to using an older memory management scheme (using WFV*.tmp DATs) that is not as efficient.
The older memory management scheme is used until the next time the service starts, or an update occurs, where it will again attempt to create the RunTimeDAT.
I have same issue
When start dat update EngineServer.exe use 100% cpu about 5 min.
And when finish back to normal...
Epo agent 3.6 and agent 220.127.116.110, Virusscan 8.7 patch2.
Chat with gold support and i got answare:
Its normal. when start dat update engineserver.exe high cpu usage is normal, and no hotfix or registry settings for control cpu usage.
I don't see how telling our clients that Yes it's normal for your machine to grind to a halt for 5-10 minutes every day because a dat update is occuring or it might be scanning during the update. Why does the problem exist in 8.7 and not 8.5? We are on the verge of upgrading to 8.7 but reading posts like this make me even more leary of attempting that. It's absolutely unacceptable for a clients machine to be completely frozen for 5-10 minutes because of a McAfee update. Why doesn't McAfee fix this?
>Why does the problem exist in 8.7 and not 8.5? We are on the verge of upgrading to 8.7 but reading posts like this make me even more leary of attempting that. It's absolutely unacceptable for a clients machine to be completely frozen for 5-10 minutes because of a McAfee update. Why doesn't McAfee fix this?
Agreed. It needs investigation to make sure there is no product issue, and even if not, to see if there's a way to improve the user experience.
It has been posted before that there are tweaks to lessen the burden of what happens during an update.
Same issues here.
As a work around using ePo I have disabled global updating and allowed the definition updates to only run after hours. I also, forced "run missed event." If a user has turned off his/her machine then they will get the latest DAT once they turn it on, and interrupt the workflow. If they left it on then they will get the newest without even being on the PC. Would rather have it fixed, but this helps in the interim.
Same horrible issue here. Scheduling the updates at night helps for some, but we have a lot of laptops be taken home. Folks come into the office, log on, and ouch, the system comes to a crawl. EngineServer.exe taking most of the CPU and hangs Outlook, Word and most other apps. Unacceptable.
The fact that this did not happen with 8.5 is a clear indication that it IS A PROBLEM that should be fixed. I'm exploring ways to roll back to 8.5, just what I needed...
I agree the 5400 engine should be installed for concerns with the engineserver.exe I would also suggest testing lower the process priority for either Virusscan or the agent. The link below talks about how to do this. It refers to policy enforcement, my thoughts are that the updating process will be affected because of a shared component. With this change in place the updating process should take a back seat to user processes.
Hope this helps.