This content has been marked as final. Show 7 replies
Do you have any tasks that are scheduled during that time of the day, like an Update Task?
If you happen to, since I wont see this forum again for a couple of hours, do you have randomization turned on?
Without knowing much more about your EPO or network setup, this is all I can think of right now.
Now, you can make the McAfee protected registry changes as needed.
Remember to restore the settings you saved earlier (right?).
I hope this is helpful. Let us know if you have more questions.
We are having the same type of issue here in our environment as well. However, we have deployed the 8.7i patch1 to test pilot of 1200 machines and are seeing the issue on about 10%.
Our users are reporting the even mouse movements are choppy for about a minute during the dat upgrade.
I first suspected that this is due to "too many" updates at one time. But 9000+ 8.5 users are not reporting this issue.
I have not found the solution as of yet and in the meantime I have moved these machines into a new group and will delay the dat upgrades for the 8.7i installations until after-hours to avoid the CPU spike.
I appreciate the link you provided and I will test this on some of our machines and report the results.
By the way, the issue about not being able to update the registry for the framework service is most likely the Access Protection feature of AV.
You could remote to the machine with the console and pause the access protection, then make the registry change on the remote machine, then turn access protection back on.
I wonder if clearing temp files might help?
I look forward to the results you get.
we had the same performance issues here and at customers sites and it turned out, that not the epo agent DAT update itself caused the problems (at least not with VSE 8.7 with SP1), it's the startup of the OAS after the update. On startup the scanner does scan all processes in memory. Turning of this scanning option solved our problem (policy "VirusScan Enterprise 8.7.0 > On-Access General Policies", checkbox "Processes on enable ").
So you are saying that "McScript_inuse.exe" was using excessive CPU during the update? Or, was it another VSE process that was checking other processes ("Processes on enable") during the update initiated VSE restart? (Implying that the registry settings "LowerWorkingThreadPriority" and "NoUpdateUI" likely have no impact on originally stated problem.)
In any case, I would like to ask others their opinions of turning off this setting, issues found, potential security problems, etc.
In my experience, "McScript_inuse.exe" is causing some short cpu spikes during the epo update task, but only for a short moment and not annoying to the user (as I said: VSE 8.7 SP1).
The real problem has been a time of approx. 90s, in which the computer has become almost unusable: very high cpu util, mouse and keyboard very sluggish. The high cpu util has been caused by mcshield process. And no matter how we set "LowerWorkingThreadPriority" and "NoUpdateUI" settings.
And this problem does occur not only after the DAT update, it occurs every time we stop and start the OAS.
Disabling the "Processes on enable" option solved the problem for us in any case. Stations have been XP Pro SP2/3, Vista SP1.
Of course it would be nicer to leave this option enabled, but because of this performance penalty nobody wants this.
Some months ago I had a service request open with McAfee regarding this issue (without them pointing me to the right direction) and I offered a simple solution: decrease process priority of McShield from "high" to "normal" during the enable-phase (= process scanning). This solves the problem in most cases.