V4 EAV BE on Servers - rolled back to 3.0.684

Hi all,

More take of woe. I manage about a dozen seaparate SBS 2003 servers, and on two I've now rolled back to 3.0.684.

With one, the overnight backup would hang the server. Reliably.

With the other, the backup would fail with "Error: An inconsistency was encountered in the requested backup file.". Reliably.

We're back to 3.0.684 on both, and all is well. In fact I'm even using the same XML file on both, so the configs are the same.

So, ten serers working happily with 4.0.417, and two needing to be rolld back to 3.0.684.

Just my experience....



Jim

 

I just got e-mail from support to update to newer 4.0.417 version. I was suspecting that they didn't fixed the problem crashing servers as promissed... can you please confirm that the servers which crashed were running version 4.0.417?

 

Jim, Were these two servers which crashed working as a file servers?

 

Yes, working a file servers.

Both are SBS 2003 R2. Both servers backup overnight to USB drives.

With one server, it would hang every day and would need the Big Red Button in the morning. Event viewer shows lots of these at around 03:51:

Code:

Timeout (30000 milliseconds) waiting for a transaction response from the ekrn service.

combined with some of these

Code:

The time provider NtpServer encountered an error while digitally signing the  NTP response for peer 10.0.0.95:123.  NtpServer cannot provide secure (signed) time to the client and will ignore the request. The error was: Not enough storage is available to process this command. (0x80070008)

(storage is plentiful, unless eset is gobbling up memory/disk)

With the other server, the backup would fail after around 7 minutes, and Windows explorer would show that USB drive disappearing and reappearing. Disabling realtime on the server would cure this, but adding the drive as an exclusion did not cure it. Interestingly, using ntbackup to backup to C: worked fine, and then copying the file manually to the USB drive would fail. So that rules out any issues with Volume Shadow Service and ntbackup.

Both servers are back on 3.0.684 and both are back to being solid again. The good thing is, rolling back to 3.0.684 is fairly painless, so I can try this stuff again in a few releases time I haven't the courage to put v4 back on for a while, due to lack of backups and unhappy early-shift users.....



Jim

 

Don't hurry up to upgrade production machines (a.k.a. servers) with the very latest new versions of any product . Why is this rush ? v3.0.684 works great , is time-tested and stable enough . You don't use the servers as workstations and you don't need the improved cleaning (I supposed) nor you need the integration of ESI .

I would recommend everybody use v3.0.684 on servers (Windows File servers) and NOD32 2.7 + XMON on Mail servers MS Exchange. You can , of course , try to upgrade some non-critical workstations to v4 BE . Don't get me wrong , not that the new version is bad , full of bugs or something something that . No! However , new versions are always something that will need more tech testing (than the Marketing and Sales Depts. have). Each and every company would rush a bit its new product but it will be us who may have problems if we rush , too.

 

I admit I installed V4 much sooner than I would normally do. But V3 was such a good product, and V4 had such a long beta cycle, that I thought it would work properly and without problems. It does, mostly....

Agreed, I'm happy with 3.0.684 on the servers, and I have 4.0.417 on the clients. It seems to work well as a combination.


Jim

 

and still is , right

 

No it's not. There is an issue on version 3 with error "Virus signature database could not be updated. Undocumented serious error (0x101a)" appearing on servers. Deleting *.dat files or reinstalling antivirus is fixing the problem but then it appears again after few weeks. You cannot restart your servers every few weeks. NOD32 developers know about the issue and not fixing it...

 

I was lucky, I only had that once or twice and I was able to reboot overnight. I never did understand the cause...

 

1, it's enough to end ekrn.exe, it will be restarted automatically and subsequent updates will work fine
2, the problem has actually been pinpointed and fixed just recently in v. 4.0.417.

 

I have seen this , too but I personally can't say it is something happening always and on regular bases .

Yes , just every few minutes

 

The 4.0 release was much smoother release than 3.0. Plus we didn't have to wait as long for ESET to release a newer build to address some bugs.

March 31, 2009 - 4.0.417
Fixed several issues in firewall module:
Detection for Conficker added
Fixed detection of TCP stream
Fixed detection of binary rules in ipv6
Fixed BSOD on Vista caused by entering mapped drives
Removed potencial deadlock during Windows log on process
Fixed detection for DNS cache poisoning attack
Fixes and changes in ICMP filtering
Fixed scanning of ARP
Fixed issue with disconnecting of routers and data transfer cards from internet
fixed: protocol filtering (correct displaying on list of certificates)
fixed: Settings of scanning size (GB) within archive is displaying correctly



As for the issue you're having, if you ever do plan to install 4.0.417, I recommend applying the recommended settings and exclude the backup software from the real-time scanner.


What are the recommended settings for an ESET security solution installed on a server? (4.0)
http://kb.eset.com/esetkb/index?page=content&id=SOLN2144

How do I exclude certain files or folders from real-time scanning? (4.0)
http://kb.eset.com/esetkb/index?page=content&id=SOLN2153


How do I exclude certain files or folders from the On-demand scanner? (4.0)
http://kb.eset.com/esetkb/index?page=content&id=SOLN2152