KB55685 - Repository selection options for the ePolicy Orchestrator agent
KB59434 - Calculating the Subnet values under ePO repository
KB55133 - Client does not update from repository with the fastest ping although the option, Ping time was selected
You have two options from a brief read of the above KB entries
- Subnet selection: but this means the agent is going to connect to the nearest super agent ( which is what you want if your using super agents )
- User defined list: Will probably get you want you want but with 70 subnets will mean 70 policies which is unrealistic and a nightmare to manage.
My question is just for the first communication between agent and server.
I have no problem once the agent is managed to configure the repositroy intented in the Agent's strategy.
For some clients i use a script deploiement , forcing the sitelist.xml in the script. Is there something i could do to optimize the sitelist.xml deployed by pushing EPO agent from console ? As my server is reachable by almost all clients, i wish they check communication with it first instead of least.
1 of 1 people found this helpful
Sorry, but I think that is just how it works.
Even if your repository of choice was first in the list, all the other enabled repositories would still be pinged and the best repository selected at the end of the process.
The agent runs through the full list because it does not know which is best (unlike you )
Time-wise it would not matter if your repository was first, middle or last. The time taken to complete the selection would be the same. It depends on the number of enabled repositories.
Is there a way to decrease the timeout of the ping ? it appears to be 60s wich can be quite long with 100 repositories , even if it runs a few pings at the same time
More generally is there a way to edit the default sitelist.xml use by the console when pushing the EPO agent, as we cannot edit the default McAfee strategy ?
Ce message a été modifié par: fbollier on 23/11/10 09:02:38 CST
Not that I am aware of, no.
ok then, i'll try to use scripting as much as possible so .
Why won't you try the Agent Handler? They do repository cache, you can control witch agents are associated (by network, directory group, etc).
I have very slow network links as I manage about 100 shops , each one with 3 or 5 computers in workgroup, so i set a repository by shop.
I don't have the broadwidth nor equipement to set agent handler everywhere
Ok, I do understand that, but as I've mentioned earlier, the Agent Handler (AH) acts like a cache proxy for software. I believe that you have all VSE deployed and the only thing you must be concerned is with daily updates. So, when one machine requests the update (.gem or in worst cenário the entire dat file/superdat) AH will request it from Master Repository and will be stored locally. All other machines will get the update from there.
You can also do another thing. You can use the GLobal Update feature and everytime (you must control this) the Master Repository gets a new update (dat, superdat, hotfix, etc. - you can select what kind of update triggers it) it will send a broascast to all superagents (like, wakeup I've got fresh software ) and the superAgents will request (ASCI - and incremental replication) the update.
This is only to show you a few options that are available to you. You, being the IT Admin, knows better how things work.