Urgent- Exchange Store stopping w-XMON after 2022 update ??

I agree- where does it state anywhere to exclude these?

 

Microsoft have always recommended excluding those folders http://support.microsoft.com/kb/823166 - I'm sure I've read about it in one of the NOD32 PDF's too.

Unfortunately I have a tendancy to just exclude the whole EXCHSRVR folder and subfolders which doesn't seem to work.. looks like you literally need to specify the folders as per Blackspears post.

 

We had the above dirs excluded from the Amon on our sites, the issue still occured... Only solution i found to work 100% was to disable Xmon.

As a side note.. Eset are on the ball and a solution is not far off.. currently testing a patch and it has appeared to resolve the issue on the first 6 sites i have rolled it out to.. I would assume it won't be long before Eset release a fix..

 

this is what the manual states:

XMON scans e−mail messages stored in the MS Exchange Server storage. This storage is placed on the server file system as a single file and using non−standard settings in AMON (on−access scanner) running on the same server might lead to collision between XMON and AMON. To avoid the collision make sure that the AMON module is not set to scan all files. If you have set AMON to scan all files (not recommended) exclude the following two directories from scanning:

%ProgramFiles%\exchsrvr\mdbdata\
%ProgramFiles%\exchsrvr\mtadata\

 

Exchange store crashed again ~20 minutes after implementing work around....
(possibly on mail collection or encountering an infection ? ? ? ) , I have disabled XMON again and await the update.

 

Yep – Gratz on the efficiency of response to all involved.

If anyone hasn't experienced this style of exchange info store issue before please consider: http://support.microsoft.com/kb/842000/en-us

Strangely, I received no benefit from the post:

Obviously you weren’t using a particular gateway around Christmas when they took 2 days in Asia Pacific to even acknowledge that an issue existed!

 

Count me in on this. Exchange Information Store would crash, start, and crash again. Disabled X-Mon and I'm back up. What is in the 2022 update that is causing this problem?

 

yes, you would be correct. i was not in the asian pacific around christmas.

 

To be honest... Eset have been very quick to respond and rather helpful, Having recently changed from another vendor and not having had to deal with an issue with Nod32 I have been pleasantly surprised at the speed and efficiency the matter has been dealt with....

 

Add me to the list.
Exchange 2000 sp4 on Server 2000. 10:30 (31-1-07) this morning it fell over. Disabled amon and it still crashes. Disabled xmon and still won't start. Uninstalled nod32 and it is now running okay again.

 

here is what i would like to see from any software vendor, but particularly one that produces a mission-critical piece of software that is continuously updated:

they have a database of all of the email addresses of their registered owners. they know which owners have which products. when a patch or update is released that causes problems with several systems, and it is clear that there may be a problem with that patch or update, zip out a brief (one or two sentences) email to all owners of that particular product telling them that they may experience problems with that patch or update, but that a revised patch or update will be issued soon.

that way, system admins don't go poking around in other system settings trying to troubleshoot a problem with their email server that doesn't exist.

i don't see how that is so difficult or unreasonable to ask.

 

Well, yes.. It would be nice.. But, I'm still happy.... Ever tried to get help from Symantec or Mcaffee? ...... I highly doubt you'll get reply this quick... And no.. i don't have shares in Eset...

 

I don't get this one... why would you ditch a flawless product?

The reason we're getting updates is because there were new threats to deal with and there is a lot of unknown in dealing with these issues. An update went bad and I agree with your plight. I did my share of manager/owner convincing a couple months back myself.

In the grand scheme of things I've had a zillion updates since we joined up and this is the first time this has happened. Yep' an email would have been nice since I've been pushing the update button for the last 15 minutes and thought something was wrong with my system but Eset blocked me from getting the "bad" update and I appreciate that.

I would rather having them working on probs than sending out email.

Nod will get this fixed.... quickly.... that's just the way they are.

If your talking AV product... flawless doesn't exist... and NOD is about as close as you can get.

 

Fix 2023 released. Tested - OKAY

Now to re-install Nod32.

Shi_e happens. Purely by the speed and number of virus's nod catches I am still more than happy.

 

Yep- downloaded 2023. Seems OK.

 

It works!!! W00t!!!

 

Updates have now been rolled back and the update is now called 2023

All reports so far is that everything is back to normal.

ESET will investigate further as to the cause.

Cheers

 

Workin' good.. good work eset.... 7 servers updated... no further issues.. passed infected files through the exchange, picked up and cleaned..

 

Wow, what a day this caused for me. Didn't think of Nod32. Had several SBS 2003 Exchange Servers down with frustrated users. Was rebooting Servers and trying all sorts of workarounds for the 9175 Event. My God, I need a beer - what a drama. While working on one site, I noticed the Nod32 mirror update alert and then the Information Store just started. I tried updating Nod32 on another site and bingo, worked again. Then came here and realised just how many people were in the same boat. Thanks for such a quick work around but I really didn't need that much stress today.

 

I've just read the entire post and someone mentioned you need to set the exact exclusions for Amon, rather than parent folders. Can some one please confirm the following exclusions are OK for Amon or give a better list for SBS2003? This is what I currently have set for exclusions. I am only scanning default extensions.

C:\PROGRAM FILES\EXCHSRVR\
D:\EXCHSRVR\ - this contains the MDBDATA database folder for Exchange
C:\WINDOWS\SYSTEM32\INETSRV\
C:\WINDOWS\IIS TEMPORARY COMPRESSED FILES\

 

This has also happened to me, we have been running XMON flawlessly for over a year, and today I've had 4 exchange servers crash, took a while to isolate and fix. Very annoyed - grrrrr.

 

Could everyone please advise me what version of XMON was in place for the affected servers?

Cheers

 

Xmon version 2.51.15

 

My bad- in my frustration last night, didn't remember this. I went and checked my procedures, and Yes- I exclude the store and log folders. On all sites. So that was never the issue.

 

all working ok here too - XMON version 2.51.15 - if you need any more info just ask

thanks all for the help/suggestions and eset for the quick response

rob