5 Replies Latest reply: Feb 12, 2008 6:57 AM by metalhead RSS

    EPO Distributed Repositories Question

      Hello,

      I am currently trialling McAfee EPO on my business network with a view to rolling it out to support our 250+ client PC's and servers. We aim to use a central repository, with several distributed repositories at our regional sites.

      I have setup a test distributed repository to look at bandwidth usage when sending out the DAT updates. All we are using on the clients is AV 8.5i, so we only need to send the DAT and Engine updates to the distributed sites.

      At this point I should mention that we are using an ISDN dial-up network that cannot be upgraded for the forseeable future.

      When actioning a full replication of everything in the EPO package, the time is 2hr 13mins, with an incremental update taking 59mins.

      When actioning a full replication of just the DAT and Engine files, the time is 1hr 14mins, with an incremental update taking 1hr 1min.

      Is there any way to get the DAT updates out to our regional sites quicker with EPO, or is this product unable to support our network without this huge bandwidth consumption? Even downloading the .exe files and sending these out takes between 1-2 hours, as the .exe files are now 30+Mb.

      Can anyone offer advice on how to manage these updates with a slow network? Any pointers would be much appreciated.

      Regards,

      Tim
        • 1. RE: EPO Distributed Repositories Question
          metalhead
          As you already know with a new DAT fil at least about 40 meg will be replicated and there is no way to get around that because currently the amount as doubled because they must support and download signatures for VS80 (engine in mode 1) and compressed signatures for VS85 (engine in mode 2). When all McAfee products support the engine 5200 in mode 2 they can drop the support for the old DATs and replication traffic will only be half.

          The question in your case is if you really need distributed repositories. A cVSE85 lient which only updates to the newest signature version downloads only the last incremental file which is about 20-50 kb in size.

          So when it only comes to updating you must have a lot of clients to get over your 40 meg replication traffic.

          If you get additional cost for every ISDN dialup I would advise you to schedule a clients to communicate and update at the same time so that the line is only opened once for updating your AV software.
          • 2. RE: EPO Distributed Repositories Question
            Thanks for the reply.

            I have 8.5i running on the clients, and have trialled the updates. These update quickly over ISDN when connecting to the central repository, which is very useful to us in the dial-up environment.

            However, I have some clients that sit behind a server, and rely on it's connection to our central server for their updates, hence the need for regional/distributed repositories. It is these I need to find a quicker solution for, as the current DAT replication is taking too long.

            I can't rely on the sites themselves to manually initiate the call at a scheduled time to recieve their update, the staff are not very IT literate. I plan on scheduling a replication task every hour, so it will update the repository if they are connected at that time.

            With the current regional distributed repository task taking 1hr to complete a DAT update, this will mean the server is permanently replicating.

            Is there any way around this problem?

            Thanks in advance,

            Tim
            • 3. RE: EPO Distributed Repositories Question
              metalhead
              What do you exactly mean by "the clients sit behind a server" ?

              Also I was thinking of scheduling an update task via ePO which runs at a special time for these clients ...
              • 4. RE: EPO Distributed Repositories Question
                Tom,

                Sorry for the confusion.

                We have a central exchange server that the majority of the client PC dial in to, to pick up their mail from the mailboxes on the central server.

                We also have a few exchange servers that sit in our regional offices which dial in to pick up their mail. These then have 4-5 client PC's that pick up their mail from these regional servers.

                These clients 'behind the servers' rely on the server to dial in to the central exchange server to pick up their mail. We can't schedule in a specific task for these as the people using the regional servers dial in as-and-when they want to pick up any mail. They are not permanently connected as it is ISDN.

                Confusing isn't it?

                So, we want to make these regional servers act as distributed repositories for EPO to replicate with. Unfortunately the DAT update takes 1hr 1min over ISDN, so even scheduling an hourly task gets complicated.

                At the moment we email the .exe files from the McAfee website out once a week. We can't do it daily as it takes forever to download the files now they are 30MB+ in size.

                The clients PC's running 8.5i update in a couple of minutes from the EPO server, it is these problem clients attached to the servers that we need to fix.

                I think the only way we can do it is to get these PC's to dial in to the central EPO too, which is a bit more work for us, but might be quicker in the long run.

                The company won't pay for the ISDN network to be replaced!

                Thanks in advance,

                Tim
                • 5. RE: EPO Distributed Repositories Question
                  metalhead
                  Hi Tim,

                  but these clients behind the exchange server will never be able to communicate with yout epo server to get policies and tasks. Therefore they need a direct connection to your epo servers communication port.

                  So these clients are standalone client. As you must configure them locally you can configure them to update from an ftp repository and fill this repository manually. Then you only have to copy the files you need for VS8.5 updating.