You could do it with ePO servers on all major node branches and then 1-2 superagents on all subnets. The superagents report to the ePO:s at each major branch, and they in turn report to the master ePO at site A. So you can control the replications from the different slave ePOs to the subordinate superagents. This is probably the way to go if you really want to lower the WAN traffic.
But you can also go to the automation tab and edit on Update repositories, choose action and select which repositories to replicate to. Then it's just a matter of duplicating that task and select the repositories you want.
No - you don't have to have multiple EPO servers. A server with a fileshare for the repository will do.
We have a UK wide WAN, with hundreds of subnets (branches, local offices etc). We have one ePO Server, but also have two other repositories geographically spread. With the ePO Server as repository as well it means we have a repository in the North, Middle, and South of the country. I configured clients to use the nearest repository by ping time - and it works very well.
It also depends on where your priorities lie - we want to ensure updates happen, so allow clients in the north to update from the south if that just happens to be the least busy repository. If you want to definately cut WAN traffic, but run the risk that updates may take longer, then you can tell clients to use a specific repository - but that was too much of a headache to track for me as clients wander the country 🙂
I've never used superagents, but my understanding is that if you have a superagent in each sub-branch, then normal agents will use the repository on the superagent instead of pulling updates across the WAN - but I could be wrong.
You don´t have to use more than one ePO if you don't want to.
BUT superagents is, not mandatory, but very advisable, recommendations from McAfee is two superagents on every subnet, one for backup. And that's good if you want to do an global update, if an emergency dat is out and you can't wait for the clients to initiate contact. Do a super-agent wake-up call, and it goes trough all of the super agents instead of directly from the ePO. Same goes for information back to the ePO.
The problem with ping time is that if you got better super-agents on say the northern site and they answer the agents wanting to update from the southern site faster than the closer one, you could potentially make the WAN link working in modem speed. Seen it happen. But works most of the time, so try it.
Haven't used fileshares as repositorys only super-agents so I can't say about that.
As mentioned before - the replication architecture you seem to require should be - set up an ePO Distributed Repository for each Major Branch on the central ePO Server which points to a UNC/HTTP/FTP area on a server at each MaJOr Branch Site - then define a couple of Superagent Clinet Systems in each Subnet associated with your Subsidiary Branches.
With this configuration/architecture the 100Meg only gets copied over the WAN to the Distributed Repoitories on the Major BRach Site Srrvers - all other traffic is local on the LAN between the Superagents and the Local copy on the Distributed Repository Data Server.
Reading this again carefully, I think I see the issue...
Time for a little ASCII Art...
I think your setup is:
CENTRAL ePO Server __+--Major Site A (with large No. of machines) __+--Major Site B (with large No. of machines) __+--Major Site C (with large No. of machines) __+--minor site x superagent (with small No. of machines) __+--minor site y superagent (with small No. of machines) __+--minor site z superagent (with small No. of machines)
CENTRAL ePO Server __+--Major Site A (with large No. of machines) ____+--minor site x superagent (with small No. of machines) __+--Major Site B (with large No. of machines) ____+--minor site y superagent (with small No. of machines) __+--Major Site C (with large No. of machines) ____+--minor site z superagent (with small No. of machines)
As said before, I've no experience with superagents, but I beleive they will act as a repository (allowing non-superagents to update from them rather than a standard repository.
With the first diagram, even if you have repositories at the Major sites, each superagent will probably be equidistant (in network terms) from each repository, and is just as likely to download from the ePO Server. However, if you have the second setup, and if you can get each superagent to look to it's respective Major site repository first, that should hopefully cut down on the traffic.
To do that I would configure the McAfee Agent policy to use either the subnet distance (if your network layout allows), or repository list order - with each minor site having a different order.
Your mileage may vary...
(Edited to insert underscores as spaces at the beginning of lines are stripped out)
At SiteA I have a EPO server which is also a SA. There's SA's in all sites with clients in all branches.
When EPO replicates is replicates to SA's at a,b,c,d,e which kills the line between A-B
I would like EPO to replicate from A to B and then somehow the SA's and c,d,e to pull their updates from B
The problem is in the replication of the pattern files not in the clients updating their pattern files - The clients in all branches are setup to get their updates from the SA in the local branch only so as to not impact the WAN.
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.
Community Help Hub
New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.