I have the same problem. There is a task stuck in on my client workstations that is not on my EPO server. The task looks like an old AutoUpdate from version 8.5. We are on 8.7i now. I have removed all the EPO tasks, forced policy updates, and all the deleted EPO tasks that were on the clients are gone accept this one. I need to get rid of it because when it runs at 5pm every day the client systems experience 100% cpu usage for about 5 minutes.
I found where the task exists on the client systems in the registry and in "All Users" but don't a have a clean way to delete them. Thanks, John
I'm running into the same issue...I migrated to a new ePO server and a new update task was created on the new server (existing task was NOT migrated). However, the old task remains on the clients and some even have an ancient task from the 7.X days. I can't for the life of me find a way to blow away the existing tasks.
jmumme - I'm curious about where you found these tasks in the registry. Are you able to remove the tasks manually?
In the EPO Administrator select Systems then Policies
Select Viruscan 8.7 in the product drop down
Select to edit the User Interface Policies
Check the checkbox to "Disable default Autoupdate task schedule"
The default AutoUpdate task is already disabled. The tasks in question are managed (created by us, not default tasks) left over from an old ePO server that we migrated away from. The old tasks were not carried over to the new server (on purpose).
You had mentioned finding the tasks in the registry and in the "All Users" profile, I was curious about that information.
There are three tasks listed here. Which coincide with the three tasks I have in EPO, (under the group my system is part of).
I guess you should see if you have additional items in the registry that are not in the tasks on your EPO server.
I agree that you should only see the new tasks, and not the old. Maybe try moving a system to a new group, wake up the agent while watching the agent status window and see if the tasks get removed. Then move it back into the original group and connect again to see that the new tasks are applied. If that doesn't work, I would uninstall/reinstall the agent, with force if need be.
My problem was the "default" was not checked.
I've got one that's really bad. I went to change the policy on a single machine and instead disabled the autoupdate task on my ENTIRE organization. So, I did what anyone would do. Go remove the disable checkmark and do a full server wide wake up to get the new policies. Since then my machines all show that the auto update task is disabled STILL even though I removed the disable checkmark and made sure it is applied from the top level down. Any help on why undoing that change is now working? My own machine is not working and I can go sync policies, and even reboot the machine but the auto update disk still shows disabled.
Unfortunately disabling the default autoupdate task is a one-way operation at this time - but you can easily create a new update task and assign it to the machines: that will have the same effect.