Anti-Virus Solutions for Microsoft Exchange 2000 Server.doc
Anti-Virus Solutions for
Messaging and Collaboration
HP Industry Standard Servers
Microsoft Exchange 2000
Solutions & Strategy
Executive Summary .............4
Exchange 2000 and Abstract: The continuing onslaught of viruses spread by e-
Exchange 5.5 Differences...5 mail has caught the attention of mail-system Administrators
Phase 1 - Analyze the
and the general public, acting as a reminder of the need to
Background on Viruses.......6 protect our systems. This paper discusses the software virus
Phase 2 - Plan for Solutions 8 problem, and develops solutions for protecting Exchange 2000
Economic Justification.........8 Server mail systems from malicious software. This is an
Defining Borders of update to the original paper written for ActiveAnswers, based
Protection............................9 on Exchange Server version 5.5. Exchange 2000 is
Methods of Prevention or substantially different from its predecessor and the differences
Phase 3 - Develop the
are covered here. With a variety of vendors and products on
Solutions..............................16 the market, there are many different methods to solve the
Anti-Virus Software: problem. Example deployment scenarios are outlined and a
Selection Criteria...............17 comparison of product functionality and features is detailed.
Product Selection and
Deployment.......................20 HP Best Practices for an organizational deployment are
Phase 4 - Conduct Pilot presented in a generic six-phase implementation methodology.
Phase 5 - Deploy the
Phase 6 – Manage and
Research Organizations and
Sample Evaluation Criteria
for Selecting Anti-Virus
Best Practices Summary List
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 3
Secure electronic messaging is a relatively immature technology, and it presents an
opportunity for intrusion into networked computer systems. E-mail may be used as the
medium to attach viral applications, or may contain the virulent code itself, especially as
the capabilities of e-mail are extended via HTML and active content. In the past, it was
difficult to convince mail-system Administrators to protect their systems, as anti-virus
scanners introduce a level of risk to servers and mailbox stores. Recent viruses spread
by e-mail have caught the attention of the general public, increasing awareness of the
problem, and forcing most, if not all organizations to address the problem.
This document is specifically targeted at Exchange Server Messaging Solution Architects
and Mail System Administrators to protect against the threat that e-mail brings as a
transmission vector for viruses. It should act as a condensed overview of the problem
and provide a guide to the solutions. The structure of this document parallels a six-
phase implementation methodology: analyze, plan, design, pilot, deploy, and manage/
maintain. The better we analyze and understand the problem, the better information
we will have to develop comprehensive solutions.
HP Best Practices are highlighted on how to test and deploy these solutions. Products
designed to protect either SMTP gateways or Exchange mailbox servers are tested and
the effectiveness and performance results of each method are compared. Exchange
2000 offers new methods or APIs to scan for viruses, and the results are substantial in
performance and detection rates. With a properly sized server, the anti-virus resource
utilization and load impact is not statistically significant.
The conclusion is that current virus-scanning prevention technology is ineffective by
itself at preventing an initial viral outbreak, caused by a new virus. Current technology
focuses on eliminating the recurrence of known viral code. Just as an e-commerce
implementation involves more than pointing a Web server at a product database, an
anti-virus solution involves more than installing scanning software on an Exchange
Server. The most effective method of preventing losses due to viral payloads is to
implement a comprehensive solution that involves defining and implementing
organizational policies and procedures in the areas of network security, system
operations, and messaging content. A coordinated effort is required, and securing the
desktop operating system is recommended.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 4
Exchange 2000 and Exchange 5.5 Differences
Exchange 2000 brings substantial changes to the architectural design and deployment
issues of anti-virus software. We will discuss each of these in greater detail in this
• Web Storage System exposes access into the Store via HTTP-DAV (Outlook Web
• EXIFS – The Exchange Installable File System exposes access into the Store as a
drive (M:), folders, and items within the Store
• Multiple Storage Groups (up to 4) and Mailbox Stores (up to 5 per SG) per Server,
requiring Exchange 2000 aware anti-virus applications
• New type of database file for Internet protocols, (.STM), requiring Exchange 2000
aware anti-virus applications
• A New virus scanning interface: AVAPI and VSAPI v2.0 in Service Pack 1 (and later)
• Transport Event Sinks and Store Events, which allow custom code to be executed on
the server for functions such as anti-virus and content management
• Front-End (FE) / Back-End design allows for anti-virus placement on different server
types. FE servers can service Internet protocols such as POP3, IMAP4, SMTP, and
HTTP-DAV as proxies for OWA clients
• Revised clustering design on Microsoft Cluster Server (MSCS), including active/active
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 5
Phase 1 - Analyze the Problem
The first phase of the implementation is to determine the nature of the problem. To
develop the best possible solution, we must first fully understand the problem. Without
acknowledgement and awareness that there actually is a problem, it appears that no
action needs to be taken. The introduction of new viruses has been fueled by
improvements in ease of development (such as macro languages) and the ability to
share information and transmission via the Internet. The viral problem would cease to
exist, were it not for irresponsible individuals who lack the conscience or wisdom to
prevent them from randomly harming others.
Viruses are not directly related to or dependent on messaging products such as
Microsoft Exchange Server; however, e-mail has become the preferred transmission
method for viral replication. Many smaller organizations are becoming exposed to the
hazards of the Internet for the first time.
Background on Viruses
See “Appendix: Viral Information” for definitions of basic terminology. For the purposes
of this paper, the generic name virus will refer to all malicious software such as viruses,
worms, and Trojan horses. This section will briefly cover methods of attack and methods
of transmission. The key point is that while transmission has been made easier by e-
mail, the damage inflicted by the payload has escalated to the point of serious business
risk and financial loss. The history of e-mail viruses dates back to November 2, 1988
when Robert Morris Jr. released a worm onto the Internet that replicated via SendmailTM.
Methods of Attack
Viral payloads typically fall into one of three categories:
– System modification (corruption to software, files or hardware) and invasion of
privacy (unauthorized access to information) typically through installation of a
– Unwanted traffic or files (unsolicited e-mail and unwanted “joke” files)
– Denial of service: overloading or crashing component services and systems
Historically, file-based personal computer viruses replicated via diskette were the
prevalent form, but script viruses have been increasing in numbers because of the ease
of authoring. The vast majority of viruses are files such as attachments to e-mail;
however, it is possible now to send active content or links to active content within the e-
mail message body. The scope of attack has been increasing as well; from isolated
personal computers to networked computers.
One recent trend has been the shift from a delayed payload (a latency period, where the
virus is present, but remains dormant in the system) toward an immediate payload,
delivered when the user opens the message or file. For example, boot sector viruses
delivered via diskette were forced to remain latent until the system was rebooted.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 6
Table 1 illustrates how latency and payloads have changed, threatening entire networks
and companies, instead of just isolated personal computers.
Table 1. Changes in Latency and Payloads
Viral Type Latency Payload
Boot Sector When computer rebooted Damage PC / boot
Executable When operator executes Trojan Horse Loss of files, corruption of system
Macro When operator opens document attachment Loss of files, corruption of system
Applet When Web Page or HTML e-mail opened Loss of files, corruption of system, security
compromised, network intrusion or attack
Active Technologies1 Immediate Backdoor opened: Exposure of sensitive
information, loss of business in e-commerce
Methods of Transmission
As the personal computer has changed from a stand-alone system to part of larger,
networked systems, the methods of transmission have changed. Virus authors look for
the most rapid method of sharing files. Transmission methods have evolved from
storage based (floppy disks) to more efficient methods such as e-mail and potentially
even browser-based. Viruses may now be contracted via FTP downloading or as
attachments to unsolicited e-mail. The Melissa virus showed the world how easy it was
to automate the transmission via e-mail. The method was not even ingenious, using
widely publicized code. The payload was merely the transmission itself, expanding
exponentially with each instance. However, the Worm.EXPLOREZIP virus advanced to
the next logical level, not only delivering a destructive payload, but also changing the
subject line of the message with each automated reply. The effect of receiving a reply to
a previous message fooled the recipient into becoming a victim. The Nimda virus
escalated the methods of replication used by the Code Red virus to include many
methods of attack. Clearly, the methods of attack must be restricted in order to limit the
At the time of first publication of this white paper in 1999 these were emerging attacks, but are now quite prevalent.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 7
Phase 2 - Plan for Solutions
The second phase of the implementation is to develop a comprehensive plan to solve
the virus problem.
As with any project impacting the financial affairs of the business, it is important to
measure the cost / benefit ratio of the anti-virus implementation. Historically, figures
have been difficult to obtain, but recent viral outbreaks have given organizations the
opportunity to study and measure the cost of downtime, clean-up, and add protection.
Traditional ROI (return on investment) measures are inadequate, as anti-virus protection
can best be thought of as an insurance policy. The measure of benefit is the reduction
of risk exposure to the organization. It is beyond the scope of this article to measure
cost / benefit or to provide guidelines on how to measure. Look for information on cost
of projects from consulting practices, while benefit information can be obtained from
anti-virus vendors (who have measured the costs associated with down-time and
recovering from attacks).
Viral attacks have one (or more) of three characteristics: system modification, unwanted
content, and denial of service or system overloading. The virus problem is really the
intersection of these three areas. If we properly address each of these three areas, the
virus problem can be eliminated. Figure 1 shows the intersection of the affected areas.
Table 2. Affected Areas
Type of Attack Affected Area
System Modification (corruption to software, files or Network Security
hardware) and Invasion of Privacy (unauthorized access to
Unwanted Traffic or Files (Unsolicited e-mail and Content Control
unwanted “joke” files).
Denial of Service: crashing systems or component System Operations
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 8
Figure 1: Intersection of Affected Areas Defines the Anti-Virus Problem
Defining Borders of Protection
As part of the plan to protect the organization, we need to define the borders of
protection. Think of an organization as a closed system with limited points of entry (see
Figure 2). A complete virus protection program will need to cover the points of entry
into your organization. Intrusion can come actively as a break-in and attack, or
passively as a virus. Software to detect active intrusion and provide detailed information
is beyond the scope of this paper.
This section briefly discusses protecting your organization at the points of entry. Control
over these borders may be out of the control of Exchange Server Administrators;
however, protecting these points of entry is vital in preventing Exchange Server from
becoming a transmission method for viruses.
Figure 2: Viral Entry Points into an Organization
Tier 1: Client Email and Desktops
There are two primary methods of protecting clients or desktops: one is to run the same
type of real-time and file-based virus scanning as on file servers – scanning files saved
to disk, watching for a viral signature match. This method requires ongoing updates to
the signature database. Due to recent outbreaks of viruses, some vendors even offer
desktop anti-virus software, including future updates, for free. When combined with
regular backups of critical files, this provides protection against known viruses. Another
method of protection for the clients or desktops can be called “Dynamic Security” --
software that watches for the end result of viral behavior: destructive activity.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 9
The most effective method of preventing losses due to viral payloads is to implement a
secure desktop operating system and limit the power of the current logon context. By
limiting the power of the current logon context, viruses run under that context and can
be defeated by limiting permission to access critical files.
Another concern for viral intrusion, is the installation of backdoor applications that send
confidential data outside of the organization. Unless users are educated on the dangers
of installing unapproved programs, the likelihood of so-called ‘spy-ware’ or other
backdoor intrusion is high. Users need to be similarly educated on hazards of installing
browser plug-ins such as ActiveX controls. In highly secure environments, consider using
personal firewall programs to detect backdoor intrusion – these applications will pop up
a warning when a program requests an outbound connection. Administrators will need
to provide users with education on how to respond to backdoor detection when the pop
up message appears.
HP Best Practice: Implement virus scanning on the client desktop and secure the
client desktop operating system. Reduce automation such as active script associations
(more detail later) and restrict the administrative power of the current logon as much as
possible. In highly secure environments, consider personal firewalls for backdoor
The email client can be a source of virus outbreak or a last line of defense. Different
solutions need to be addressed for different types of email clients. We will consider
versions of Outlook, Outlook Web Access (OWA), and Outlook Express. Other POP3 and
IMAP4 clients need similar solutions.
In response to viral outbreaks, Microsoft has released a security patch starting with
Outlook 98 and Outlook 2000. The security patch is built into Outlook 2002 in Office XP.
The patch restricts access to attachments by type, either blocking access completely
(active code types) or forcing save to disk (other file types that may contain active
code). Control over file type definition can be administratively maintained (see Microsoft
Knowledge Base article Q263297). The security update also restricts programmatic
access to the address book, which can impact email applications. Microsoft has several
Knowledge Base articles Q249780, Q264128, Q264130 on this subject. Unfortunately,
users are able to bypass the security restrictions either through direct registry edits or
Outlook COM add-ins, so access to these configurations needs restriction.
For organizations extremely concerned about security and the possible risks of incoming
HTML email, it is possible to convert HTML email to plain text to avoid active HTML
payloads. There are two methods for doing this in Outlook, the first being available in
Outlook 2002 Office XP SP1. See Microsoft Knowledge Base article Q307594 for
information on enabling this option via Registry key. The second method is available for
all other versions of Outlook and uses an HTML to RTF Macro called ZAPHTML, which is
available from www.slipstick.com.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 10
Outlook Web Access
Since Outlook Web Access uses a browser to open email, it is dependent on the browser
security settings. In Internet Explorer for example, clicking on an executable attachment
will result in the dialog shown below in Figure 3.
Figure 3: Opening an executable attachment in Outlook Web Access
It is strongly recommended that organizations allowing usage of Outlook Express require
an upgrade to the latest version (as of this writing, version 6). Outlook Express now
offers attachment blocking and automation restrictions similar to the Outlook security
update discussed earlier. On the Security tab of the Tools, Options dialog are two new
options: Warn me when other applications try to send mail as me and Do not allow
attachments to be saved or opened that could potentially be a virus. See Microsoft
Knowledge Base article Q291387 OLEXP: Using Virus Protection Features in Outlook
Express 6. Another solution for protecting against email viruses is to use a POP email
proxy scanning solution such as the one in Norton SystemWorks.
Handling of email attachments can be further managed via the Control Panel: Folder
Options, File Types tab, and the settings for each file extension type - Confirm open
after download checkbox.
HP Best Practice: Update email clients to the latest version of security protection to
get attachment blocking and prevention of other exploits.
Tier 2: File and Application Servers
Files installed or copied to servers may transmit viruses. Real-time scanning and file-
based virus scanners should be run on Network File Servers. However, file-based anti-
virus scanning should never be run against the application and database files of an
Exchange Server. Doing so can result in false reports of a virus and corrupt Exchange
databases when attempting to disinfect the file. If you choose to run a file-based virus
scanner on an Exchange Server, remove the Exchange files and directories from the
scheduled scans and real-time scanning.
HP Best Practice: When deploying file-based scanning on Exchange Servers, be
certain that the Exchange database and transient file locations (such as the SMTP
mailroot and MTA), and the M: drive is excluded from scanning. Ideally, the anti-virus
product should be deployed via a package that is pre-configured for these exclusions.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 11
Tier 3: Firewalls and Gateways
Monitoring at this entry point includes transfer methods of FTP and HTTP. The key
point here for Exchange Administrators is that code downloaded directly to any
Exchange Servers should be scanned.
SMTP Relay and Connector Servers
All points of entry must be included: connections to the Internet, other X.400 MTAs, and
mail connectors to legacy mail systems (such as cc:Mail or MSMail). A recent trend has
been the outsourcing of virus scanning systems to a Service Provider. Anti-virus
scanning services are provided for all mail passing in and out of the connection and the
Provider handles all anti-virus software installation, administration, regular updating and
multi-system management. More information on this type of service is available from
companies such as Lansoft or Trend Micro.
Methods of Prevention or Detection
This section illustrates six methods of preventing viral intrusion into the organization,
including both software and policy-based methods.
The most recent form of viral payload has been through e-mail attachments. The
destructiveness of a very small percentage of attachments has become a security
headache for network administrators. One proposed solution is to disallow receipt of
attached files; instead, the e-mail must send a URL linking to the file. This solution
requires a unified network, and makes the assumption that the end-user will set proper
security on the desired file. Otherwise there is nothing to prevent a hacker from
replacing the original file with a viral file (if security has not been properly set). Another
solution is to allow your mail system administrators to strip off incoming attachments
and place them in a secure location where they can be isolated and scanned either for
viral signatures or tested for destructive payload. Indirectly this may also cut down on
the volume of rather large videos and animations.
The most complete protection is offered by preventing any and all attachments
containing executable code to be transmitted to recipients. If code does need to be
transmitted, it can be sent to an Administrative mailbox for verification or execution, as
explained below. Limited blocking can be enabled, where known filenames are placed in
an exclusion list, which is then referenced to determine whether to allow or deny
Microsoft has implemented file blocking to some degree in Outlook, starting with the
Office 2000 Service Releases, and continuing into the current version of Outlook 2002,
part of Office XP. Attachments are classified into one of two restrictive levels, and are
either blocked completely (active scripts and executables) or the user is forced to save
them to disk.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 12
For more information on Outlook security and attachment blocking, see the following:
– Outlook 2000: Information About the Outlook E-mail Security Update (Q262631)
– Outlook 2000 SR-1 Update: E-mail Security
Content filtering involves maintaining a list of words, statements, senders, or filenames
that are denied entrance into (or exit from) the mail system. Organizations that explore
this option are quite often looking for more than virus protection, such as the ability to
prevent unwanted solicitations or offensive material. Viruses transmitted by e-mail quite
often contain an identifying statement within the subject line that can be used to filter
out the messages.
HP Best Practice: Consider content filtering as a supplement to anti-virus scanning
that can limit unwanted messages from entering or leaving the organization. The best
anti-virus programs now include content filtering, and some content filtering applications
now include anti-virus.
A problem with any method of detection is that some files may be incorrectly identified
as suspicious code or unwanted content. However, the chances of this happening are
quite small and certainly are greatly outweighed by the value of preventing the outbreak
of true viral mechanisms. For this reason, messages must be quarantined or stored
temporarily until it is quite certain that they are unwanted and can be deleted. The
quarantine directory becomes another point of administration, as it must be included in
the monitoring systems for disk space usage.
A new virus can be identified because it behaves in a certain way. By definition, it is the
behavior that makes the program a virus. Code Execution is a method of viral
prevention, where a computer is set up (often called a "sacrificial system") in an isolated
network zone and all incoming applications are executed and monitored for suspicious
behavior. The process must be automated for optimal efficiency, otherwise the support
burden is overwhelming.
Scanning is the most common type of viral prevention. Incoming files are compared
against a known database of viral signatures or fingerprints. The database is usually
static and must be updated frequently (see the section on “Definition Updates”). Viral
scanning can be done in real-time as messages arrive or on a periodic scheduled basis.
The keys to anti-virus effectiveness are listed below. Considerations that impact the
effectiveness are the program API that is used to access Exchange Server as well as the
speed and efficiency of the program (both explained later in the product evaluations).
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 13
Content filtering has long been the realm of products designed for that sole purpose.
However, anti-virus vendors are adding this capability to their products. For example,
leaders in the Exchange Server anti-virus market, such as Trend Micro, have added this
capability to their products for Exchange 2000. The Trend Micro product is known as
eManager, and is available with their 6.0 release. Content management is even available
for smaller organizations through simple but powerful tools such as Nemx Power Tools
Selective Attachment Blocking
Essentially a subset of content filtering, selective attachment blocking allows for
preventing specific file types from entering the organization. This can be useful for
screening against unwanted file types (scripts such as VBS, or large media files such as
MP3) at all times or just during a virus outbreak. For example, the Sybari product is
known as Antigen File Filtering™ (AFF), and filters e-mail attachments by filename or
type and can use wildcards selection.
In the past, viruses tended to attempt avoiding detection and further propagation by
attaching to useful information or by using the Trojan Horse method. Most recent
outbreaks have been self-propagating and infected e-mails contain only the virus and no
useful information. In response, anti-virus vendors are offering the ability to completely
remove the offending message, rather than deliver a useless virus-generated message
with a cleaned attachment. In Sybari Antigen this is known as Worm Purge™ and in
Trend Micro ScanMail for Microsoft Exchange 2000 this is known as the Active Message
Selection by File Type
Typically, scanning programs increase efficiency by checking only file types known to
carry viruses (EXE, COM, DOC, etc.) or a list provided by the administrator. Recently,
the Symantec AntiVirus Research Center (SARC) put out a notice that the
W97M.Melissa.A virus was spreading again via an infected Word document with the file
extension of RTF instead of DOC. The document is a Word format file that has had the
file extension renamed so that anti-viral software not configured to scan the "RTF" file
extension, will not detect the virus. To detect the virus, the "RTF" file extension must be
added to the scanning and real-time protection lists. If you create a subset of file types
to scan, here are some recommendations:
Table 3. Attachment types recommended for scanning or blocking
Complete List of File Extension Recommended by SARC for Scanning:
386, ADT, BIN, CBT, CLA, COM, CPL, CSC, DLL, DOC, DOT, DRV, EXE, HTM, HTT, JS, MDB, MSO,
OV?, POT, PPT, RTF, SCR, SHS, SYS, VBS, XL?
Additional list of file attachments that may contain active content
??_, 00?, ACM, APP, ARC, ARJ, ASP, AX?, BAT, BO?, CAB, CDR, CHM, CMD, CNV, DEV, GMS, GZ?,
HLP, ICE, IM?, LZH, MPD, MPP, MPT, MSI, MSG, MSM, MSO, MSP, MST, OBD, OBT, OCX, OLE, PCI,
QLB, QPW, RAR, REG, SMM, TAR, TD0, TLB, TSP, VS?, VWP, VXD, WBK, WIZ, WPC, WPD, WSI, XML,
XSL, XTP, ZIP
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 14
Rather than use string comparisons to identify filename extensions some anti-virus
products determine the content type by reading the file header. This method requires
more processing overhead, but prevents lack of detection merely due to the file being
renamed (see section “Detection Circumvention Tests” for an example of this test and
the section “Effectiveness: Summary” for the results).
HP Best Practice: Ensure that anti-virus scanning or content filtering scans all file
types and is not bypassed by invalid file types or extensions.
Heuristic scanning studies suspect code to classify it by type of behavior. This method
does not rely on virus signatures; instead it inspects a program’s structure,
programming logic, instructions, file data, and other attributes to assess the likelihood of
viral intention. Heuristic scanning is important for scanning macro viruses due to the
ease of viral authors creating variants of the original macro virus. False positive alerts
are an issue however, as the anti-viral software must essentially make an educated
guess to identify viruses.
Another factor that impacts effectiveness of anti-virus scanning is called recursive
decompression. This is critical for compressed (ZIP) files placed within other
compressed (ZIP) files. Often this is a configurable setting (number of levels). This is
also a known point of attack, where very large files are nested deep within the zip files
and the anti-virus program must be capable of protecting itself against this threat.
Real-time and Manual Scanning
The most effective anti-virus scanning is done in “real-time” as messages traverse the
system. However, manual scanning should also be performed, especially in areas where
products were found in test results to be somewhat ineffective. In the past, it was quite
possible for a virus to slip past some scanners, usually under heavy load or from the
inadequacy of MAPI to provide 100% priority to the anti-virus scanner over the client
(which may be moving the e-mail message to a personal folder (PST) based on a rule or
mail delivery location -- see the section on “MAPI versus VSAPI” for more details). To
completely protect the system it may be necessary to run a manual scan, often
scheduled during the night.
HP Best Practice: At a minimum, Implement real-time scanning on entry points into
the organization. Schedule manual scanning for access points that may be less than
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 15
Policies and Procedures: User Education
Mail recipients need to be educated on proper handling of mail attachment types, such
as executables, documents containing macros and links to Web applets. For deployment
of AV Solutions to be truly successful, it must also encompass end-user education. A
thorough organizational policy mandates that incoming media be scanned or turned over
immediately to system administrators. End users need to be aware that retrieving
Internet mail from a Service Provider (such as through Outlook Express or another POP3
client) may circumvent anti-virus scanning efforts on corporate mailbox servers, and
should be avoided or protected by a client-side virus scanner such as the Norton POPPROXY
(a part of SystemWorks).
HP Best Practice: Establish and distribute an organizational policy explaining what file
types contain active content and how computer operators should handle those files.
Educate users to treat incoming attachments and Internet e-mail with suspicion and to
err on the side of safety.
The mission of most virus authors is to wreak havoc, demonstrate superiority over
defense systems, and come up with new ways to avoid detection. Anticipate and expect
viral outbreaks by following these Best Practices:
HP Best Practices:
– Limit access to network information and systems, such as installation of untested
code on Exchange Servers
– Monitor suspicious activity, by enabling and checking Security Auditing and Event
– Implement a reliable Backup and Disaster Recovery Strategy, and perform
regular recovery exercises
– Prepare an Outbreak plan for Administrators (detailed later)
Phase 3 - Develop the Solutions
This section focuses on software solutions to the virus problem for Exchange Server
systems. With the variety of Exchange Server designs and implementations, there is no
“one-size-fits-all” anti-virus product. The primary value of this section is in generating a
thorough list of questions that must be answered before choosing a product to
implement. There are certain crucial requirements that must be met (such as protection
at points of entry into the Web Storage System, Public Folders and PST files) and other
considerations that affect the ease of product use and manageability. The first question
to answer is where to draw the borders of protection, on connections to the outside
world or on internal mailbox servers.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 16
Anti-Virus Software: Selection Criteria
There are two methods for product selection; the first one is to choose the product with
the most desirable feature set, perhaps seeking a critical feature that cannot be done
without. This method may be easiest, especially if the choice of products with this
feature set is limited. The other method is through the process of elimination, choosing
the product that passes effectiveness and performance testing with the best results. The
following section illustrates both methods, starting with an attempt to prioritize product
features and assist in determining “must-have” features. The section Sample Evaluation
Criteria for Selecting Anti-Virus Products in the appendix summarizes the selection
criteria that you may wish to use to evaluate several products side by side.
Exchange 2000 versus Exchange 5.5
Exchange 2000 brings substantial changes to the architectural design of Exchange 5.5.
These will have deployment implications and affect the choice of anti-virus software.
Most likely, anti-virus software designed for an Exchange 5.5 server will no longer be
The most significant architectural change in Exchange 2000 in the area of virus
protection is in the API (Application Programming Interface) provided for virus scanning.
There are two main factors that impact the effectiveness of an Exchange Server specific
scanning product: the first is having the virus definition database up-to-date and the
second is the method or API (Application Programming Interface) used to access
Exchange Server. A new virus-scanning interface VSAPI v2.0 was introduced in Service
Pack 1 for Exchange 2000.
The previous version of this white paper and the testing conducted illustrated that the
existing API known as MAPI used for virus scanning was not 100% effective in
preventing transmission of known viruses. Essentially the anti-virus product acts as a
mail client, and attempts to get to the mail before the user does. MAPI also has a
disadvantage of not providing any means to scan outbound messages without
implementing additional anti-virus software on the client. One vendor, Sybari developed
its own method for interfacing with the Exchange 5.5 Store inserting a shim (loading the
Antigen DLL before the ESE DLL) between the ESE API (which is used for Exchange
online backups). The ESE shim was found to be very effective and offer high
performance, giving the product the ability to catch outbound viruses before they can
even leave the Outbox and be sent.
But the ESE shim was not a supported or endorsed method. It is still available as a
scanning method for the Sybari Antigen product for Exchange 2000, but Antigen also
offers the VSAPI method. Trend Micro also developed an ESE shim version for Exchange
5.5 only, but it was not tested as part of this paper.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 17
As part of Exchange 5.5 SP3 and also the initial release of Exchange 2000, Microsoft
developed an improved Virus Scanning API (VSAPI, also referred to as version 2). This is
the version tested for this white paper, as it includes several much needed
improvements over the AVAPI version 1. The VSAPI passes committed database
transactions to a vendor-supplied anti-virus scanning DLL. Even though the attachments
are in the store, e-mail clients cannot open the attachments until they are scanned.
Outlook (MAPI) clients will be able to open the message, but not the attachment, and
Internet protocol clients such as OWA will not be able to open the entire message until
scanning is performed.
The following are the methods or APIs available for virus scanning:
– MAPI – Original API used for Exchange 5.5 scanning and Outlook e-mail clients.
– ESE shim – Vendor developed workaround, not fully endorsed by Microsoft for
– AVAPI – Version 1 of Exchange 5.5 and Exchange 2000 scanning, with limited
– VSAPI – The official method for protecting Exchange 2000 Service Pack 1 (SP1)
and later. VSAPI is backwards compatible with the older AVAPI, so anti-virus
software should continue to work after SP1 is applied.
– Combination approach – in order to gain the advantage of each API, it is possible
for the anti-virus vendor to use a hybrid or multiple API approach.
– Transport Event Sinks and Store Events allow custom code to be executed on the
server for functions such as anti-virus and content management. See the
Exchange SDK for Microsoft’s documentation in this area.
MAPI versus newer Virus Scanning APIs
When Microsoft introduced the Anti-Virus API (AVAPI) in Exchange 5.5 Service Pack 3, it
presented some difficulties to virus-scanning vendors. When a virus was detected in an
e-mail attachment using AVAPI, the anti-virus scanning program received no information
on the sender or recipient of the message. In addition, only the e-mail attachments
could be scanned, and not the message body. This presents a severe limitation when
attempting to detect viruses such as the KakWorm, which can infect the body of the e-
mail message. Vendors using the AVAPI were often forced to develop hybrid solutions.
For example Trend Micro (ScanMail) and McAfee (Groupshield) revised their products to
use both MAPI and AVAPI interfaces, in order to scan the message body, and also
obtain sender and recipient information. McAfee also released a utility to identify items
in the quarantined virus database and attach names.
The new Virus Scanning API 2.0 (VSAPI) in Exchange 2000 SP1 offers the following
improvements: the ability to get full message details such as senders and recipients. It
offers the ability to scan native MIME/MAPI content, and perform proactive scanning,
before the message is requested from the client.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 18
All message types are scanned by the VSAPI to prevent receipt of binary viruses labeled
as plain text. The VSAPI offers priority-based queuing and background scanning. And it
offers full event logging and Performance Monitor counters. Since VSAPI is capable of
providing on-access scanning (when the e-mail attachment is requested), it provides an
extra measure of safety even without performing manual scan jobs to detect
undiscovered viruses (for which there was no signature when received).
In summary, the new VSAPI2 offers these three methods
1. Proactive Scanning - as new messages arrive at the server
2. On Access Scanning - when messages are opened or accessed via the email
3. Background Scanning – administrator requested scanning of messages, primarily
used for re-scanning the Exchange database when virus signatures have been
The combination of these three methods provides a comprehensive solution for anti-
virus vendors to deliver scanning applications.
Multiple Information Stores
Exchange 2000 provides Multiple Storage Groups (up to 4) and Mailbox Stores (up to 5
per SG) per Server, requiring Exchange 2000 aware anti-virus applications, as this is a
different architecture than Exchange 5.5. Exchange 2000 also introduces a new type of
database file, (.STM), requiring Exchange 2000 aware anti-virus applications, as clients
are able to access this database file using Internet protocols such as POP3, IMAP4,
SMTP, and HTTP-DAV (OWA).
Exchange 2000 provides additional methods of clients to send and retrieve messages
from the Exchange private and public information stores. The Web Storage System
exposes access into the Store via HTTP-DAV (Outlook Web Access), and is not protected
against viral transmission using MAPI or AVAPI scanning methods. The VSAPI (and also
ESE shim) does provide protection for OWA clients, however only when running on the
back-end server and not on the front-end server, as described below.
The Exchange Installable File System (EXIFS) exposes access into the Store as the M:
drive and folders that can be shared out, just as on a file server. To protect against
viruses being saved into the M: drive, Exchange-aware anti-virus should be run using
the Service Pack 1 VSAPI (or the ESE shim). Anti-virus products designed for file-servers
should not be run against the M: drive or database corruption may occur.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 19
Anti-virus software for an Exchange Server environment is available in three designs.
The first is for an SMTP server regardless of the SMTP gateway version, usually relaying
on TCP/IP Port 25 to the Exchange Server system. The second design is to be installed
on Exchange Servers dedicated as connector servers (in Exchange 5.5 Internet Mail
Connectors). Both of these designs primarily protect against inbound and outbound
viruses from Internet e-mail. Exchange 2000 introduces a front-end (FE) / back-end
design which allows for anti-virus placement on the FE servers. The FE servers service
Internet protocols such as POP3, IMAP4, SMTP, and HTTP-DAV as proxies for OWA
clients. The third type of design runs directly on the final delivery point, and protects the
Exchange Server Mailbox Store. This is often the preferred design, as it should protect
all internal e-mail and collaboration transactions from infection.
HP Best Practice: When deploying Exchange 2000 and Outlook Web Access make
sure to place anti-virus on the back-end (mailbox) servers, as anti-virus on the front-
ends does not scan incoming or outgoing OWA e-mail
Cluster Support (MSCS)
Exchange 2000 takes advantage of the revised clustering design of Microsoft Cluster
Server (MSCS), including active/active cluster nodes on Windows 2000 Advanced Server
and N+1 nodes on Datacenter Server. In an environment where Exchange 2000 Server
is run on Microsoft Cluster Server, the choice of anti-virus products is further limited.
Trend Micro ScanMail and Sybari Antigen have long been designed to operate in a
cluster fail-over situation. Clustering is also available in the Windows 2000 Datacenter
product and several anti-virus vendors are actively testing compatibility of their
Product Selection and Deployment
Server Sizing and Performance Impact
The most often asked question is “How much additional hardware will I need to
implement anti-virus scanning software into my Exchange System?” The answer
depends on the existing load and resource utilization on the servers, which is a function
of message flow during normal and peak periods, and the number and size of
attachments. For new deployments the impact of deploying anti-virus scanning
software is lessened by the fact that no user expectations exist for what system
response should be.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 20
Performance Impact: Existing Load
Anti-virus software primarily utilizes the resources of CPU and memory. If either of
these resources is near becoming a system bottleneck, additional resources will need to
be added before the anti-virus program is installed or performance will suffer. Before
implementation it is important to measure the existing load during normal and peak
operations. In the event that they do become a bottleneck in the scanning process, the
disk subsystem will then be impacted as the processing queues build up. It is therefore
recommended that the disk subsystem design also be considered in selecting anti-virus
HP Best Practice: Measure the existing load during normal and peak operations (using
PERFMON) to establish a baseline before deploying anti-virus solutions.
Performance Impact: Enhancing Performance
Whenever possible it is best to plan, develop, test and deploy anti-virus when the
Exchange Server system is first rolled-out. However, in lieu of that it is possible to use
the scalability of Exchange Server to resolve the issue either through horizontal or
vertical scalability. Horizontal scalability is also known as functional decomposition, and
it means offloading services, or functions of the Exchange Server to additional servers.
Mailboxes can be moved to a new server, lessening the load on the existing system as
anti-virus protection is added, thus keeping the user responsiveness optimized. Vertical
scalability is achieved by adding more resources such as additional memory or
processors to the server.
Performance Impact: User Response versus Throughput
Another important consideration is the impact on the e-mail system, especially when
deploying into an existing production system where end-users may have already created
expectations of how well the system should perform. The effect of deploying on
mailbox servers is to delay the responsiveness of the system (to end-user operations,
such as opening and sending mail), while the effect of deploying on connector servers is
usually to delay delivery rates (throughput). The latter is often a more acceptable
impact to an existing system, so placing anti-virus scanning on the gateways is less
noticeable to the end-user community.
HP Best Practice: Before deploying anti-virus solutions understand the impact to the
organization on the mail system, whether it will be in responsiveness or delivery times.
Handling Infected Files
The best anti-virus software gives the administrator the ability to control how to handle
files suspected of being a virus. In the unlikely event of a false positive it is important
that the original file be preserved and not damaged. The choice of whether to attempt
repair, quarantine or just delete the file should be made available. In the event of
quarantine, most programs will only allow the administrator to specify a root directory.
It would be easier to manage if a hierarchy was created based on recipient name.
HP Best Practice: Place the quarantine location on a RAID protected drive subsystem,
away from the Exchange Server database and log files. Regularly monitor the free
space on this drive location and clean up as needed.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 21
Every anti-virus vendor would like to be able to claim that they have the fastest
response time to discovering and protecting against new viruses. The reality is that no
one vendor can always be first. Discovery of new viruses released “into the wild”
depends on the network of contacts, customers and research that the company does.
The “Holy Grail” of anti-virus technology is software that detects suspicious files
automatically and never requires updates. In the meantime, updates are made
available for automatic, scheduled distribution via the Web or FTP. Anti-virus vendors
must certify the stability of engine (or virus definition) updates before making them
available. However, it has been known to happen that a specific server configuration
will result in problems. For this reason, it is recommended as a best practice to update
a less-essential server first and monitor the stability before applying the update to other
production mail servers.
Verify that the anti- virus software you are considering for purchase allows configuration
of scheduled, automatic updates from a specified location. In the event of a problem
with the engine update, the software should be designed to rollback to the previous
Most likely the server selected to automatically pull the definition update will not have a
direct connection to the Internet, and must be able to access through a proxy server.
Verify that the anti-virus software will allow for this configuration. To reduce the
amount of traffic over the Internet connection it should also be possible to use fan-out
distribution architecture, where the first update is placed on a shared network location
and remaining servers are updated from that source.
HP Best Practice: Configure frequent, automatic updates and apply first to less critical
or non-production Exchange Servers.
The best anti-virus software gives the administrator the ability to control the types of
notifications sent out on detection of a virus. Notifications should be configurable for
administrators and mail system end-users. Choice of methods includes Broadcast Alerts,
E-mail Alerts, and Pagers. In addition, the message that is sent out should be fully
customized to ensure that the desired information is conveyed to the recipient, and also
allow for multi-lingual messages.
One anti-virus product, Sybari Antigen, in addition to allowing customization and control
over messages, allows separate control and definition for external senders and
recipients as well as internal senders and recipients. This helps to reduce the flood of
traffic that notifications can create during a viral outbreak.
Additional information can be written to the Windows Event Log or Application-specific
Reports. Most anti-virus software creates a log, which can be exported to other
formats. This information can be quite useful. For example, one program, NAV (Norton
Anti-Virus) for Exchange logs information to the NT event log when an encrypted ZIP file
enters the organization. This could be quite useful, as the encrypted ZIP file may
represent a breach in security.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 22
HP Best Practice: Choose notifications carefully, as they can create additional load on
the system during a viral outbreak.
Server Status and Monitoring
As with most any software, introduction of anti-virus scanning application to a
production e-mail server represents a risk of introducing harm or disruption to that
server. The need to monitor the server becomes increasingly important. Allegorical
stories have circulated of store corruption (-1018 errors) perhaps induced by the anti-
virus scanning. Confirmation or isolation of these issues is difficult, and quite often the
first priority of support personnel is to reduce interference and request that anti-virus
scanning be removed until the problem can be resolved.
Various products provide a management console in either a native Windows program or
an HTML-based browser allowing for administration of remote servers across the
network, or perhaps both. The functionality of each version may not be exactly the
same, as the browser versions tend to aim for portability at the loss of features. Add the
type of management console to your selection criteria when considering a product for
Most anti-virus products (such as Trend Micro ScanMail and Sybari Antigen) add
PERFMON counters for their product for scanning and detection rates. These can be
used in addition to monitoring the following recommended counters for measuring anti-
virus product resource utilization:
– % Processor Time: Total
– % Processor Time: AV Processes
– Memory Used: AV Processes
– Message Delivery Times
– Disk Usage: % and Queue Length
IMPORTANT: the disk measures require that the disk counters be enabled by toggling
“diskperf -y” and should only be used during testing to ensure that the disk subsystem
can handle the required load during scanning and quarantining. Be sure to disable
“diskperf” during production).
Exchange 2000 now includes anti-virus counters as part of the VSAPI (Virus Scanning
Application Programming Interface), but the anti-virus scanner must make use of the
VSAPI for these counters to gather information.
Monitoring Service Status
The anti-virus services need to be included into existing or new monitoring systems. In
the case of most products (except Sybari Antigen, which places a dependency key in the
registry so that the Antigen Service must be running or the Exchange Information Store
will not start) it is possible for the anti-virus service to be stopped and messages will
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 23
continue to pass through unchecked. This represents a point of attack for virus authors
if they can use a Trojan-Horse virus to fool an administrator, then the virus can use the
logon context of that administrator to stop the anti-virus service and deliver its payload.
HP Best Practice: Add the anti-virus services to monitoring systems (third-party or
Exchange Administrator Console) and configure notifications so that the Administrator is
alerted if the scanning service is offline.
Product Issues: Pricing, Licensing, and Support
Other considerations for selecting an anti-virus product are pricing and licensing, and
support issues. A product may be favored for selection due to aggressive pricing
strategy, such as a “trade-up” price. Licensing may be favorable when another product
by the same vendor is used for client desktop or file server protection.
It is recommended that the vendor’s support policy be investigated before selecting a
product. Important to consider are they type of contact supported (telephone, e-mail,
Web-based discussion list) and the availability during normal business hours for all time
zones that the organization has a presence in.
Another important factor, although much more difficult to assess, is the longevity of the
product. How quickly will the vendor respond to service packs or upgrades to the
Exchange Server product? What is their commitment to having their product ready so
that you can keep your Exchange systems up to date?
HP Best Practice: Expect a long-term relationship with the anti-virus product vendor
and get a clear commitment on support policies and product longevity.
Viral Identification and Effectiveness and Performance Testing
Finally, and perhaps the most important factor in product selection is how well it
performs in preventing viral intrusion. The next section details the testing of various
products in a lab environment.
Phase 4 - Conduct Pilot Testing
Once the product selection is narrowed down based on the information in the previous
section, a performance evaluation and comparison of products can be considered. For
the purposes of this research paper, a comprehensive evaluation of anti-virus software
for Exchange Server and the messaging environment in general was done. New
products are released quite frequently, especially considering the large number of
vendors and products tested; so, these test results should only be used to determine
what to look for in conducting your own comparisons.
The testing involved three main parts: (1) attempting to pass a virus file through
detection, (2) measuring performance impact and (3) assessing the usability of program
features. The table below lists the viruses and problem files that were introduced while
the servers were under increasing load, to determine how well the Anti Virus programs
detect viruses and handle problem files (such as a ZIP file with no contents and a zero-
byte COM file).
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 24
Table 4. Viruses and Problem Files Introduced
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 25
Type of Description Desired Result
Category: Known viruses
Known Example: TROJ_EXPLOREZIP (also known as Remove Attachment
Executable Worm.EXPLOREZIP) an email worm containing a
Virus damaging payload.
Known Macro Valid document with macro infection. Example: The Clean document
Virus W97M_Empirical Word Macro virus.
Disguised Known virus signature: well-known virus renamed Remove Attachment
Known Virus as *.JPG to avoid detection if only scanning on
active content extension types (e.g. .EXE and not
Known Active Viral payload is contained in message body as Purge message
scripts, and opposed to attachment. Example: KAK or Bubbleboy
Known Worm Entire message is unwanted content. Example: Klez Purge message
- a mass-mailing email worm that attempts to copy
itself to network shares. Uses random subject lines,
message bodies, and attachment file names.
Exploits vulnerability in Microsoft Outlook and
Outlook Express to execute when you open or
preview the message2.
Archived and Known virus, zipped and placed within an Outlook Clean virus out of archive
Nested Virus message (.MSG) file, which is then attached to the
Virus Known virus placed within a document, which is Clean virus out of document
Embedded in then attached to the outgoing message.
.com URL Rename known virus to .com file that appears as a Remove Attachment
format hyperlink e.g. www.badfile.com (e.g. exploited by
Category: Illegal MIME Structures
Invalid e.g. Viral attachment passes but in form
content type Content-Type: text/plain; name=?us-ascii?Q? ATT00xx.txt which is saved as text
Invalid name e.g. Viral attachment passes but in form
structures Content-Type: application/binary; name=?us-ascii? ATT00xxx.DAT which is saved as
Information from Symantec Security Response: http://firstname.lastname@example.org
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 26
Type of Description Desired Result
Invalid name e.g. Detection
File name not e.g. Viral attachment passes but in form
specified – Content-type=application/hta ATT00xxx.DAT which is saved as
determined attachment. (Not a real threat)
by MIME type
Illegal 8.3 file e.g. additional dot in filename stripped when saved Detected when scanning all
name to disk in Windows PC. attachments and not just specific
Category: Problem attachments and messages
Zero-Byte Zero-byte file with .COM extension. Designed to Remove Attachment or pass without
.COM file test a known issue with some scanning programs, error to scanner
reported in August of 1999, where a zero byte file
could cause the scanner to hang.
Zero Byte ZIP Zero-byte file with .ZIP extension Designed to test a Remove Attachment or pass without
file known issue with some scanning programs, reported error to scanner
in August of 1999, where a zero byte file could
cause the scanner to hang.
Extremely Office Document of several hundred megabytes Remove Attachment or pass without
Large Zipped placed into a zipped file along with a known virus. error to scanner
Category: Potential virus threats
NTFS Stream Alternate Data Streams threat with the extension Remove Attachment
“*}”. See http://www.sans.org/infosecFAQ/threats/
win_NTFS.htm for more information.
IFRAME tag When an HTML email with a URL in an IFRAME tag Purge or Remove HTML
embedded in the message is opened in Outlook the
user is prompted to open (run) the file, save or
cancel with no warning that the URL may point to a
dangerous executable file. The default choice is
"about:" or Even though scripting is turned off by default in Purge or Remove HTML
still be executed.
Predictive Stay current on exploits that can be easily Varies
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 27
Example Detection Circumvention Tests
The following tests were devised to measure detection rates and attempt to defeat
Table 5. Detection Circumvention Tests
Test Expected Test result
To Uninitialized Mailbox Ideally: Initialize mailbox to scan incoming mail, otherwise first time logon to
mailbox may allow access to virus (previous problem with MAPI-based
Delayed Send Detection (immediately on send)
With Invalid Return Address No problems (expect NDR if notifications to sender)
Embedded in Outlook Form Detection
To Distribution List Address Detection, including outbound SMTP (Custom Recipient) member of
To Public Folder via Post Detection
To Public Folder via an SMTP Detection
Drag and Drop File to Public Folder Detection
Exchange Settings: Private Detection
Attempt to catch virus while AV Detection
Service stopped or starting
Message in Sent Items Cleaned copy of message sent should be kept; but no active virus should be
.PST as delivery location (Client Detection
Invalid inbound address (creates Return without Scanning Attachment; NDR message should come back with
NDR, but should not scan virus intact. (Note: Consideration when under attack during viral break-out
attachment) such as “Melissa” created)
Invalid Address (create NDR) with Detection
Digital Signature Unable to detect without affecting signature (Ideally: Integrate with
Certificate Server to scan mail)
Signed and Encrypted Unable to detect, encrypted (Ideally: Integrate with Certificate Server to scan
Example Test Environment
Figure 3 illustrates the test environment for evaluating anti-virus software.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 28
Active Directory Organization
First Routing Group
Drive 0 Open Drive 1 Open
ProLiant DL360 front-end
Drive 0 Open Drive 1 Open
servers FE360L9 - 12
Drive 0 Open Drive 1 Open
18 GB 18 GB
Version 6.0 (Build 4712.4:
Drive 0 Open Drive 1 Open
COMPAQ Service Pack 1)
ProLiant ML Active
DNS, DHCP Second Routing Group
ProLiant DL Mailbox ProLiant 1850 Mailbox EXVS1 -- Cluster
Server Version 6.0 (Build Server Version 6.0 (Build Version 6.0
5762.4: Service Pack 2) 4712.4: Service Pack 1) (Build 4712.4: Service
Figure 4: Exchange 2000 Test Environment
HP Platform for Testing
The table below shows the ProLiant platform configuration for testing.
Table 6. ProLiant Platform Configuration for Testing
Computer Role CPU + RAM Drive Subsystem
ProLiant 8000 Active Directory Servers 8-way 500Mhz Smart Array 4250ES RAID
ProLiant 6000 Global Catalogs and DNS 512MB RAM Controller
4-way 400Mhz Smart Array 3250ES RAID
>1GB RAM Controller
ProLiant DL360 4 Front-End Servers (SMTP, 1 CPU 800Mhz Internal Integrated Smart
POP3, IMAP4, HTTP- 512 MB RAM Array Controller RAID1
ProLiant 1850R Back-End (Mailbox) Servers 2 CPU 550Mhz Smart Array
1 GB RAM External
ProLiant 1850R Back-End (Mailbox) Servers 2 CPU 500Mhz External RA4000 Fibre Channel
384 MB RAM
2x ProLiant 1850R Clustered Back-End (Mailbox) 2 CPU 500Mhz External RA4100 Fibre Channel
Servers 384 MB RAM
Deskpro EN LoadSim and Mailtest load 233-700MHz IDE
generators 256-384 MB RAM
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 29
Example Test Plan
The overall purpose of this testing is to evaluate representative anti-virus products
based on differing detection methods or APIs, and measure the results of server
performance impact and viral detection rate, just as you are encouraged to do with
products that you are considering. The scope of these tests is to evaluate anti-virus
products in Exchange mailbox server, and Internet protocol (SMTP, IMAP4, POP3, HTTP)
front-end server versions. In practice, you would narrow the testing down to one or two
products to make sure that they meet your expectations. Several tests were devised,
• Exchange 2000 Server Mailbox and Public Folder Store virus protection
– Test Suite 1: Normal Load
– Test Suite 2: Peak Load (Stress Test)
– Test Suite 3: Impact of Multiple Storage Groups and Mailbox Stores
• SMTP Front-End virus protection
– Test Suite 4: Measure throughput and resource utilization with and without anti-
The testing methodology involves creating the sample environment using LoadSim,
including Active Directory accounts and fully populated mailboxes. The test load is then
run, allowing LoadSim to achieve a steady state over an 8 hour run, during which
performance monitor counters are captured. Results are then analyzed during the 4-
hour window after the initial 2-hour ramp-up time. Several tests were run until
consistent results were achieved.
Example Test Results
IMPORTANT: The following test results are not meant to represent your expected
production performance. Every environment will be different based on existing server
load, message sizes, attachment sizes, and percent of attachments. Note that some
values (italicized) are out of range.
Exchange 2000 Server Mailbox and Public Folder Store virus protection
Test Suite 1: Normal Load
The first test suite involves creating a test load on the Exchange Servers (multi-server
environment) using LoadSim for MAPI MMB2 e-mail, and MailTest for inbound SMTP e-
mail. The viruses and known problem files listed in Table 4 are then introduced. The test
settings on all products were as follows: scan all attachment types, on detection notify
sender, administrator and recipient via e-mail, repair if possible, quarantine if not.
All anti-virus scanners tested using the VSAPI passed the detection tests with essentially
100% detection rates (unlike in previous versions using Exchange 5.5 and MAPI, as
discussed in the section on virus scanning APIs).
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 30
The following table shows the results of running the LoadSim tests. The conclusion is
that the load impact of anti-virus does vary from product to product and can affect the
processor utilization significantly.
Table 7. Test Results for Load Impact on Exchange 2000 Mailbox Server with 1,000 MMB2
Configuration: Mailbox Server, 2 Storage Groups, 8 Stores total - 1,000 MMB2 Users
Baseline VSAPI VSAPI
No AV Product A Product Y
LoadSim 95th percentile Response 134 193 200
PerfMon Object Counter
% Processor Time Total 32% 58% 36%
Memory Pages/sec 4 16 7
Process Working Set (MB) AV n/a 5 2
Store 813 862 864
MSExchangeIS Count 1,250 1,251 1,244
MSExchangeIS Scanned n/a 3,113 3,153
MSExchangeIS Processed n/a 951,685 890,360
MSExchangeIS Mailbox(_Total) Delivered 96,778 99,535 101,640
MSExchangeIS Mailbox(_Total) Messages Sent 25,982 27,176 27,292
% Read / % Write Data 94 / 250 111 / 280 167 / 324
Logs 0/6 0/8 0/7
Current Disk Queue Length
(averaged over time period) OS - - -
Data 2 3 3
Logs - - -
Calculated: Physical Disk
% Read : % Write Data 27 : 73 28 : 72 34 : 66
Logs 0 : 100 0 : 100 0 : 100
Load Impact and Clustered Servers
The following table shows the results of running the LoadSim tests against 2-node
(Active/Standby) clustered Exchange Servers. The conclusion is that the anti-virus
products were stable and performed well in a cluster environment. Note that even with
anti-virus, the user response times could actually improve, indicating that the load
impact of anti-virus was not statistically significant.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 31
Table 8. Test Results for Load Impact on Clustered Server with 500 MMB2 Users
Baseline Product Product
Test Run No AV A B
LoadSim Response 99 97 80
PerfMon Object Counter
% Processor Time Total 14.3% 18.9% 14.8%
Process Working Set (KB) AV n/a 15,674 3,319
Store 283,540 284,200 287,672
MSExchangeIS Count 530 528 538
MBytes VSAPI not
MSExchangeIS Scanned used 225 3,044
MSExchangeIS Processed n/a 88,185 436,109
Mailbox(_Total) Delivered 55,403 48,623 47,851
Mailbox(_Total) Sent 13,253 11,561 11,816
Mailbox(_Total) Ratio 1.18 1.15 1.15
% Read / % Write Data 35 / 69 38 / 72 42 / 78
Logs 0 / 3.7 0 / 3.9 0 / 3.8
Current Disk Queue Length
(averaged over time
period) OS 0.01 0.05 0.04
Data 1.50 1.17 0.96
Logs 0.02 0.02 0.04
% Read : % Write Data 34 : 66 35 : 65 35 : 65
Logs 0 : 100 0 : 100 0 : 100
Load Impact and Varying RAID Levels
The following table shows the results of running a baseline, anti-virus “Product A” and
then anti-virus “Product B” on RAID1+0. Then the RAID array was converted to RAID5,
the Stores were moved to the new array and the tests run again. The conclusion is that
using RAID5 (to provide more disk space) instead of RAID1+0 does have a significant
negative impact on performance, as measured by the client response time. In fact, the
load impact is much greater when multiple Stores are placed on the same RAID array,
as shown in the next section and in the separate paper “Impact of Exchange 2000
Information Store Partitioning” available at www.hp.com/solutions/activeanswers.
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 32
Table 9. Test Results for Load Impact with Varying RAID levels - 1,000 MMB2 Users, 8 Stores
Test Configuration: Mailbox Server, 2 Storage Groups, 8 Stores total - 1,000 MMB2 Users
Baseline Product VSAPI Product
No AV V Product A A
RAID Level RAID1+0 RAID1+0 RAID1+0 RAID5
LoadSim Response 135 158 193 238
PerfMon Object Counter
% Processor Time Total 33% 40% 58% 40%
Memory Pages/sec 26 33 16 11
Process Working Set
(KB) AV - 13 5 4
Store 836 834 862 863
MSExchangeIS Count 1,251 1,248 1,251 1,187
MBytes VSAPI not
MSExchangeIS Scanned used 2,011 3,113 1,852
Messages VSAPI not
MSExchangeIS Processed used 192,218 951,685 771,466
Mailbox(_Total) Delivered 127,161 97,279 99,535 28,115
Mailbox(_Total) Sent 33,023 26,307 27,176 7,199
% Read / % Write Data 98 / 241 110 / 279 111 / 280 108 / 254
Logs 0/6 0/7 0/8 0/7
Current Disk Queue
over time period) OS - - - -
Data 2 3 3 3
Logs - - - -
Calculated: Physical Disk
% Read : % Write Data 29 : 71 28 : 72 28 : 72 30 : 70
Logs 0 : 100 0 : 100 0 : 100 0 : 100
Load Impact of Multiple Stores
Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 33
The following table shows the results of running a single store baseline, with and
without anti-virus “Product X” and then two stores, four stores, and then two stores in
each of two storage groups (all on RAID1+0). The conclusion is that using multiple
stores has an impact on anti-virus scanning (as evidenced by the increased resource
utilization such as processor, and connection count), however the end result as
measured by client latency was not significant.