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
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.
