Overview of Exchange Server 2003 and antivirus software (823166)

SUMMARY

This article contains an overview of the different types of virus-scanning programs that are typically used with Microsoft Exchange Server 2003. This article lists advantages, disadvantages, and troubleshooting considerations for the different types of scanners. This article does not describe Simple Mail Transfer Protocol (SMTP) filtering solutions that are typically installed on a different server than the Exchange 2003 computer.

back to the top

File-level scanners

File-level scanners are frequently used, and they may be the most problematic for use with Exchange 2003. File-level scanners may be either 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 the files that are used on the hard disk and in 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 on a schedule. There are versions of antivirus software that start the on-demand scan automatically after virus signatures are updated to make sure that all files are scanned with the latest signatures.

The following issues may occur when you use file-level scanners with Exchange 2003:

• File-level scanners scan a file when the file is used or at a scheduled interval, and these scanners may lock or quarantine an Exchange log or a database file while Exchange 2003 tries to use the file. This behavior may cause a severe failure in Exchange 2003 and may also generate -1018 errors.
• 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 file-level scanners and memory resident file-level scanners:

• Exchange databases and log files across all storage groups. 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 directory.
• The Exchsrvr\Mailroot virtual server folder.
• The working folder that is used to store streaming .tmp files that are used for message conversion. By default, this folder is Exchsrvr\Mdbdata, but the location is configurable. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

  822936 Message flow to the local delivery queue is very slow

• 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 Services (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.
  
  Note You may want to exclude the whole Exchsrvr folder from both on-demand file-level scanners and memory-resident file-level scanners.
• The Internet Information Services (IIS) 6.0 compression folder that is used with Outlook Web Access 2003. By default, the compression folder in IIS 6.0 is located at %systemroot%\IIS Temporary Compressed Files.
  
  For more information, click the following article number to view the article in the Microsoft Knowledge Base:

  817442 Antivirus scanning of IIS Compression directory may result in 0-byte file

• For clusters, the Quorum disk and the %Winnt%\Cluster folder.
• Any messaging antivirus program folders.
• The Exchsrvr\Conndata folder.

Exclude the folder that contains the checkpoint (.chk) file from memory resident file-level scanners and on-demand file-level 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: Many file-level scanners now support scanning processes. This can also adversely affect Exchange. Therefore, you should exclude the following processes from file-level scanners:

• Cdb.exe
• Cidaemon.exe
• Store.exe
• Emsmta.exe
• Mad.exe
• Mssearch.exe
• Inetinfo.exe
• W3wp.exe

back to the top

MAPI scanners

The first generation of virus scanners that include an Exchange agent are 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. Therefore, the scanner may scan a single message many times if the same message exists in multiple mailboxes. Therefore, 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 even better options available than the MAPI scanner, and these are described later in this article.

back to the top

Virus Scanning API scanners

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

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

Exchange 2003 now includes Virus Scanning API 2.5. Virus Scanning API 2.5 includes the previous features of Virus Scanning API 2.0 in addition to the following improvements:

• Improved virus scanning API allows antivirus vendor products to run on Exchange 2003 servers that do not have resident Exchange mailboxes (for example, gateway servers or bridgehead servers).
• Virus Scanning API 2.5 allows antivirus vendor products to delete messages and send messages to the sender, and additional virus status messages allow clients to better indicate the infection status of a particular message.

Contact your antivirus software manufacturer for more information about updates.

When you use a virus scanning API 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 virus signature file has not scanned the content, the corresponding message component is submitted to the antivirus vendor product for scanning before that message component is released to the client. The client can be using a conventional MAPI client or an Internet Protocol (IP)-based client such as Post Office Protocol version 3 (POP3), Microsoft Outlook Web Access (OWA), and Internet Message Access Protocol, Version 4rev1 (IMAP4).

Virus Scanning API 2.0 and Virus Scanning API 2.5 processes all the message body and attachment data by using a single queue. On-demand items that are submitted to this queue are marked as high-priority. In Exchange 2003, this queue is now serviced by a series of threads, and high-priority items always take precedence. The default number of threads is 2 times number_of_processors plus 1. This makes it possible for multiple items to be submitted to the antivirus vendor product at the same time. Also, client threads are not 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.

Virus Scanning API 2.0 and Virus Scanning API 2.5 include a proactive-based message scanning feature. In Virus Scanning API 1.0, message attachment information is scanned only as it is used. In Virus Scanning API 2.0 and Virus Scanning API 2.5, 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, Virus Scanning API 2.0 or Virus Scanning API 2.5 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 the same time in the low-priority queue, and the contents of this queue are determined on a first in, first out basis.

Virus Scanning API 2.0 and Virus Scanning API 2.5 include an improved background scanning process. In Virus Scanning API 1.0, background scanning is conducted by making a single pass over the attachment table. Virus Scanning API 1.0 then submits attachments that have not been scanned by the current antivirus vendor product or signature file directly to the antivirus dynamic link library (DLL). Each of the private information stores and public information stores receive one thread to perform this background scan. After the thread finishes a pass of the attachment table, the thread waits for a restart of the information store process before it conducts another pass. In Virus Scanning API 2.0 and Virus Scanning API 2.5, each MDB Messaging Database still receives one thread to conduct the background scanning process. However, in Exchange 2003, 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 antivirus vendor product, and the scanning process continues. Antivirus software vendor products may also force the start of a background scan by means of a set of registry keys.

The feature that was most requested for addition to Virus Scanning API 1.0 is one that provides message details so that Exchange administrators can track the existence of viruses, determine how viruses penetrated the organization, and determine the users who are affected. This feature was added in Virus Scanning API 2.0 because scanning is no longer directly based off the attachment table.

Virus Scanning API Performance Monitor counters can be used to track the performance of the virus scanning API and to enhance troubleshooting in Virus Scanning API 2.0 and Virus Scanning API 2.5. By using these counters, the administrator can determine how much information is being scanned and how quickly that information is being scanned. This helps the administrator to more accurately scale servers.

Virus Scanning API 2.0 and Virus Scanning API 2.5 also include event logging that is specific to the virus scanning API. Events that are logged include:

• Vendor DLLs being loaded and unloaded.
• Successful item scans.
• Viruses that are located in the information store.
• Unexpected behavior in the virus scanning API.

back to the top

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.

back to the top

Additional reading

For more information about virus scanning software that is used with Exchange, click the following article numbers to view the articles in the Microsoft Knowledge Base: For the latest information about virus and security alerts and about virus protection software vendors, visit the following Microsoft and third-party Web sites:

MicrosoftICSA

ICSA Labs, a division of TruSecure Corporation, 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.Computer Incident Advisory Capability

Computer Incident Advisory Capability provides on-call technical help and information to Department of Energy (DOE) sites that experience computer security incidents.McAfeeTrend MicroComputer AssociatesSymantec (Mail Security for Exchange, Symantec Antivirus, and Norton AntiVirus)back to the top