Initial AV update is >175MB, eating my bandwidth

Apparently the BASE_END_USER_v18xxx.cav gets updated on a regular (daily?) basis, and the initial AV update from a newly installed client always wants this huge file. Subsequent updates are apparently using much smaller interim files.

If I install a group of clients, I need to babysit one of them to get a successful update, then my caching proxy helps with the rest of them, but if I do the same tomorrow I will be stuck again babysitting the first one to try to get a successful download. If I don’t babysit, then they all fail and eat my bandwidth.

Any way to manually download and pre-populate the client install with this initial file?

Hi,

This may be what you are looking for > Comodo Help, or maybe you just want these Comodo Anti Malware Database Latest Version & Additions 2022.

Remember that you are downloading a whitelist DB as well as a blacklist DB so it will be a little larger than the other guy’s blacklist only DB.

I am assuming you are doing the deployments after production hours though :slight_smile:

Kind regards,
Michel.

That second link looks useful. For future deployments, I’ll pull the latest DB from there and install it manually before letting them update over the network.

I have the following requirements that the AV need to fit in:

  1. the Internet is slow.
  2. I have a caching proxy on the network but I haven’t figured how to make it properly cache the huge files.
  3. One policy company wide to keep things simple. This rules out specifying a proxy in the policy because of remote users that don’t have one, it would kill their direct connection.

Due to the nature of our business there are no “off production hours” so I have to deploy whenever I can.

  1. the Internet is slow. > understood

  2. I have a caching proxy on the network but I haven’t figured how to make it properly cache the huge files > will be in touch

  3. One policy company wide to keep things simple. This rules out specifying a proxy in the policy because of remote users that don’t have one, it would kill their direct connection > create 2 parent groups, one for local users (apply proxy in policy) and another for remote users (no caching proxy). Can show you how to do this while we are ‘in touch’.

Kind regards,
Michel.

  1. Yeah, I know “how” to do it. It’s the additional complexity I’m objecting to.

Proxy and Host Settings seems to be the only thing I would want to be different between local and remote clients. Perhaps it would be a good thing if you had separate tabs for “Proxy and Host (local)” and “Proxy and Host (remote)” such that the same policy could be used.