I'm updating our corporate VirusScan from 8.0 to 8.7 through our ePO server with the Deployment tasks and it's going rather well. I have noticed that the clients, when going through the update process, pull the 8.7 installation package from our Master Repository along with the subsequent DAT and Engine updates associated with v8.7 after the installation is done. This is causing a lot of network traffic when pushing this to the remote offices. We have several local repositories setup throughout our office locations that have the 8.7 install package and updates needed for 8.7 (DAT/Engine. etc.). Is there a way to have the clients pull the 8.7 installation and subsequent DAT and Engine updates from their local repositories when they receive the Deployment Task from the Master Repository?
I'm still learning all this but my educated guess is that since the Deployment Task is coming from the Master Repository, the clients pull the 8.7 installation package from there. This update causes the sitelist.xml file to become null and the subsequent DAT and Engine updates are pulled from the Master as well until the sitelist.xml file is reloaded. After the full update is performed the clients pull from their local repositories once again and all is well. Only problem with this is that I thought the sitelist.xml file was associated with the ePO agent and not the VirusScan app. BTW... we calculate the nearest repository by ping times.
Any insight would be greatly appreciated. I'm looking to make this roll out a little less network intensive if possible. happy
Has there been any update in this. I've seen the exact same problem upgrading from Agent 3.6/EPO Server 3.6 to Agent 4.0/EPO Server 4.0.
We have deployed almost 1500 machines so far, but the slower WAN sites are now flooding their links trying to pull the updated software from the Master Repository. All these slower sites have up-to-date repositories locally.
I think part of the problem is that we upgraded the Agent/VirusScan/AntiSpam/HIPS at the same time. I think this is not the advised way to do it. From my investigaton, I've read that it is best to have all the software at the same revision level between both servers and then upgrade the agent last, (moving management from the EPOServer 3.6 to 4.0 so no additional packages need to be updated
My problem now it that we have about 200 machines that reside on much slower WAN links that we cannot effectively deploy the updates to. Has anybody got any suggestions on how to reconfigure these to pull from their local repository automatically on first installation?
Has anybody used the McAfee Installation Designer to try this, or are there options within MID to do this??
Nothing.... I just finished pushing v8.7 to our Beijing and India offices little by little. I guess I'll have to call McAfee support and work with them on a possible solution or reason for this. I was hoping to get some insight with this post but at least I know I'm not the only one that has the same question.
perhaps it maybe to do with the XML scripts that are used (Sitelist) to give the order of the repositories. You should be able to set the default or top choice to be the local and not you master one, but of you are sending out the upgrade request from the master, then that's perhaps where the issue is - the external systems are taking their Q from the server requesting the upgrade and serving the updates.
MID package is really good idea, but i only of use it to do the odd manual installation - i have never tried to check in an altered application package, but i dare say it's possible to do so, so it deploys with the latest DAT and Engine update.
Solution: Create a McAfee agent policy specifically for the sites in question, and then in the Agent policy specify the local software repository and move it up to the top of the repository list. Then specify the next furthest repository as the fallback. Then ensure your master repository is replicated to all the remote repositorys.
Then create a install group in EPO for that office, create the client task to install AV, Dats, whatever, and then move your PCs into there and wake the agents up. This will mean you can upgrade your VirusScan, update the DATS, engines, etc all from that office's location using it's dedicated software repository. The only network traffic this method will take up is the software replication and the calls in and out of EPO to pick up the policies and client tasks.