Believe it or not, but you may be over protecting your Exchange server against viruses without realizing it.
How can that be, and beyond that, what's the harm even if you are in some kind of "overprotection" mode?
The answer is that you can damage your Exchange Server if you implement virus scanning incorrectly.
If you want to learn how to avoid doing this and any potential consequences, I've compiled a list of some Dos and Don'ts that you may find useful.
First 'Do': Start with your workstations
Obviously, you want to give your Exchange organization the best possible virus protection. To do so, you should install an "Outlook aware" anti-virus program onto all of your workstations. Doing this will not only protect your workstations at the file level, but your workstations will also be able to scan new e-mail as it arrives.
At the server level, you should install a file-level anti-virus program so that the server is protected from file-level viruses. However, file-level protection alone isn't enough because a file-level virus scanner won't scan your server's mailboxes for viruses. By itself, file-level virus protection can also be very damaging to Exchange.
Because of this, you should install an Exchange Aware anti-virus program on top of the server's file level protection. This Exchange aware anti-virus software will scan the Exchange mailboxes for viruses and remove them before they are placed in a user's mailbox. In most cases, the Exchange level anti-virus software will also reconfigure the file level anti-virus software so that it will not be harmful to Exchange.
Unfortunately, Exchange level anti-virus software tends to be expensive, so a lot of companies tend to avoid buying special Exchange level anti-virus software, assuming that the workstation level anti-virus software will catch viruses when a user attempts to open them through Outlook. Although I personally think that Exchange level anti-virus software is a good investment, it is true that the client level software should catch mail viruses, assuming that the software is Exchange aware. If you do decide to go this route and only have file level protection on your Exchange Server, you need to reconfigure your anti-virus software to keep from causing problems with Exchange.
The first change that you need to make is to prevent your anti-virus software from scanning Drive M. Exchange 2000 reserves Drive M for the installable file system, which is used by Exchange system files. If your anti-virus software scans Drive M, then the most common side effects are that calendar entries will likely disappear from the user's calendars. Another common side effect is that Exchange will create a huge number of transaction logs as a result of the scanning. As if these particular side effects were not enough, some anti-virus software tends to corrupt the contents of the M: drive. The problem is that the files listed in the M drive are not really files at all, but rather are the contents of the database represented as files. Therefore, if you corrupt the M: drive, then you corrupt the database. This can lead to problems mounting the database in the future.
Don't scan output directory for viruses
In addition to the M: drive, you should also exclude the Exchange databases from any file level virus scans. To do so, you want to exclude the ExchsrvrMdbdata folder and any file with the extension of EDB, STM, or LOG. Although .LOG files are not technically database files, it is important that you exclude transaction logs and other types of Exchange log files from your virus scans.
Another component that you will want to exclude from file level virus scans is the MTA queues. If the MTA queues are scanned at the file level, not only do you risk corruption, message flow to the local delivery queue will tend to be very slow. The MTA queues are stored in the ExchsrvrMtadata folder. I recommend excluding the entire folder from your virus scans.
Likewise, you will also want to exclude from your virus scans any files related to the site replication service or IIS. By default, the Site Replication Service files are stored in ExchsrvrSrsdata, and the IIS system files are stored in %systemroot%system32inetsrv.
So far I have talked about all of the main Exchange system files that need to be excluded from virus scans. There are, however, some "working file" locations that you might also want to exclude, such as the ExchsrvrMailroot virtual server. You should also consider excluding the working folder used for storing temporary files related to message conversions. Normally, these temporary files are stored in ExchsrvrMDBData, which should have already been excluded. However, since you can configure Exchange to store temporary files elsewhere, it's worth double checking to make sure that the temporary file location really is excluded.
Finally, keep in mind that when you run off-line maintenance, such as using ESEUTIL to fix a database, the location that you run the utility from is used to create temporary files (unless you specify an alternate location). Although running ESEUTIL is not a part of day-to-day Exchange operations, it is important that if you ever do run this utility in an effort to repair a database that you do not scan the output directory for viruses.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, Tech Target, MSD2D, Relevant Technologies, and numerous other technology companies. You can visit Brien's personal Web sites at http://www.brienposey.com and http://www.relevanttechnologies.com.
