The way i do it is:-
1 - Disable Global updating in EPO ( Menu -> Configuration -> Server Settings )
2 - Create a new group in the system tree with a task that installs VSE 8.7 P4 (or what ever software you want) with immediate start schedule.
3 - Move selected computers into that group and send an agent wake up.
4 - Once done move the computers back to their original group
If you have multiple repositories you could create multiple 'install' groups and specify different repositories by creating a new agent policy for the group.
Note: I don't use directory sorting so couldn't comment on how this method could/would/should work under those circumstances.
Take a look at KB57905 which you can search from the McAfee Knowledgebase https://mysupport.mcafee.com/Eservice/templatepage.aspx?sURL=3 .
It will show you the various means that Patches can be prematurely deployed throughout your organization. We had global updating disabled, but it still went out to systems that were not part of our test group.
It is a pain to deploy patches as it leaked out to over 1400 of my systems. The only issues we had was with Thunderbird not working. This is due to a problem with exclusions longer than 15 characters, this is addresses byhotfix 613356 which you can get from support after running the MER tool.
Release Notes - McAfee® VirusScan® Enterprise 8.7i HotFix 613356
Thank you for using McAfee software. This document contains important information about this release. McAfee strongly recommends that you read the entire document.
About this HotFix
For a list of supported environments for VirusScan Enterprise 8.7i on Microsoft Windows, see McAfee Support KnowledgeBase article KB51111.
- Patch Release: 12-10-2010
This release was developed for use with:
- McAfee VirusScan Enterprise 8.7i Patch 4
- McAfee AntiSpyware Enterprise 8.7i
File name Version mfeapfk.sys 188.8.131.527 mfeavfk.sys 184.108.40.2067 mfebopk.sys 220.127.116.117 mfehidk.sys 18.104.22.1687 mferkdet.sys 22.214.171.1247 mfetdik.sys 126.96.36.1997 mfevtps.exe 188.8.131.527 mytilus3.dll 184.108.40.2065 mytilus3_worker.dll 220.127.116.115 mytilus3_server.dll 18.104.22.1685
Resolved issues in this release of the software are described below:
- Issue: When a Windows Server Backup is scheduled on a removable storage device and the backup storage device was unexpectedly disconnected the Plug-and-play event would be delayed waiting on file scans to the disconnected backup device, resulting in the system no longer adding and removing plug-and-play devices. (Reference: 588306)
- Issue: Kernel mode drivers should refrain from using more than 1kb of stack space when processing I/O. However when another filter is installed and attempts to filter McAfee's driver load attempt, both filters can then use large amounts of stack space resulting in a stack overflow and a double fault exception (BSOD). (Reference: 613356)
- Issue: On-Access Scanner attempts to mark the file as writable while accessing a file marked read-only, but fails to account for the case of 'read only' being the only attribute set on a file, attempting to set an attribute mask of 0 (i.e. - 'do not change attributes' when set). (Reference: 624132)
- Issue: Process names over 16 characters listed in the exclusion or inclusion fields of an Access Protection rule are not being recognized in Windows Vista or later. (Reference: 626033)
Resolution: File scans being performed on backup devices, that get unexpectedly disconnected, no longer prevent Plug-and-play events from occurring.
Resolution: Updates to the drivers have implemented a change to move stack usage to the heap in these instances.
Resolution: The On-Access Scanner now correctly detects 'read-only' as the only attribute set on a file and sets the 'attribute normal' instead, which has the effect of actually removing the read-only attribute.
Resolution: Access Protection rules now can handle process names greater than 16 characters in length.
Message was edited by: twenden on 1/18/11 9:27:05 AM CST
I was thinking of doing this also but in my configuration global updating is already disable. The thing is that as soon as I put the package (VSE patch4) in the current branch, all the PCs are downloading it....
I got several repositories but I guess that as they didn't download the latest version yet, when the PCs check they found the master server is the one having the latest VSE version and all are downloading on it...
do you think I can log on the repositories and manually copy the VSEpatch4 into the current_branch folder?
Do you have an update client task running against your groups?
Make sure you only have the 'Signatures and engines:' options ticked and everything under 'Patches and service packs: ' unticked within the configuration tab of the client task.
task.jpg 102.3 K
thanks Tristan !
yes I had this ticked !
so I will untick it and then put back VSEpatch4 in the current branch ! if my understanding is right, the repositories will then download the patch in their current branch folder, but no PCs will install it !