1 of 1 people found this helpful
The FIRST part of my "testing" involves NOT being on the bleeding edge with McAfee's releases. I will wait for a period of time and watch these forums or other intarweb sources for people b!tching that the new blah blah blah broke something and are never going to do blah blah blah again because it screwed them horribly.
Once I am satisified that the drama is over and the danger is minimal, I "test" by identifying a small group of systems 30-50 from as many disparate business units as possible and use them as pilot systems by use of a tag. I chose a small number, because it something goes wrong and the users are impacted, I need the group to be small enough that I can manually mitigate the issue in a timely manner.
I do not find it to be overly tedious as you only need to do it once. Any periodic updates to the list of systems will be handled on a onesy / twosy basis and are no big deal.
To address the other issues you are seeing; to manually tag a bunch of systems, I would do the following:
1.) Create a new system tree branch
2.) Import the systems into that group via text file and disable their system tree sorting.
3.) Create and apply the tag to all of the systems in the group. About 6 clicks of the mouse or so.
4.) Re-enable system tree sorting and allow the systems to go on their merry way.
5.) If these are not new systems to the ePO tree, you may have just created duplicate systems in the tree. No biggie, just run the query and delete the systems from the tree that do NOT have the tag you just applied.
If this qualifies me as a rocket scientist, I need to go speak to my boss about a raise.
Hope this helps or at least points you towards a possible solution for you as my answers may not be applicable with any additional context that was not shared in the post above.
Thanks for the reply. I think your process is better than mine, but still on the Monkey Science side of things, meaning a person is involved in the process and this isn't an educated process, just a monkey see-monkey click process. Seems like ePO having been around a number of years and being an enterprise level product would have a focus on patch certification processes.
McAfee posted an official guide, but I couldn't find it anymore on the kb. Give support a ring and ask them if they can hand it to you.
Alright, so after doing the monkey work, I'm now finding a crucial flaw:
I'm updating hosts between "minor" versions, example VSE 220.127.116.117 to 18.104.22.1685. To update hosts between minor versions an "update" task is used, not a "deployment" task. When using an update task, it updates the VSE to what is checked-in to the master repository "current" branch. (Correct me if I'm wrong or there's a way to update task to "evaluation" branch). Here-in lies the problem. I'm trying to qualify a piece of software checked-in to the "evaluation" branch. How do I go about updating 20-50 hosts to software checked-in to the evaluation branch?
If this were major versions, such as 8.7.0 to 8.8.0 a product deployment task could be used, which allows "evaluation" branch choices.
If I check-in the "evaluation" branch VSE to the "current" branch, I'm then forced to move the "current" branch to "previous" branch and then lose my "previous" branch version. The strategy of checking in evaluation software to a current branch, even if just for a moment, could cause any hosts that check in to accidentally be updated to the temporarily checked in "current" branch.
I could uninstall VSE and then force a script to re-install, but that's ridiculous to leave hosts without protection.
You can configure which branch each product uses for its updates as part of the agent policy - if you check the Updates tab on the General policy, you should see a dropbox for each product that allows you to select the branch to use.
Create a new policy and assign it to the machines that you want to use the Eval branch - that should do what you want it to.