What is your ERAS setup?

I've spoken to a couple of ESET techs and have gotten some mixed response regarding how the server and database should be set up.

Right now ERAS is running on a Windows 2003 server with two other enterprise applications running alongside: McAfee Endpoint Encryption (formerly SafeBoot) and Track-It (asset management).

Neither of these applications high-utilization, high-transaction programs. In other words, this is a fairly light-duty server.

The ESET SQL database is on another system entirely. We tend to segregate databases for easier management, backup, etc.

My question to you ESET Admins: What is your configuration and how has that impacted performance?

I'm thinking of moving the ESET database locally and wanted to get your thoughts. It seems like the better way to go but don't want to put the effort in without some real world input.

Thanks,
JJJ

 

Ours is a 1 CPU 512MB VM that is dedicated to ERA. Internal access database, 630 clients attached with 4.5 db queries/s. Disk I/O volume is tiny (100kB-250kB/s) during the day with 5% cpu load at its worst. The built-in HTTP host for update distribution was unreliable so we moved to IIS, which dropped CPU load considerably. It's really resource-lite unless something isn't configured right. If you aren't running it in a VM then I wouldn't hesistate to throw some other services on the same server.

Zero performance issues now that I'm on IIS, by the way.

 

Thanks Smacky. I have yet to experience the issues with the HTTP host for update distribution. Performance has been fine so far so I'm going to leave that be for now.

My biggest peformance issue was refreshing the list of clients on the console.

Why is my FirewallLog table so huge and how do I adjust how the clients report in? I'm poring over my client policies but cannot find it.

JJJ

 

Go in to the advanced settings on your ERA and look for this:

They're not labeled well, but those control how many records are saved PER CLIENT in your database. I've trimmed it down because for some of those records that generate a lot of noise (firewall, client events) I simply do not need more than the last handful back.

On the client side:

This controls how often clients phone back in to report status. This uses a tiny amount of bandwidth/resources and doesn't change how large your DB will be since the data from those events are going to get uploaded at some point regardless. I would recommend just leaving the clients on their default settings w/r/t reporting.