Although last weeks issue (XP SP3) was related to AV, it would seem to me that some additional features in EPO (and corresponding integration with AV product) could have lessened the impact of the problem. My suggestion is to provide a testing phase in the EPO automated rollout of updates i.e. a way that the update can first go to a certain EPO group of corporate test PCs and have those test PCs report back their health after the update to indicate if there is any problem. The update would need to pass a percentage of the machines before being marked for full scale rollout (with some form of notification from EPO if various timetables were in jeopardy of not being met). If a problem is detected it alerts the Administrator and requests confirmation/remediation before proceeding with the full rollout. This minor change would have helped prevent widespread outages in this instance. It has the possibility (Companies can chose their level of testing/remediation ) of introducing a delay in the rollout of protection, but does allow corporations to weigh their options and chose what is best for them. I hope something like this is being considered.
Thank you Jkohut for your suggestions. Please use the form below to submit your suggested feature as an FMR -
Currently you can configure the pull task to check-in the daily packages into the Evaluation branch and configure agent policy to pull their regular DATs from the current branch. By configuring a test group
of machines to pull their DATs from the Evaluation branch, that day's DAT can first be tested and only after you are confident that no issue is reported, the DAT can be copied to the Current branch where the majority of the systems are set to pull their daily update.
Actually something like this already exists. Here are the high-level steps:
1- Configure your repository pull to Move existing package to Previous branch (its a checkbox in the pull task)
2- Assign an agent policy to the majority of your machines to update DATS from the Previous branch (policy setting on the Update tab of the agent policy)
3- Assign a different agent policy to your test machines instructing them to update from the current branch
In the scenario above the majority of your clients will end up being 1 day behind on their DAT files. This should not be a problem in normal circumstances but if you happen to be in a virus outbreak then it becomes important to have the latest DAT file on all clients ASAP. In that scenario you can easily for a short time either change the agent policy to have all machines update from the current branch or do your testing against the current branch and move the DAT file in the current branch to the previous branch after you have done your tests (in other words don't wait for tomorrows pull task to do it for you).
In normal "non outbreak" times the above should work fine. You will have roughly 24 hours to test the DAT release on the handful of machines you have updating from the current branch and when the repository pull brings in the new DAT files the next day it will automatically move the DAT package in the current branch to the previous branch so the rest of the clients can then get the updated DAT.
If you want a more manual process you could have the repository pull bring the new DAT file to the evaluation branch and have your test machines update from the evaluation branch. Then when you are done with your testing manually move the file from the evaluation branch to the current branch. Currently we have no mechanism to automatically move DAT packages from the evaluation branch to the current branch so if you wanted to do that you would need to submit an FMR.
Thank you to those who took the time to fill me in on the existing options/features. I have taken your information and fowarded it to our normal McAfee support personnel. I try and keep up a little with what AV is doing at our company (as an Analyst, I am involved in a numer of things from AV to OS to applications. I will let them create an FMR if they feel appropriate. My suggestion for automation of install testing (it doesn't really deal with application testing, simply install testing and overall health of the system to be able to respond. It seems that suggestion might have helped to alleviate the issue last week, as it is my understanding that the affected systems probably were not in a state to be able to respond after the update was applied) seems to have some merit, but if an FMR is required to get it enacted, then I will leave it to others to make that happen.
I'm figuring out how to set this up (evaluation and current) so our DATS can be delayed but I forgot about the unmanaged (ePO) Autoupdate task set to run at 5pm. Therefore even if I pull the new DATS down to the Evaluation branch, at 5pm the unmanaged autoupdate will run at 5pm.
Am I missing something?
Ok, found out where it is being applied.
VirusScan 8.7 - User Interface Policies: Disable default AutoUpdate task scheduleMessage was edited by: rwhitehill on 5/3/10 9:57:18 AM GMT-05:00
The update task itself should not matter as the repository selection is not determined by the update task but rather by the agent policy assigned to that machine. Just edit your agent policy and go to the updates tab and you should be able to see how to tell the DATS to update from the evaluation/current/previous branch.
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center