6 Replies Latest reply: Nov 30, 2012 11:13 AM by JoeBidgood RSS

    Partial repository replication

    random543

      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.

        • 1. Re: Partial repository replication
          mischaboender

          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.

          • 2. Re: Partial repository replication
            mischaboender

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

             

            • 3. Re: Partial repository replication
              random543

              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?

              • 4. Re: Partial repository replication
                Tristan

                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
                • 5. Re: Partial repository replication
                  random543

                  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.

                  • 6. Re: Partial repository replication
                    JoeBidgood

                    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