We wanted to install VSE 8.8 patch 1 in a staged fashion therefore we created a product update task and set it to have VSE 8.8 patches checkbox enabled only. Also, we created the task itself disabled.
We have some other product update tasks, but nowhere is VSE 8.8 patches checkbox set (we have some VSE 8.5 and 8.7 patches enabled).
We then broke the inheritance on two groups related to this new update task and set it to enabled. The members of these group were around 350 computers.
Today we saw that approx ten times the number of computers have VSE 8.8 patch 1. I'm impressed by the quickness, but am help- and clueless scrathing my head, how could it happen?
I triple checked our product update tasks and where VSE 8.8 patches are set to install, those tasks are disabled (and inheritance does not break except for the one I mentioned above). All other update tasks that have VSE patch install set are for earlier versions, not v8.8.
We checked in patch 1 installer after the said tasks were created.
We have ePO 4.6.1 and agent v 18.104.22.1682.
Can someone give me a clue?
You should also check that global updating is disabled or you may see any new patch deployed automatically even if you don't have a task to do it (Menu->Configuration->Server settings->Global Updating)
I recently noticed this myself when deploying HIPS 7 patch 9. I have checked the following:
- Global updating is disabled.
- All containers had the product update task enabled but only for "Signatures and engines" package types(supported by existing machines not receiving the update).
- McScript logs show the patch installation performed immediately after the HIPS client installation on machines that perform a full installation of HIPS (new system build container).
- New build containers were the only systems that received the updated patch.
- Oddly enough a hotfix checked in at the same time was also deployed to these same new build systems.
My fourth point seems to be where the issue lies. I have an open ticket right now for a separate issue but did pose a question to the suppport rep and asked if a client is updated to the "Current" patch version during initial installation. Their response was "No" but this seems to contradict all of the data I have gathered to this point.
My guess is that any patch checked into the "Current" branch in the software repository will be called after an installation task has been completed. This may also be true for any hotfixes checked into "Current" but the McScript logs do not show an immediate update but rather the hotfix is called hours later. Unfortunately, I cannot find any documentation or discussions to support either of my claims.
What I would ask is, which branch do you have VSE 8.8 P1 checked into? And are you running a VSE 8.8 product deployment task on these same machines? If it is checked into "Current" maybe roll it back to "Evaluation" and see if you still have clients updating unexpectedly.
On a side note... Is there any documentation or forum threads that go into better detail on installation tasks?
I'm sorry not to have replied to either of you (Joe and Ulyses) so far. We do not use global updating, never did. And I could not just pick two log files out of any affected client,because we were ordered to deploy Patch 1 to all of them one day after the initial "pilot".
Frankly, my impression is that this could be a elusive bug somewhere. I had a support call for a very similar issue a while ago, but the technician doing the remote call could not reproduce it and when he created a new task with the same logic, it just worked.
I have checked the patch in the Current branch (we have a test system, so we do not have to really use Evaluation branch in production system - but in the future I might 🙂 ) Or rather use tags on tasks.
Normally we use VSE deployment tasks to replace, if any, missing VSE from systems. But that is a deployment and not an update task.
AttilaMessage was edited by: apoling on 05/06/12 10:59:34 CEST
You should still be able to get valid McScript logs from these clients. The agent logs have certainly rolled however and will probably not provide us with any good information. I would be interested to see the McScript logs as well so I can compare to what I have been seeing.