Please excuse me if this is already indicated in documentation, but is there an inherent limit to how many agents a SuperAgent can support?
Here's the rationale behind the question. Presently our organization is considering deploying ePO in this fashion....
Regional ePO Server ------> Country UNC Repository ------> Remote Site SuperAgent pairing (One to download, the other to propagate, per recommended setup) ---------> Remote Site network segment (Agents/endpoints)
A Regional coordinator then asked the question: So, what happens if the Regional ePO server goes down? Now we have multiple SuperAgents throughout the country potentially drowning out the country's already-small bandwidth, all trying to get an update from McAfee Source, or elsewhere....
The gist is that the UNC Repository is simply a "dumb" share. Why not replace that with a SuperAgent--a Server with the same resources--so that it would have enough intelligence to go down the Repository list and pull from another source? This way, even if the Master Repository goes down, the SuperAgent can intelligently download from the source on behalf of all the other SuperAgents in a country.
So in effect, we'd have:
Regional ePO Server ------> Country SuperAgent pairing ------> Remote Site SuperAgent pairing ---------> Remote Site network segment (Agents/endpoints)
See my drift here? What are the downsides to this arrangement?Message was edited by: firstname.lastname@example.org on 7/28/14 2:58:10 PM CDT
do you have regional ePO servers that share the same DB with the main/HQ ePO?
Regarding your question: if the regional ePO is down, the UNC repository will get no updates. But as the Super Agents can reach the UNC repository I don't think they would look somewhere else (just see - oh - no new updates - ok)
Regional ePO servers at this time have their own DB's and Agent Handlers. At some point, we'll be staging the "HQ/global" ePO environment to which all the regions will eventually be connected---that aspect, I still have much to learn about (possibilities and limitations).
That's an interesting point you raise. I wonder if there's a way to set policies such that superagents start checking a different source if the parent Repository is not providing new updates after, say, a week...
If not, then it may well be the case that your point negates much of the benefit I saw in my original proposal above...