EPO4 - Master/Distrubited repositories

[gmc_za]

I have a single EPO4 server and would like to know if something like this is possible:

Large WAN envionment with EPO server at Location A.

Hanging off A are multiple major node branches - B,C,D etc.

Hanging off each major node are small sub branches. So off A there's X,Y,X

Currently all branches are superagents, so the EPO4 replicates updates to all sites.

If it possible to setup EPO so that updates are replicated to ABCD and then A replicated to XYZ and B to GHI etc etc instead of all updates coming from a single source - this is killing the WAN.

So for example at 2am updates would replicate to all major nodes. and then at 4am all major node would replicate to the minor nodes?

[Turift]

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.

Hope that helps.

[gmc_za]

So you have to have multiple EPO Servers? Seems a bit of overkill - then I have to control which clients report to which EPO server and duplicate the policies on each server? sad

[MilleRJ]

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.

Good luck

[Turift]

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.

[gmc_za]

Digging up a old thread here as I never got a working solution.

With the pattern files becoming so large the WAN is starting to take strain when it comes to distributing the files.

Maybe my original query was not clear.

We have a large number of WAN branches with slow links. Say 10 smaller branches connected to a major branch which then connects to us. (Multiple this setup by 10)

When it comes to doing a repository update the EPO server now replicates a 100mb of pattern files to 100 superagents all at once - thereby killing the WAN.

Is there a way to get the EPO server to replicate the pattern only to the major branches and then get the SA's at the small branches to replication their pattern updates from the major branches.

The pattern updates will therefore only be copied across the WAN once, as apposed to copying to 10 branches across the same link.

[jmaxwell]

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.

Hope this makes sense....

Jim

[gmc_za]

Jim,

I'm not following. When the EPO server replicates pattern files it will replicate from the master repository to the superagents.

Where can you setup the config for the superagents to only get their updates from a certain HTTP/FTP server instead of the master repository?

[MilleRJ]

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)

...and not

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...

Good luck

(Edited to insert underscores as spaces at the beginning of lines are stripped out)

[gmc_za]

Its more like the second diagram. I've uploaded a simple pic here

http://img22.imageshack.us/my.php?image=scan002sa7.jpg

I hope its clear enough.

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.