Constant update errors

Hello,

I have a network with ~90 NOD32 clients, all connected to RA Server and configured to send me email when something bad happens.

Usually I get 100-200 emails a day with the following content:

Subject: NOD32: Error
5/18/2006 15:13:54 PM - During execution of Update on the computer X1, the following warning occurred: Update attempt failed (Server connection failure)

My question is: is this normal? Do NOD32 update mirrors malfunction such offen? Or is it something else?

 

Doesn't your NOD32 update from other servers at all? Do they all update from your local mirror?

 

No, NOD32 updates just fine. Clients are updating from native ESET mirrors.

I only asked why those mirrors are malfunctioning such offen. Let's take some math:

I have clients configured to update every hour. I recieve those warning 2-3 times a day from every client. So that's 10-15% of mirror server outages. That's too much, no?

 

The main question is why all clients are set to update from Eset's servers unless they have NOD32 installed on laptops.

If they actually use laptopts, then they are fine if they eventually update from other Eset's servers if one fails.

 

Because I don't want to rely on one major server that may be down. And yes, some of them are laptops.

 

Have the same problem here every day.

Tijd Module Taak Gebruiker
18-5-2006 15:07:33 Update Fout bij verbinding maken met server u4.eset.com.
18-5-2006 15:07:12 Update Fout bij verbinding maken met server 82.165.237.14.

Translated from Dutch: error connecting with server..........and so on.

I have the updating configured for automatic server selection.

 

Latops can update from our servers, but the other machines should update from a local mirror. One of the advantages is that when your license is due you will only need to replace the username and password on the server and not on all machines. Another advantage for updating from a local mirror is that this way you decrease the Internet traffic and, what's more important, more users can download updates simultaneously. For instance, if a client with 100,000 licenses updated every computer from our servers I doubt other clients would get their updates which would expose them to risk.

I wonder whether you don't trust your server reliability and whether it goes down that often that you are affraid of udpating from it.

 

One of the goals of having an enterprise versions of antivirus software, is streamlining your network..specifically...traffic. Yes other benefits such as creating configurations and pushing installs and eyeballing all clients from a local console. However...network traffic. You setup your head antivirus server, in Esets case..your RAS box. This is the main server...which is set to download updates from Esets server...and shove them to in the "mirror" folder. It checks by default once an hour for updates..and if any are available (both definitions, and programs)...it pulls them down, and shoves them into the mirror. This gives your networks internet pipe..which is usually lean..rather small (usually 1-6 megs), and already congested on a network of decent size..just 1x hit to perform the job of antivirus updates. Normally the clients would be configured to pull these updates from this RAS box...ideally using http..and this update flows across your high speed LAN (usually at least 100 megs switched). Clients are usually set by default to heartbeat with the RAS every 5 minutes for this.

Versus...
Having 90 plus clients all check for updates at 1 hour intervals...stagged in time, creates a lot of DNS requests...extra hits to your domain controller for DNS request. And if found...they start downloading updates individually through your small internet connection. Possibly clogging it up a bit. Actually with 90 rigs, unknown DNS load/efficiency, and unknown size of internet pipe and other network designs...I see it as quite likely that you would see a lot of errors relating to not finding resources on the internet.

Why not set all the workstations to pull from the http mirror? I have an aweful lot of them setup at most of my clients..it's quite a reliable setup.

 

I can certainly vouch for that. Our setup is similiar to the above, except with another server layer in there. Master pulls from Eset and mirrors the files. Each site server pulls from it (WAN link) and mirrors, then the clients all pull from their individual site servers via http (LAN link). Remote users pick up their updates via VPN from the master server. We support ~3500 clients and 17 sites that way.

Highly recommended.

Jack

 

I'm having the same as BENVAN45.
It is my Pc at home, so no serious problem, but yes, server availability may be better then recent weeks.
In this month I experienced this more often than in april

Tonight, manually updated from U8; that worked

Tijd Module Taak Gebruiker
18-5-2006 21:54:58 Update Updateverzoek afgebroken met fouten (Server connectie fout) THUIS-PC\algemeen
18-5-2006 21:54:02 Update Updateverzoek afgebroken met fouten (Server connectie fout)
17-5-2006 22:09:14 Update Updateverzoek afgebroken met fouten (Server connectie fout)
15-5-2006 21:43:45 Update Fout bij verbinding maken met server 82.165.250.33.
12-5-2006 22:51:15 Update Fout bij verbinding maken met server u8.eset.com.
12-5-2006 22:50:54 Update Fout bij verbinding maken met server 82.165.250.33.
9-5-2006 22:00:42 Update Updateverzoek afgebroken met fouten (Server connectie fout)
3-5-2006 22:33:45 Update Updateverzoek afgebroken met fouten (Download onderbroken.) THUIS-PC\algemeen
3-5-2006 22:32:43 Update Updateverzoek afgebroken met fouten (Server connectie fout) THUIS-PC\algemeen
3-5-2006 22:31:56 Update Fout bij verbinding maken met server 82.165.250.33.
3-5-2006 22:29:30 Update Updateverzoek afgebroken met fouten (Server connectie fout)


I guess you can read the dutch logfile
fout = error
afgebroken = terminated
Fout bij verbinding maken met = error connecting to

end of dutch lesson

 

This is due to limited connections to each server. However, if connection to one of the servers fails NOD32 should try to update from others provided that you have the update server set to "Choose automatically".

Therefore, it's important to use update from a local mirror wherever possible, otherwise if the number of simultaneous connections exceeds the limit other clients will not be able to connect to that update server and receive that error.

 

So, we should not configure updating set to "Choose utomatically"? I always understood this being the proper way.

 

It's strongly recommended to leave the default setting "Choose automatically" selected unless you update from a local mirror, or you may not get updates if there's a problem with a specific server.

 

We have a T3 connection and we don't pay for MBs, so 90mb/h traffic increase for me is nothing compared to complexity that I could face with one clients updating from local mirrors, others (laptops) from eset servers, etc. etc. I just don't think that number 90 is such a big number and worth extra maintenance work.

As someone posted here before, even at home, where I have 1 PC, I see update errors quite often.

I never saw update problems on other virus vendor servers (such as Norton, Kaspersky or Panda). Don't get me wrong, I like NOD32 very much, just think that ESET servers availability could be better. If someone knows where I could fill a complain about that would be great

 

It has been duly noted, you are on the NOD32 Official Forum

We also have this thread

Cheers

 

It indeed is if you imagine that every client would downlaod a 10-MB component update, it's 900 MB in total. If every larger client would do the same it could happen that you would get updates delayed a lot.

Also note that in the case of larger updates they are pushed gradually and not at once so not all your clients would get updated imemdiately if they all are set to update from Eset's servers.

 

Well, I never saw even component updates that big and they are released every quoter year or so. Usually virus definition updates are 100-200kb in size.

 

This thread is about Enterprise Edition..when you have a RAS box. One of the purposes of the RAS box is to be the source for definitions and program update...for all the workstations on the network the RAS box is a member of.

 

What complexity? If anything..it makes things tighter, more effecient! Even if you have a full T-3..it's not about not so much about being able to pork your bandwidth...but be efficient with it...and there is also the DNS loads. As a network admin...part of what we normally do is try to streamline networks, make things run more efficiently, and easier. Strive for the optimal design...and implement it.

 

I can only say one thing:
"I agree"

 

Yes, if we would live in perfect world . But sometimes you have to weight network perfection vs physical/material resources and to decide what is more efficient for your organization not for the perfect world, if you know what I mean.

Anyway this becomes a rant, I just wanted to know ESET their servers reliability could be better, that's all.

Thanks to all who replied! Bye for now.

 

Somebody from Eset correct me if I am wrong.....

Sometimes there are connection problems to the Eset update servers, whether because they have reached a connection limit, there is internet trouble, or whatever. This shows up in the Event Log. In such case, NOD32 will try to connect to another server in its list. HOWEVER, if there is a successful connection to the new server, this does NOT show up in the log unless it actually causes NOD32 to download an update.

In other words, unless you are getting errors for all of the NOD32 update servers within a minute of each other, you are actually connecting to an Eset server, somewhere. It is just that you are not told of the successful connection.

This may put you more at ease, ProTON.

 

100% correct

 

100% correct

I'd merely add that you are at higher risk with all PCs set to update from Eset's servers because in the event of a large update not all clients download it at once. If you used update from a mirror, you wouldn't experience this slight delay and would allow other 89 customers to connect to the servers instead of your redundant connections.