V4 kills my server (backup?)

Hi,

I've installed V4 EAV onto our SBS 2003 R2 Premium server. I also have V4 on six other SBS 2003 R2 Premium servers.

On this particular server, since installing V4 the server has been hung every morning. So four days ago I uninstalled V4 and the sever was fine every morning. Yesterday I reinstalled it, and this morning it's hung again. So there's definitely an issue with V4 and our server.

Can anyone suggest where to start looking? I'm using the "default" file extensions, and all other scan options are defaults.

At present I think I have no choice but to uninstall V4 and either use nothing or revert to V3.

All suggestions welcome.


Many thanks,


Jim

 

This can't be helping:


Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7011
Date: 18/03/2009
Time: 03:00:31
User: N/A
Computer: SLFSRV
Description:
Timeout (30000 milliseconds) waiting for a transaction response from the ekrn service.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.




Jim

 

I'd suggest disabling advanced heuristics for newly created/modified files and enabling it for file execution. This should help in case you often back up files.

 

First..how are you protecting Exchange? XMON is only out for version 2.7....all my SBS clients run 2.7 on their servers.

Do you have the proper exclusions in your real time protection?
http://www.sbsfaq.com/Lists/FAQs/DispForm.aspx?ID=137

"Listed below are the items and their default locations - your installation may be different.

Exchange Server Database = C:\Program Files\Exchsrvr\Mdbdata (see note above)
Exchange MTA files = C:\Program Files\Exchsrvr\Mtadata
Exchange Message tracking log files = C:\Program Files\Exchsrvr\server_name.log
Exchange SMTP Mailroot = C:\Program Files\Exchsrvr\Mailroot
Exchange working files = C:\Program Files\Exchsrvr\Mdbdata
Site Replication Service (not normally used in SBS but should be excluded anyway) = C:\Program Files\Exchsrvr\srsdata
C:\Program Files\Exchsrvr\Conndata

IIS related Exclusions
IIS System Files = C:\WINDOWS\system32\inetsrv
IIS Compression Folder = C:\WINDOWS\IIS Temporary Compressed Files

Domain Controller related exclusions
Active Directory database files = C:\WINDOWS\NTDS
SYSVOL C:\WINDOWS\SYSVOL
NTFRS Database Files = C:\WINDOWS\ntfrs

Windows SharePoint Services
Temporary SharePoint space = C:\windows\temp\Frontpagetempdir

Additional Exclusions
Removable Storage Database (used by SBS Backup) = C:\Windows\System32\ntmsdata
SBS POP3 connector Failed Mail = C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\Failed Mail
SBS POP3 connector Incoming Mail = C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\Incoming Mail
Windows Update Store = C:\WINDOWS\SoftwareDistribution\DataStore
DHCP Database Store = C:\WINDOWS\system32\dhcp
WINS Database Store = C:\WINDOWS\system32\wins


Desktop Folder Exclusions
These folders need to be excluded in the desktops and notebooks clients.

Windows Update Store = C:\WINDOWS\SoftwareDistribution\DataStore"

 

Many thanks for the reply. These are the exclusions we have in place:

C:\WINDOWS\NTDS\*.*
C:\WINDOWS\NTFRS\*.*
C:\WINDOWS\SYSVOL\*.*
C:\Program Files\Exchsrvr\*.*
C:\Program Files\Common Files\Sage Line50\*.*

We're not protecting Exchange in any speocial way, just running v4.0.314 on the server.

If we disable the backup, the server is fine. If we uninstall ESET, the server s fine. But if both are enabled then the server hangs every day. Note that everythign worked well with 3.0.684.

At this stage I might go back to 3.0.684 (we have 4.0 on all the client machines. The sever is 100 miles away, so if it hangs I have to get the first people arriving in the mornign to pull the plug.



Jim

 

It is likely tripping up when it tries to scan the datastores. Your C:\Program Files\Exchsrvr\*.* exclusion only works for file in that directory, not sub-directories. You'll need to make specific exclusions for the datastores, log files, and all that fun stuff.

 

You're kidding, right? *.* doesn't exclude subdirectories? That's an absolutely mind-bogglingly stupid decision by ESET if that's the case.

The *.* suffix is added automatically when you say "exclude as a directory" as opposed to "exclude as a folder" in the ERAC config editor. That would mean that "exclude as a directory" was useless.

Are you absolutely sure?

Many thanks,



Jim

 

Exclude as a directory only auto-appends *.* to the end of what you select, so basically is saves you three keystrokes. I understand their decision to not allow exclusions for entire directory trees, as that would make it incredibly easy to create a massive hole on your in your server security assuming you configured something wrong and frankly, trying to exclude the entire C:\Program Files\Exchsrvr\ tree from scanning is the wrong way to do it. What if something exploits your Exchange services and replaces one of the exe's with a malicious one? You would have disabled all file system scanning there and would only catch it after the process gets launched in to memory and detected. By that point, you're screwed.

AV products typically have issues with database, log, and datastore files because they are under continuous read/write operations and you run in to file locking conflicts (I would guess your lockups are caused by that in addition to the shadow copy being created for the backup). Exclude these files and these files only, don't just give carte blache exclusions to an entire directory unless you have a program that is rapidly writing out files to a location with random filenames/extensions.

 

Ok many thanks. I've now created a more specific exclusions list:

<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\NTDS\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\NTFRS\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\SYSVOL\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\system32\ntmsdata\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\system32\dhcp\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\system32\inetsrv\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\system32\ntmsdata\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\system32\wins\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\IIS Temporary Compressed Files\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\temp\Frontpagetempdir\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\WINDOWS\SoftwareDistribution\DataStore\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\Program Files\Exchsrvr\Mdbdata\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\Program Files\Exchsrvr\Mtadata\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\Program Files\Exchsrvr\Mailroot\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="C:\Program Files\Exchsrvr\Conndata\*.*" />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="L:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="M:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="P:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="S:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="T:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="Z:\*.*" />
</NODE>
<NODE NAME="Exclusion" TYPE="SUBNODE" DELETE="0">
<NODE NAME="FullPath" TYPE="STRING" VALUE="Z:\DummyEntry." />
<NODE NAME="Infiltration" TYPE="STRING" VALUE="" />
</NODE>


and we'll see what happens. i'll need to reinstall V4 first, and I can't do that for a couple of days as we need to get a couple of successful backups. I'll report back.



Jim

 

Makes sense if you didn't have the following in the exclusion list.

Removable Storage Database (used by SBS Backup) = C:\Windows\System32\ntmsdata

I also uncheck "scan all files" on servers in the real time scanning extension section. Takes a substantial load off of the server.

Do you have something washing the e-mail? Like an SMTP smart host? Or using the POP3 connector that pulls mail from a POP3 host that washes the mail first?

 

I would agree...except I manage about a dozen SBS 2003 R2 servers for customers, and almost all of them now have ESET V4, yet only one server has this problem. Perhaps the others would have experienced it at some stage too Anyway, the exclusion is now there.

Good idea. I'll take a look into this, though to be fair the servers only have light load anyway.

We're not using the POP3 conenctor at all, our MX records point to the server's external NIC and we receive the SMTP email directly.

We don't have anything washing the mail. It's not ideal I know, but ESET's Exchange serve protection is too expensive (per mailbox), so we rely on ESET's V4's protection features on the clients.



Jim

 

You a brave man! It's like taking a trip to the red light district in Mexico without condoms.

I have a few dozen SBS boxes out there....I'm sticking to 2.7 until several program revisions of the upcoming XMON compatible with v4 is out and cooked more. I saw too many issues with v3 on servers..so out of the dozens and dozens of other non-SBS servers I have out there...they're still on 2.7 also.

Much lighter than 3 or 4....and since nobody "surfs" or does e-mail on a server....no reason for the boosted browser protection that 3 or 4 has over 2.7.

 

Agreed.

I came to ESET when V3 was current, I never experienced 2.7, so V3 is my "baseline". It's a shame ESET's pricing for Exchange protection is per-mailbox rather than per-store or per-SMTP connector, especially as we've effectively already paid for per-mailbox protection by having ESET installed on every desktop. Ah well...

I like your analogy though



Jim