Internal Mail Virus Scanning on Exchange 2007 2

[timmoat]

Hi all,

Does anyone have any first hand recommendations/comments on any of the solutions for internal virus checking on a single Exchange 2007 environment?

My previous firm used GroupShield which was not superb if I recall!

Logically it would make sense to go with ForeFront, especially as it will natively gel with Exchange.

Inbound/Outbound mail is virus scanned by 5 engines by our email filtering company so this is only for internal use.

Thanks for any suggestions!

 

[58sniper]

I like ForeFront, especially the fact that it has multiple third party engines that can run in tandem. Very slick.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[timmoat]

Hmmm... just looking into Forefront on the licensing side of things and it sounds abit complex and we may have to commit to 3 years from what our reseller says.

We only have Exchange Standard & Standard CALS as we only have 65 users.

 

[Davetoo]

I've gone with the GFI product...I believe it has five engines running at the same time. Been doing a really good job so far, in combination with my Barracuda.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

There are no more PDC's! There are DC's with FSMO roles!

 

[Zelandakh]

Thumbs up for GFi. Thumb up for forefront.

 

[jveldh]

Hi,

Have a look at Trend Micro Scanmail 8.0 it's a nice product with nice features.



Regards,

Johan

visit my site:

http://www.johanveldhuis.nl

 

[58sniper]

for Forefront, you only need to buy the Enterprise add-on CALs for the users.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[xmsre]

One thing to think about and be aware of:

A lot of the AVAPI store scanners, like Trend since someone mentioned it, use memory mapped IO to improve scanning performance. A side effect of this is that the system cache creeps up over time.

In the real world, A single exchange server setup running hub/cas/mailbox also has monitoring, av, and a host of other things running on it. All of these things compete for memory. Exchange 2007 by default grabs 90% of available RAM and uses most of that for the DB cache. In fact, most of the IO improvements in Exchange 2007 are due to that large cache.

When a program tries to allocate memory, and there isn't any available, a system wide trim is triggered. The default behavior is to trim a lot, 25% from store.exe. Very quickly you can find yourself in the middles of a paging storm with no db cache as your system becomes unresponsive.

Back to the point. You'll want to take a look at

http://blogs.technet.com/mikelag/archive/2007/12/19/working-set-trimming.aspx

Having just worked though one of these with Mike, I can say with some experience this is a difficult issue to troubleshoot. After updating the kernel to modify the trimming behaviour, updating multiple drivers on the list (which has expended recently due to a lot of the things we tracked down)there was still a problem with trimming. When Available MBytes drops below 96, a systemwide trim starts. In the end it was the system cache creeping up, as a result of all the memory mapped IO, that would periodically cause a trim. The solution was to use cacheset to limit the system cache to a level where there would always be at least 96 Available MBytes.

Food for thought: seperating roles and funtions from the sever holding the mailbox server role minimizes the impact of memory pressure and working set trimming on Exchange. If the working set gets trimmed on your mailbox server, perfomance will tank and the server will likely become unresponsive. As an admin, we far to often "pile it on" and don't give it a second thought. That is a recipe for disaster. I'm not saying don't use AV. What I am saying is carefully review your architecture, goals, and options before arbitrarially loading stuff on the mailbox server. Ask yourself; Is this needed here? Can it be done at another tier or on another server? That goes for anything you would consider putting on your mailbox server. A little time spent considering the alternatives now will save you a lot of pain down the road.