I have a EPO Server 4.5 with about 70 SuperAgents working as repositories on differents subnets .
When i push an agent installation from console, the sitelist.xml deployed contains the server and all the repositories..that is quite logical
However , by default, the new agent acts like it had a strategy with finding the most available repository by ping response time...why not.
But my problem is that the main server is the last one checked , and my new agent warns many firewalls when it tries to ping on others repositories, and it can take over 10mn to arrive on the main server.
Is there a way to order the sitelist.xml , so that the main server is on the top of the list ?
Sorry for my bad english , and thanks for your answers !
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.
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 CSTCe message a été modifié par: fbollier on 23/11/10 09:04:01 CST
Not that I am aware of, no.
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.
Just as an aside, if you have so few machines on each site, having a repository on site is very inefficient use of bandwidth... it would be far cheaper in terms of bandwidth to simply allow the machines to update from the master repo (or from a distributed repo on the same site as the ePO server, if you wish.)