I'm having some issues finding a scalable way of managing agent and VSE updates. What are other people doing to manage agent and VSE versions? My current strategy was to have each department create a Active Directory group and add machines to it...that was nixed once you realize that McAfee has their System Tree termonology wrong. mcAfee calls a "group" what should be called a container. Thus, McAfee does not see groups in AD. Next strategy is basically the same AD strategy, but doing a dsquery to pull out the members of the qualification groups. Problem then becomes you have to manually tag a bunch of machines. In reality tags are a terrible way of deploying qualification, as it's manual. You can't import a flat text file and apply tags based on this. So Strategy number two nixed. Basically leaving just one strategy and that's to manually tag stuff, the word manual terrifies me. Something as stupid as grouping machines for qualification shouldn't take rocket science, but with McAfee it basically takes monkey science to do something as fundamental as running a patch management program.
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.
Alright, so after doing the monkey work, I'm now finding a crucial flaw:
I'm updating hosts between "minor" versions, example VSE 22.214.171.1247 to 126.96.36.1995. 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.