cancel
Showing results for 
Search instead for 
Did you mean: 
random543
Level 7

Partial repository replication

Hi,

we're running ePO 4.5.4 with multiple UNC distributed repositories. Currently our repository replication takes up to 4.5 hours and slows our WAN considerably. The majority of this daily transfer is the avvdat-nnnn.zip file. Of course most of the users in the remote branch sites are on the network daily so rarely refer to this file but rather receive incremental DAT updates.

  • Can we exclude the large avvdat-nnnn.zip from daily replication?
  • Can it be replicated on weekends/after hours only? - but the incremental replicated immediately
  • If an endpoint was rebuilt and required an entirely new DAT would it grab a avvdat-nnnn.zip DAT which is a few days old and then perform incrementals or will it simply fail as the avvdat-nnnn.zip as stated in the avvdat.ini does not exist? Failing this will it fall-back to the master repository?

Any help to reduce the distributed repository replication would be gratefull.

Thanks.

0 Kudos
6 Replies
mischaboender
Level 11

Re: Partial repository replication

You might want to look into the LazyCaching feature of McAfee Agent 4.6.

Here's what the ePO 4.6 Product Guide says about LazyCaching:

How the cache works

When a client system first requests content, the SuperAgent assigned to that system caches that content. From that point on, the cache is updated whenever a newer version of the package requested is available in the Master Repository.

The SuperAgent is guaranteed only to store content required by the agents assigned to it because it does not pull any content from the McAfee ePO server until requested from a client. This minimizes traffic between the SuperAgent and the McAfee ePO server. While the SuperAgent is retrieving content from the Master Repository, client system requests for that content are paused.

0 Kudos
random543
Level 7

Re: Partial repository replication

Thanks for the option but it's not really what I'm after. I have ePO4.5.4 not 4.6 and also I'd like to be able to have the DAT copied out to our remote sites in the early hours of the morning rather than wait for the first device to request it. Also we use UNC distributed repositories not superagents so that would be an 'architectural' change.

I know that one option for me would be to handle replication outside of McAfee (such as robocopy scripts etc.) and exclude the large zip files. WAN accelaration/shaping won't work as the links are tiny so would run 24/7.

If an endpoint was rebuilt and required an entirely new DAT would it grab a avvdat-nnnn.zip DAT which is a few days old and then perform incrementals or will it simply fail as the avvdat-nnnn.zip as stated in the avvdat.ini does not exist? Failing this will it fall-back to the master repository?

0 Kudos
Tristan
Level 15

Re: Partial repository replication

If your looking at a way of managing DAT bandwidth usage to low bandwidth sites and your ePO server is on Windows 2008/2008r2 then the policy based QoS bandwidth management you have within group policy is a possible solution.

You can specify the total amount of bandwidth the server will 'serve' to a specific IP range/subnet/protocol/port range.

http://technet.microsoft.com/en-us/library/cc771283.aspx

http://technet.microsoft.com/en-us/library/dd919203(v=ws.10).aspx

Replication might take longer but the network hit will be less. The other option is to replicate your repos at night an not during the day

Message was edited by: Tristan on 29/11/12 10:05:53 GMT

Message was edited by: Tristan on 29/11/12 10:06:22 GMT
0 Kudos
random543
Level 7

Re: Partial repository replication

Thanks again for the response but we're using win2k3. Bandwidth throttling is usually done by our comms hardware not group policy anyhow. We like to keep this separate.

I think the type of configuration that I was after isn't achievable. Although there are lots of options (two mentioned above, thanks) they're not exactly what I was after. I may do the following; Remove the distributed repository at sites which have low bandwidth links. These clients can rely on incremental DATs. The incremental DATs will be cached on our Cisco WAS so copied to the site only once. The disadvantage with this is there will not be any full DAT stored/cached locally if an endpoint required it it could take hours to copy.

If I were to use the lazycaching option I'm not sure if the entire 'package' will be transferred at first request, not just the .gem and ini files. Remeber that the large avvdat-nnnn.zip file is part of the full DAT package.

Thanks.

Marking both responses as Helpful.

0 Kudos
McAfee Employee

Re: Partial repository replication


If I were to use the lazycaching option I'm not sure if the entire 'package' will be transferred at first request, not just the .gem and ini files. Remeber that the large avvdat-nnnn.zip file is part of the full DAT package.

Just to clarify this point, the caching is done at the file level - so if none of the clients on the site need the full zip, then it will not be downloaded. Only those files that the clients request are pulled over and cached.

HTH -

Joe

0 Kudos
mischaboender
Level 11

Re: Partial repository replication

Here's a nice YouTube video that explains the LazyCaching:


0 Kudos