From what I remember, I thought this is all we did the last time we deployed a patch but I can not remember for sure. A list of steps to accomplish this would be great.
I did the same and it works fine.
I suppose you have already checked the prerequisites for the hotfix and they are in place in your environment (VSE Patch 6 or 7, ePo Extensions)? If yes, have you checked the Agent Log and observed the Agent Status Monitor while the update task is running?
Btw. collecting an sending props does not trigger the update task.
Actually, it did work (after some period of time), but only for 14 workstations out of 20. They are completely identical in terms of VSE patches and MA versions, and they all do report to ePO and get AV updates on a scheduled basis without any issues.
I haven't checked the Agent Log yet, but I did observe the Agent Status Monitor on one of those PCs that didn't get the hotfix -- it looks absolutely normal (it checks the policy changes, reports the status, but no traces of hotfix installation).
To be honest, I always thought that collecting and sending props does trigger the update task. This is how I usually deploy new Agents or VSE patches for test PCs, so I don't have to wait for a scheduled task. For example, I check in new Agent into evaluation branch, login to the test PC, hit collect and send props and get the update task triggered immediately, but may be the installation of hotfix is different... then I'm lost.
As far as I know you can trigger the update task on a client by one of the following ways:
- Sending WakeUp Agent Call from ePo with enabled "Force complete policy and task update"
- Opening the McAfee Console on client and start AutoUpdate
- Running mcupdate.exe on client
On my client when observing the Status Monitor I see that Patch 7 and HotFix 1123565 has already been installed.
What do you see on clients where Hotfix does not install? If you don't see anything usefull it would maybe help to compare Agent logs from a working to a non working client.
Thank you -- it does work. Those remaining 6 PCs have had msiexec in the running state from another service (SCCM most probably), which prevented the hotfix to be applied. Restarting fixed the problem.