Exchange Server and Virus Checkers

Viruses are a part of computer life, and email is a common way to transmit them. The advent of viruses in spreadsheet and document macros increases the chance of infection in an email community. All Exchange Server administrators must consider how to prevent the spread of viruses. You can detect and disinfect viruses at three points in a messaging system: when the message enters your network, when the message arrives at the server, and when a user opens an email attachment at the client.

Router-based virus checkers typically check messages as they enter through gateways and connectors after they pass through a firewall, usually at the Simple Mail Transfer Protocol (SMTP) relay hosts. Content Technologies' MIMEsweeper ( is a good example of this type of product. You can use the latest version of MIMEsweeper to check messages before the Internet Mail Service (IMS) relays them to Exchange Server.

Server-based virus checkers check messages when Exchange Server stores them in the Information Store (IS) on the server. As a result, they are called store-based virus checkers. Many store-based virus checkers support Exchange. Trend Micro's ScanMail for Microsoft Exchange ( was one of the first store-based products. Many others, including Symantec's Norton AntiVirus 1.0 for Microsoft Exchange ( and Dr Solomon's Anti-Virus Toolkit for Microsoft Exchange (, have joined it.

Client-based virus checkers catch infected files. When a user opens an attachment in an Exchange message, the system creates a temporary file. The client-based virus checker screens the temporary file for viruses. Client-based virus checkers are effective at stopping infections from disks and other external sources. However, using PC-based checkers isn't foolproof, because this defense is effective only to the extent that the entire PC community uses virus checkers. Each unprotected PC is an avenue for infection. Depending on a mailbox's permissions, a client program might not be able to update the public folder with disinfected content. For example, if your mailbox has only read permission for a public folder, you can't replace the infected file with your disinfected copy, because Exchange treats the replacement as an edit function. Therefore, a virus can spread even after the program has detected it.

Ideally, you need to use all three types of virus checkers to achieve maximum protection. However, if you can pick only one type, store-based detection is the best way to stop email viruses, because every client must connect to the server to fetch messages.

In this article, I'll explain how store-based virus checking works and how it affects servers. Although I have a favorite store-based product, I'm reluctant to endorse a virus checker because new products come out frequently. Instead, I'll offer some guidelines to help you select a product.

How Store-Based Checking Works
Exchange Server contains no hooks, or event mechanisms, that a program can use to intercept messages before they arrive in a mailbox. Messages travel to the Message Transfer Agent (MTA) either directly (if they come from another server in the same site) or via connectors. The MTA delivers the message to the IS, which updates the recipients' mailboxes and notifies clients that new mail has arrived. Screen 1 shows the store-based virus checker ScanMail in action; you can see the log registering messages as the program scans them.

Because Exchange Server doesn't have an event mechanism to advise the checker that messages are en route, the checker has to constantly scan for new mail. The lack of an event mechanism also means that the product must check across all the mailboxes on a server rather than residing at a common choke point, such as the MTA or a holding area. To avoid constant scanning, virus checkers use Messaging API (MAPI) to log on to each user's mailbox to access messages and attachments. Obviously, because Exchange Server delivers messages to mailboxes without intercepting the messages, virus checkers must race with users to access content. In most cases, the virus-checker program reads new messages before users do, but a user might get to a message first, and the contents could infect the user's PC.

Microsoft knows that programs such as virus checkers need server-based events, so you can expect a future release of Exchange Server to include a feature that lets third-party programs register events that must occur before messages get near a mailbox. This step will greatly simplify virus checking and make it more effective.

Logging on to user mailboxes imposes an additional load on the IS. Anecdotal evidence suggests that virus checkers have contributed to some database corruptions, but I'm skeptical. I've used a store-based virus checker since 1996, and I've never seen a problem. Checking out customer references for a product before you buy is one way to avoid database corruption.

Store-based virus checkers can affect upgrades. For example, three Microsoft articles, "ESEUTIL /g Returns Error -1022" (, "Upgrade to Exchange 5.5 Fails If Virus Software Is Enabled" (, and "Err Msg: Unexpected NT API Error: 0xC000000D" (, document problems with Computer Associates' Inoculan virus checker during upgrades to Exchange Server 5.5. The general rule here is to disable or uninstall any store-based checker during any upgrade to a new version or service pack and to never restart the product unless you are satisfied that the vendor has validated it against the new version of Exchange Server.

The Impact of Checking
Every product you run on a server uses system resources. A virus checker doesn't usually generate many disk I/Os, but it does demand some CPU and memory to process incoming messages. The question is, "What impact will a virus checker have on my system?" or "Will users notice any difference when the virus checker is active?" The answer is that your mileage will vary according to the number of active users, the number of incoming messages, the percentage of messages that have attachments, the type and content of the attachments, and the existing system load. Other factors, such as other active programs, can also steal CPU cycles that you might blame on virus checking.

Because the performance equation has many variables, you can't say with certainty what impact a virus checker will have on your system. However, you can roughly predict the effect by using the Microsoft Exchange Server Load Simulator (LoadSim), which simulates MAPI client load on Exchange Server systems. Vendors have built all the store-based virus checkers on MAPI. Therefore, you can use LoadSim to identify how much a virus checker affects system capacity. (Greg Todd describes the tool in detail in "Understanding and Using LoadSim 5.0," Windows NT Magazine, January 1998, February 1998, April 1998, and May 1998.)

To assess the virus checker's effect, run a successful simulation, then repeat the test after you enable virus checking. The reduction in the number of supported clients between the two simulations is the net effect of the virus checker. Don't worry if you see a reduction in the 5 percent range. I've typically seen that percentage reduction in the simulations I've performed for customers. Good operating practice is to never run a server past 80 percent capacity so that you leave enough capacity to accommodate peaks in user demand. However, if the reduction in supported clients is 20 to 25 percent or greater, you need to determine whether any variables differed in the two simulations. If all the variables were identical, consider using another virus checker.

If you don't want to use LoadSim to determine a virus checker's effect on performance, you can ask vendors for their opinion. You can also ask consultants about results they have observed.

Selecting a Virus Checker
When you evaluate a virus checker, first consider the points you need to review for any third-party Exchange Server add-on, then consider specific questions about detection and eradication of computer viruses. For any add-on product, ask the following questions:

What versions of Exchange Server does this product work with?

Does the product require a specific service pack or version of Windows NT?

How soon does the manufacturer update the product after Microsoft releases a new Exchange Server version or service pack?

Does the product support Exchange Server running on Microsoft clusters?

Does the product support all the desktop clients deployed in a specific environment?

Does the product require any update to desktop clients?

Is the program well integrated with Exchange Server and Microsoft Outlook?

What platforms (i.e., Intel and Alpha) does the product run on?

For international deployments, what server and client languages does the product support?

How well does the vendor respond when problems occur?

With respect to virus checkers, ask these additional questions:

How effectively does the detection engine discover viruses?

How often does the manufacturer update the detection engine to handle new viruses?

Does the product check the server or desktop clients?

What clients (e.g., MAPI, Web browsers, Post Office Protocol 3—POP3, Internet Message Access Protocol 4—IMAP4) does the product support?

Can the product detect viruses inside compressed files?

What happens when the product detects a virus? Does the virus checker automatically disinfect the file and deliver it? Does the product notify the administrator?

Vendors can answer many of these questions, and they're usually happy to describe how good their detection software is compared with their competitors'. References from current customers are the best source of information about quality of support and ease of deployment. Most vendors let you download 30-day evaluation kits from their Web site. As always, getting your hands on real code is the best way to find out which product best suits your needs.

Just Do It
You need to protect your servers and users from the havoc that a runaway virus can wreak. Virus-checking products are available, so take the time to make a decision about the right virus checker for your environment.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.