Exchange and antivirus software

This article provides an overview of the different types of virus-scanning programs that are typically used with Exchange 2000 Server. The article lists advantages and disadvantages, and troubleshooting considerations for the different types of scanners. This article does not describe SMTP filtering solutions that are typically installed on a network server separate from the Exchange 2000 Server-based computer.

File-Level Scanners

File-level scanners are frequently used, and may be the most problematic for use with Exchange 2000 Server. File-level scanners may be "Memory resident" or "On-demand":

• "Memory resident" refers to a part of file-level antivirus software that is loaded in memory at all times. It checks all files that are being used on the hard disk and computer memory.
• "On-demand" refers to a part of file-level antivirus software that you can configure to scan files on the hard disk, either manually or according to a schedule. Note that there are versions of antivirus software that start the "on-demand" scan automatically after virus signatures have been updated to make sure that all files have been scanned with the latest signatures.

The following issues will occur when you use file-level antivirus scanning with Microsoft Exchange Server 2007, with Microsoft Exchange Server 2003, or with Exchange 2000 Server:

• File-level antivirus scanners scan a file when it is used or at a scheduled interval. The file scan causes a file to be locked when Exchange Server tries to access the file while it is being scanned. This causes an Exchange Server Information Store failure to lock the file. Eventually, this causes the file to become corrupted or unusable. All dynamic files that are used by Exchange Server must be exempted from file-level scanning. The core list of files that should be exempted are all .edb files, .log files, .chk files, and STM files. We recommend that all folder-hierarchy-containing files that are used by Microsoft Exchange Information Store be exempted from file-level scanning.
• More problems may occur if you scan drive M with file-level scanner software.
  
  The following is an example of an event that may be logged if the M: drive is scanned by file-level scanner program:

  Event: ID 6 
  Source: Norton Antivirus 
  The description for Event ID ( 6 ) in Source ( Norton AntiVirus ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote ccomputer.
  
  Scan could not open file M:\ORG_NAME.COM\MBX\User_Name\Inbox\No Subject-15.EML

• File-level scanners do not provide protection against e-mail viruses such as the "Melissa" virus.
  
  NOTE: The "Melissa" virus is a Microsoft Word macro virus that can propagate itself through e-mail messages. The virus sends inappropriate e-mail messages to addresses that it finds in personal address books on Microsoft Outlook mail clients. Similar viruses can cause data destruction.

Exclude the following folders from both "on-demand" and "memory resident" file-level scanners:

• The Exchange 2000 Server drive M.
• Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder.
• Exchange MTA files in the Exchsrvr\Mtadata folder.
• Additional log files such as the Exchsrvr\server_name.log file.
• The Exchsrvr\Mailroot virtual server folder.
• The working folder that is used to store streaming temporary files that are used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location.
• The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility.
• Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.
• Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.
  
  NOTE: The Exchsrvr\address, Exchsrvr\bin, Exchsrvr\Exchweb, Exchsrvr\Res, and the Exchsrvr\Schema folders are generally safe to include in a scan. However, you may want to exclude the whole Exchsrvr folder from both "on-demand" and "memory resident" file-level scanners. We strongly recommended that you temporarily disable file-based scanning software during operating system and Exchange upgrades; this includes upgrading to new versions of Exchange or the operating system, and applying any Exchange or operating system fixes or service packs.

For more information about the working folder, click the following article number to view the article in the Microsoft Knowledge Base:

Exclude the following file types from both "on-demand" and "memory resident" file-level scanners:

• .edb
• .stm (on Exchange 2000 Server)
• .log

Exclude the folder that contains the Checkpoint (.chk) files from "memory resident" and "on-demand" scanners.

NOTE: Even if you move the Exchange databases and log files to new locations and exclude those folders, the .chk file may still be scanned. For more information about what may occur if the .chk file is scanned, click the following article numbers to view the articles in the Microsoft Knowledge Base:

MAPI Scanners

The first generation of virus scanners that included an Exchange agent were MAPI based. These scanners perform a MAPI logon to each mailbox, and then scan it for known viruses.

The MAPI scanner has the following advantages over the file-based scanner:

• The MAPI scanner can scan for e-mail viruses such as the "Melissa" virus.
• The MAPI scanner does not interfere with the Exchange log or database files.

The MAPI scanner has the following disadvantages:

• The MAPI scanner may not scan an infected e-mail message before a user opens the e-mail message. The MAPI scanner does not prevent a user from opening an infected e-mail message if the scanner does not first detect the infected e-mail message.
• The MAPI scanner cannot scan outbound messages.
• The MAPI scanner does not recognize the Exchange Single Instance Storage filter, so the scanner may scan a single message many times if the same message exists in multiple mailboxes. Because of this, the MAPI scanner may take longer to perform the scan.

Because the MAPI scanner can detect e-mail viruses, it is a better option than a file-level scanner. However, there are better options available, and these are described later in this article.

VAPI, AVAPI or VSAPI Scanners

Virus Application Programming Interface, or Virus API (VAPI) is also referred to as Antivirus API (AVAPI), or Virus Scanning API (VSAPI).

VAPI 1.0 was introduced in Exchange Server 5.5 Service Pack 3 (SP3) and was used until Exchange 2000 Server. Many improvements have been made to VAPI 1.0 to improve performance with Exchange Server 5.5. For more information about this topic, click the following article number to view the article in the Microsoft Knowledge Base: Exchange 2000 Server Service Pack 1 (SP1) introduced VAPI 2.0. VAPI 2.0 is not supported in Exchange 5.5. VAPI 1.0 and VAPI 2.0 both support on-demand scanning.

When you use a VAPI scanner and a client tries to open a message, a comparison is made to make sure that the message body and attachment have been scanned by the current virus signature file. If the current vendor or signature file has not scanned the content, the corresponding message component is submitted to the antivirus software vendor for scanning before that message component is released to the client. The client can be using a conventional MAPI client, or an Internet protocol-based client such as Post Office Protocol version 3 (POP3), Microsoft Outlook Web Access (OWA), Internet Message Access Protocol, Version 4rev1 (IMAP4).

In VAPI 2.0, a single queue processes all the message body and attachment data. Items that are submitted to this queue as "on-demand" items are submitted as high-priority items. This queue is now serviced by a series of threads with high-priority items always taking precedence. The default number of threads is 2 * 'number_of_processors' + 1. This makes it possible for multiple items to be simultaneously submitted to the vendor. Also, client threads are no longer tied to "time-out" values that are waiting for items to be released. After items are scanned and marked safe, the client thread is notified that the item is available. By default, the client thread waits up to three minutes to be notified of the availability of the requested data before a time-out occurs.

A newer feature in VAPI 2.0 is proactive-based scanning of messages. In VAPI 1.0, message attachment information was only scanned as it was used. In VAPI 2.0, items are submitted to a common information store queue as they are submitted to the information store. Each of these items receives a low priority in the queue, so that these items do not interfere with the scanning of the high-priority items. When all the high-priority items have been scanned, VAPI 2.0 begins to scan low-priority items. The priority of the items is dynamically upgraded to high priority if a client tries to use the item while the item is in the low-priority queue. A maximum of 30 items can exist at one time in the low-priority queue, which is determined on a first in, first out basis.

The last area of improvement in the scanning process is background scanning. In VAPI 1.0, background scanning is conducted by making a single pass over the attachment table and submitting attachments that have not been scanned by the current vendor or signature file directly to the antivirus DLL. Each of the private and public information stores receive one thread to perform this background scan, and after the thread completes a pass of the attachment table, the thread waits for a restart of the information store process before it conducts another pass. In VAPI 2.0, each Messaging Database (MDB) still receives one thread to conduct the background scanning process. However, now the background scanning process navigates the series of folders that make up each user's mailbox. As items that have not been scanned are encountered, they are submitted to the vendor, and the scanning process continues. Antivirus software vendors might also force a background scan to start by means of a set of registry keys.

The feature that was most requested for addition to VAPI 1.0 is the ability to provide message details, so that Exchange administrators can track the existence of viruses, determine how viruses penetrated the organization, and determine which users are affected. This ability has been added with VAPI 2.0 because scanning is no longer directly based off the attachment table.

To enhance the troubleshooting of the VAPI, Exchange 2000 Server SP1 implements new VAPI Performance Monitor counters that Exchange administrators can use to track the performance of the virus-scanning API. These counters give the administrator the ability to determine how much information is being scanned and the rate at which that information is being scanned. This helps the administrator to more accurately scale servers.

The last feature is the new event logging that is specific to the VAPI. New events that are logged include:

• Loading and unloading of vendor DLLs.
• Successful scanning of items.
• Viruses that are located in the information store.
• Unexpected behavior in the VAPI.

You can determine if you are using a VAPI scanner by looking for the following registry key: This registry key does not exist if a VAPI scanner is not installed.

The following is an example of an event that could be logged if the VSAPI program scans the files through the //./backofficestorage/ path: For more information about problems that may occur if you scan drive M, click the following article numbers to view the articles in the Microsoft Knowledge Base:

ESE-Based Scanners

ESE-based scanners such as some versions of Antigen use an interface between the information store and the Extensible Storage Engine (ESE) that is supported by Microsoft. When you use this type of software, you run the risk of database damage and data loss if there are errors in the implementation of the software.


During installation, the ESE-based scanner changes the Exchange Server Information Store service so that it is dependent on the specific service. This makes sure that the service starts before the Exchange Server Information Store service starts. During the startup process, the scanner's service checks for appropriate versions of its software and Exchange Server, and appropriate file versions. If any incompatibility is found, the Antigen software disables itself, enables the information store to start without antivirus protection, and then notifies administrators.


When the ESE-based scanner starts successfully, the Microsoft version of the Ese.dll file is temporarily renamed to Xese.dll, and the Antigen version of the Ese.dll file replaces the original file. After the Antigen version of the Ese.dll file is loaded, the Microsoft version is renamed back to Ese.dll and the Exchange Server information store is enabled to complete its startup process.


Customers who contact Microsoft Product Support Services may be asked to disable the Antigen service to help identify issues, but customers are free to enable the Antigen software again after the root cause of the issue is properly diagnosed.

Additional Reading

For more information about Virus Scanning software that is used with Exchange Server, click the following article numbers to view the articles in the Microsoft Knowledge Base: For the latest information about virus and security alerts, and virus protection software vendors, use the following resources:

Microsoft

ICSA

ICSA, a GartnerGroup affiliate, provides Internet security assurance services.

CERT Coordination Center

The CERT Coordination Center is part of the Survivable Systems Initiative at the Software Engineering Institute, a federally-funded research and development center that is sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Network Associates

Trend Micro

Computer Associates

Norton AntiVirus (Symantec)

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.