XADM: Understanding Virus Scanning API 2.0 in Exchange 2000 Server SP1

This article describes the enhancements to the virus scanning application programming interface (API) that Exchange 2000 Server Service Pack 1 (SP1) contains for Exchange administrators and independent software vendors (ISVs). This article describes new features, behavior changes, and troubleshooting suggestions.

Overview

The enhancements to the virus scanning API that are included in Exchange 2000 Server SP1 represent the commitment Microsoft has made to protecting our customers' messaging environment. These new features, known as virus scanning API 2.0, expand upon the features of virus scanning API 1.0. The following is a brief list of features that are available in Exchange 2000 Server SP1:

• Message details
• Native MIME/MAPI content scanning
• Proactive scanning
• Priority-based queuing
• Multithreaded queue processing
• Per-Messaging Database configuration options
• Enhanced background scanning
• Event logging
• Virus scanning API-specific Performance Monitor counters

How Virus Scanning API 2.0 Works

Virus scanning API 2.0 has three major areas of focus for scanning:

• On-demand
• Proactive
• Background scanning

As in virus scanning API 1.0, virus scanning API 2.0 continues to support on-demand scanning. As clients attempt to gain access to messages, either by using an Internet protocol-based client such as Post Office Protocol version 3 (POP3), Outlook Web Access (OWA), Internet Message Access Protocol, Version 4rev1 (IMAP4) or by using a conventional Messaging Application Programming Interface (MAPI) client, a comparison is made to ensure that the message body and attachment (if present) 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. In virus scanning API 2.0, this process has been enhanced greatly over the virus scanning API 1.0 implementation. In virus scanning API 2.0, a single queue processes all of 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 (the default number of threads is: 2 * number_of_processors + 1), with high-priority items always taking precedence. This allows multiple items to be submitted to the vendor simultaneously. In addition, 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 new feature in virus scanning API 2.0 is proactive-based scanning of messages. In virus scanning API 1.0, message attachment information was only scanned as it was accessed. In virus scanning API 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 of the high-priority items have been scanned, virus scanning API 2.0 begins to scan low-priority items. The priority of the items is dynamically upgraded to high priority if a client attempts to access 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 virus scanning API 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 vendor's 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 conducting another pass. In virus scanning API 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 comprise 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 most requested for addition to virus scanning API 1.0 is the ability to provide message details, so that Exchange administrators can track the presence of viruses, determine how viruses penetrated the organization, and determine which users are affected. This ability has been added with virus scanning API 2.0 because scanning is no longer directly based off the attachment table.

To enhance the troubleshooting of the virus scanning API, Exchange 2000 Server SP1 implements new virus scanning API 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, to more accurately scale servers accordingly.

The last feature is the new event logging that is specific to the virus scanning API. New events include the loading and unloading of vendor DLLs, the successful scanning of items, viruses that are located in the information store, and unexpected behavior in the virus scanning API.

For additional information about virus scanning API 2.0 registry keys, click the article number below to view the article in the Microsoft Knowledge Base: For additional information about new events in virus scanning API 2.0, click the article number below to view the article in the Microsoft Knowledge Base: