Issues Detected by ExRAP
Note on IT
Published: December 22, 2005
The Exchange Center of Excellence (ECoE) administers the Microsoft® Exchange
Server Risk Assessment and Health Check Program (ExRAP) at Microsoft. An ExRAP engagement
provides a detailed on-site technical and operational analysis of a large Exchange
deployment. This Note details the most common issues and overlooked vulnerabilities
found so far during ExRAP engagements.
|
Document Definition
|
Intended Audience
|
Products & Technologies
|
|---|
|
A Note on IT is a short, technically deep drilldown on a specific topic related
to Microsoft IT and is usually associated with an existing IT Showcase document.
A Note might illustrate how Microsoft IT performs a specific operational task step
by step or configures a hardware device or software application. It might also relate
details of a best practice or contain frequently requested information about Microsoft
IT's operations.
|
This document can be helpful for all Exchange administrators. Although ExRAP engagements
are typically for large enterprises, the issues that this document covers apply
to an Exchange installation of any size.
|
- Microsoft Windows Server 2003
- Microsoft Exchange Server 2003
- Clustered servers
|
Introduction
The ECoE is a group of Exchange experts that the Microsoft Information Technology
(Microsoft IT) group sponsors. Created in April of 2004, the mission of the ECoE
is to develop programs, resources, and best practices for deploying and managing
Exchange in large enterprises. One of the programs that the ECoE currently administers,
in conjunction with Microsoft Services, is ExRAP.
ExRAP engagements are available to Exchange accounts that have Premier Support agreements.
In a typical ExRAP engagement, a Microsoft consultant performs an on-site analysis
of an Exchange deployment. This analysis covers not only individual servers but
also the physical infrastructure, logical topology, and process management that
support Exchange. An ExRAP report measures Exchange performance, stability, and
recoverability along dozens of dimensions and provides specific feedback and remediation
recommendations for any issues identified.
ECoE has completed more than 900 ExRAP engagements to date. On average, Microsoft
has measured more than a 30 percent reduction in critical situation (CritSit) Microsoft
Customer Service and Support cases in accounts that have received an ExRAP analysis.
A CritSit is a support case that a customer opens for a problem that is interrupting
service to end users or affecting important business operations. The evidence is
strong that making even some improvements based on ExRAP recommendations can greatly
improve the operational health and stability of an Exchange environment.
For customers who currently have a Premier Support contract with Microsoft, the
technical account manager is the first point of contact for scheduling an ExRAP
engagement. Customers who do not have a Premier Support agreement for Exchange,
or who want to learn more about Premier Support services, can find more information
at http://www.microsoft.com/services/microsoftservices/srv_prem.mspx.
The purpose of this document is to share the most common problems that the ExRAP
process uncovers. This paper assumes that readers are Exchange administrators with
the ability to make configuration and architectural changes to the Exchange system.
This paper also assumes familiarity with Microsoft Windows Server™ and with Microsoft
Exchange Server.
This paper is based on Microsoft IT's experience and recommendations in conducting
ExRAP engagements with several Exchange customers during the past year. It is not
intended to serve as a procedural guide. Each environment has unique circumstances;
therefore, each organization should adapt the plans and lessons learned described
in this paper to meet its specific needs.
One of the tools used in every ExRAP engagement is the Exchange Best Practices Analyzer
(ExBPA). Every Exchange administrator can download this free tool from
http://www.microsoft.com/exchange/downloads/2003/exbpa/default.mspx. An
administrator can run ExBPA against individual servers, groups of servers, or an
entire Exchange organization. The tool analyzes hundreds of Exchange server and
Microsoft Active Directory® directory service configuration settings and reports
on all suboptimal settings or misconfigurations found.
The sections in this paper deliberately exclude particular issues that ExBPA reports.
This exclusion is not because these issues are less important, but because any Exchange
administrator can (and should) run ExBPA to discover which issues apply to his or
her environment. An administrator who makes an action plan to address issues mentioned
in this document should do so in conjunction with an ExBPA report.
Server Configuration Issues
This section focuses on problems that an individual administrator can check for
and correct with minimal cost or team coordination. It focuses on one-time changes
an administrator can make that do not require ongoing management or additional operational
infrastructure.
The issues that this section identifies are not in any particular order of severity
or priority. They are all issues that can result in significant, avoidable downtime
or reduced performance in any Exchange environment.
Antivirus Configuration
With regard to Exchange, antivirus programs fall into one of two broad classifications:
-
Exchange aware. Interacts with the Exchange store process to intelligently
scan Exchange messages and to quarantine or delete infected messages without damaging
or destroying critical Exchange data files.
-
Generic file level (not Exchange aware). Indiscriminately scans files and
may quarantine, alter, or destroy files to prevent virus infection.
It is critical to exclude Exchange database and transaction log file directories
from being altered by a generic, file-level antivirus scanner. If these directories
are not excluded, the scanner will eventually corrupt Exchange data and can stop
the databases.
In the most common scenario, a generic, file-level virus scanner destroys or moves
current Exchange transaction log files. This action stops the database, leaving
it in an inconsistent state. To restart the database, missing transaction logs,
if they still exist, must be found and copied back to their original locations.
If the current transaction logs have been destroyed, there are two choices for recovery,
both of which are likely to take some time to implement:
-
Restore the database from backup and roll it forward with the remaining transaction
logs, thus losing the information in the destroyed transaction log files.
-
Repair the database, which also carries some risk of losing data, and which will
invalidate all previous backups. After repairing a database, immediately make a
new backup to begin a new series of backups that can be used to roll the database
forward.
A generic antivirus scanner may also alter an Exchange database file, thus corrupting
it. Even if the damage does not prevent the database from running, the corruption
will, at the least, prevent online backups of the database from completing successfully.
Exchange scans the entire database for corruption during online backup, and it stops
the backup if it finds corruption. This action ensures that the last database backup
is always of a good database.
A misconfigured, generic antivirus program is a very common cause of prolonged database
outages that require full restoration or other disaster recovery steps.
Note: ExBPA will detect some, but not all, cases in which an antivirus
program is acting on Exchange data files. Do not rely entirely on ExBPA to detect
this problem.
For more information about using antivirus software with Exchange, refer to the
Microsoft Knowledge Base article "The Exchange database store many not mount in
Exchange Server 2003 or in Exchange 2000 Server" at
http://support.microsoft.com/kb/896143.
Server Memory Configuration
A heavily loaded, enterprise-class Exchange server typically has more than 1 gigabyte
(GB) of random access memory (RAM) and simultaneously services more than 2,000 users.
Under these circumstances, Exchange processes massive amounts of user data simultaneously.
Tuning server memory correctly improves performance, prevents exhaustion of critical
Microsoft Windows® memory resources, and allows Exchange the maximum use of
the 32-bit virtual memory address space. For detailed instructions on memory tuning
for Exchange Server, refer to the following Microsoft Knowledge Base articles:
Online Maintenance
A busy Exchange database is accessed by hundreds or thousands of individual users
each day who move, copy, delete, send, and receive messages of all different sizes.
The database is kept busy inserting, deleting, and merging large numbers of random
records. As with a file system in which large numbers of changes are being made,
space in the database eventually becomes fragmented, thus reducing performance and
efficiency.
The database online maintenance routines include online defragmentation,
which scans the database and reorganizes space utilization. Other maintenance tasks
required to keep the database optimized also occur during online maintenance, but
defragmentation is the most important and time-consuming of those tasks.
The administrator can individually schedule online maintenance for each database.
By default, online maintenance runs between the hours of midnight and 05:00 local
time. If an online backup starts or the maintenance window expires, online maintenance
will be suspended until the next scheduled maintenance window, at which time it
will resume where it left off.
Online maintenance does not need to complete every night, but it should complete
periodically for every database. As a rule of thumb, Microsoft IT sets online maintenance
windows so that a cycle completes for each database at least once a week. If maintenance
never completes, not only will the performance of the database be adversely affected,
but also the database files may grow to larger sizes than necessary because space
within them cannot be reused efficiently.
For more information about running and monitoring online maintenance, please refer
to the following Microsoft Knowledge Base articles:
Disk Space
Exchange databases grow as needed to contain new user data. Exchange transaction
log files are generated as necessary to record all changes to the databases.
In the typical case, the size of an Exchange database will stabilize after a period
of use. The database will not grow larger because it has reached an equilibrium
state where user deletions keep up with user insertions. Exchange transaction logs
do not typically fill the log drive because the online backup process or circular
logging automatically removes them.
However, the following unusual conditions or administrative oversights may cause
transaction logs to be generated at an accelerated rate or cause databases to keep
growing in size:
-
Databases may grow because administrators have not set any limits for message, folder,
or mailbox sizes.
-
Databases and transaction log files may grow because of looping messages in the
system. For example, a client that indiscriminately forwards rules to an invalid
external address may cause a non-delivery report (NDR) loop. An NDR loop can occur
when a user creates a rule that forwards all incoming messages to an invalid e-mail
address. The receiving server sends back an NDR when the message arrives at the
destination domain. When this NDR reaches the original user, the forwarding rule
sends it to the same invalid e-mail address, thus generating another NDR. If the
original message was large, and the NDR includes the original message, the NDR loop
can result in rapid automatic generation of large numbers of large messages.
-
Databases and transaction log files may grow because of application activity that
makes rapid changes or generates large numbers of messages. For example, company
developers have been known to test mass-mailing applications in the production mail
system without considering the consequences.
-
Spam or other attacks on the system may generate large numbers of messages and cause
undue growth of mailboxes and transaction log files.
-
Moving a large number of mailboxes from one database to another will generate an
unusual number of transaction logs in the destination storage group.
It is very important to monitor free disk space on Exchange data drives at frequent
intervals. Running out of disk space is one of the most common reasons for an unexpected
database shutdown.
If a drive runs out of free space in Microsoft Exchange Server 2003, the database
can usually commit all outstanding transactions and shut down cleanly. In previous
versions of Exchange, it is more common for the database to suddenly stop in a disk
full condition. In itself, this is not a problem because the transaction log recovery
mechanism is very reliable, and will recover the database and bring it to a clean
shutdown state. However, an administrator in a disk full situation commonly deletes
all the transaction logs to create free space, including the last several transaction
logs required to recover the database. In this case, the database can be recovered
only through repair or restoration. For more information about how to safely recover
from a disk full situation for transaction logs, refer to the Microsoft Knowledge
Base article "How to remove Exchange Server transaction log files" at
http://support.microsoft.com/kb/240145.
Cluster Configuration
Exchange is a Microsoft Cluster Server-aware application. Running Exchange in a
cluster configuration provides additional redundancy and can provide higher availability
than a stand-alone environment can achieve.
However, running Exchange in a cluster means that Exchange administrators must be
trained on Windows clustering as well as on Exchange. Exchange behaves differently
when running in a cluster, and administrators must understand the differences and
requirements. The following white papers are not a substitute for comprehensive
training and experience with Windows clustering, but they do outline the most important
differences and requirements for running Exchange in a clustered environment:
Backup Monitoring
The most fundamental administrator responsibility is to ensure that backups finish,
are good, and can be restored. Yet, because of the tedious and routine nature of
the work, administrators in even the largest and most professional enterprises sometimes
forget to make, validate, and protect backups. System and data failures are infrequent,
and human nature tends to underestimate the importance of mitigating infrequent
risks, even if the consequences are catastrophic. It takes a great deal of operational
discipline to make and test backups consistently.
Microsoft IT successfully backs up its Exchange mailbox servers on a nightly basis
by using the Backup feature in Windows. To do so, Microsoft IT had to make some
specific customizations of Backup parameters. For more information about how Microsoft
IT backs up its Exchange mailbox servers, see the following documents:
Exchange Best Practices Analyzer
The ExBPA tool is based on a rules-based engine that is frequently improved to reflect
the real issues and experience of Exchange administrators and troubleshooters.
For example, a recent hotfix for Transmission Control Protocol/Internet Protocol
(TCP/IP) caused X.400 connectivity problems for some Exchange servers. Soon after
this issue was discovered, ExBPA was updated to check for the problematic hotfix
version and offer guidance to Exchange administrators about working around the problem.
Each time the tool runs, it can check for a new configuration file that contains
updated rules and tests. Microsoft IT recommends running new versions of the tool
at least monthly against representative Exchange servers in an organization (or
against all Exchange servers) to automatically detect new issues and recommend newly
developed best practices.
This tool is available free to every Exchange administrator and can be downloaded
at http://www.microsoft.com/exchange/downloads/2003/exbpa/default.mspx.
Architectural and Operational Issues
This section identifies problems that may require investment in new hardware or
infrastructure, cross-team cooperation, or project planning. Correcting these issues
may require changing the architecture or topology for Exchange, Active Directory,
or the network.
The issues that this section identifies are not in any particular order of severity
or priority. They are all issues that can result in significant avoidable downtime
or reduced performance in any Exchange environment. Although these issues are fundamental,
they deserve to be discussed because many organizations still do not address them.
Storage Configuration
Storage technology has evolved dramatically over the past several years. The choices
available in modern enterprise-class storage devices can be bewildering, and new
features and protocols are being developed at a rapid pace. Storage vendors differentiate
their products with a wide variety of sophisticated capabilities and proprietary
designs. Defining specific best practices for Exchange storage configuration is
difficult, because recommendations are quickly made obsolete by new technologies
or do not apply across products from different vendors.
One constant is that a busy Exchange server makes high demands on underlying storage,
in terms of input/output (I/O) performance and in space required to satisfy client
demands for larger mailboxes. Therefore, it is critical to consult with storage
vendors about best practices for configuring and scaling the storage system to support
the requirements of a particular Exchange organization. All major storage vendors
have detailed best practices for designing Exchange storage.
Thinking of Exchange storage requirements only in terms of disk space is a mistake.
Even more important are the capabilities and limitations of the storage platform
in terms of I/O throughput, redundant array of independent disks (RAID) configuration
options, redundant channels, and recovery options.
For more information about how Microsoft IT designed its Exchange Server 2003 clustered
storage configuration, see the IT Showcase white paper titled Exchange Server 2003
Design and Architecture at Microsoft at
http://www.microsoft.com/technet/itsolutions/msit/deploy/ex03atwp.mspx.
Disk Performance Baselining
The most common cause of poor performance on an Exchange server is inadequate disk
I/O. In general, Exchange is more disk I/O intensive than processor intensive.
An organization should not rely on theoretical I/O calculations alone. Unexpected
bottlenecks in the storage system can cause it to perform very differently from
its theoretical model. Microsoft publishes detailed information about the average
I/O load to be expected for each Exchange user, along with formulas and spreadsheets
to help calculate I/O load for specific environments.
Microsoft provides two tools for modeling Exchange performance:
-
JetStress. This tool is targeted at testing only the disk subsystem. It generates
actual Exchange databases and actual database activity that is similar in complexity
and scale to the actual load on a running database. New disk systems intended for
Exchange use should be tested through JetStress. Not only is JetStress an excellent
tool for performance modeling, but it also can uncover disk defects and instability.
-
LoadSim. LoadSim simulates actual Messaging Application Programming Interface
(MAPI) client activity against an Exchange server. LoadSim setup is more complex
than JetStress setup because LoadSim requires installation of an actual Exchange
server and one or more client workstations to simulate Microsoft Outlook® client
connections to the server. LoadSim is very useful for baselining general server
performance and for validating the overall suitability of the end-to-end Exchange
system.
For more information about the preceding tools and about tuning and baselining for
Exchange, refer to the Exchange Server 2003 Performance and Scalability Guide
at
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/perfscalguide.mspx.
Service Level Agreements
Service level agreements (SLAs) not only drive accountability for the performance
of the Exchange system, but also define the most important considerations in terms
of the performance, reliability, and availability of the e-mail system. Without
high-quality SLAs, it is difficult to appropriately prioritize resources or to appropriately
design an Exchange system. Too frequently, organizations either do not define SLAs
or define them arbitrarily. Poorly designed SLAs divert and waste resources; well-designed
SLAs focus operational and architectural resources on measuring and maintaining
the most important functions of the system.
The IT Showcase paper titled Achieving High Availability with Exchange Server at
Microsoft explains the Microsoft approach to defining SLAs for its internal
Exchange system. This paper also provides examples of how poorly designed SLAs can
lead to bad decisions. This paper is available at
http://www.microsoft.com/technet/itsolutions/msit/operations/exchhighavailTSB.mspx.
Permissions and Credentials Strategy
Microsoft Customer Service and Support recently responded to a CritSit case triggered
by a low-level administrator's deletion of all the public folders in the organization.
The administrator thought that the deletions would affect only a single server,
but the deletions replicated throughout the organization. Fully recovering and repopulating
the data took several days.
This incident illustrates the importance of making conscious decisions about who
will have access to change or destroy Exchange configuration and client data. Many
organizations do not track who has rights to the Exchange system or who has rights
to grant permissions in the Exchange system. Limiting permissions on public folders
(especially those at the top of the hierarchy) is also very important, as the preceding
incident illustrates.
For more information about strategies for administrator and end-user rights and
permissions, refer to the following white papers:
Monitoring
If the usual way that an Exchange administrator in an organization discovers a problem
in the Exchange system is from end-user calls to the helpdesk, the administrator
is not adequately monitoring the system. Not only can effective monitoring allow
administrators to respond to failures more quickly, but it also provides baselining
and measurement of everyday operation. Baseline monitoring enables administrators
to anticipate the need for capacity upgrades or detect unusual conditions before
they cause a failure.
Monitoring every aspect of a large Exchange environment can be a daunting task.
An organization must monitor not only server health, but also the status of communications
between servers, spikes in message traffic that may indicate virus or spam attacks,
and how Exchange is responding to end-user clients. Finding an effective way to
present and manage all that data is critical. It is all too easy to set up monitoring,
and then to forget to look at the resulting data because it is too overwhelming
or disorganized.
Microsoft IT uses Microsoft Operations Manager (MOM) 2005 as its enterprise monitoring
solution. The Exchange management pack for MOM captures, collates, and interprets
Exchange data in a central console that is easy to scan and provides appropriate
alerts. For more information about MOM and Exchange, refer to the following white
papers:
The Exchange Server 2003 Operations Guide also provides valuable information
about keeping an Exchange system healthy. Administrators can download the guide
at
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/opguide.mspx.
Capacity Planning and Load Balancing
One of the aspects of an Exchange environment that an organization should monitor
is the growth in message storage space required as new users come online. Without
planning for growth, an organization can easily neglect this area. Because servers
have to carry more capacity than intended, multiple problems can incubate before
performance degradation becomes evident. If database sizes are growing too large,
backups may not complete or may take too long. Larger databases also require larger
maintenance time windows, which must be balanced against backup time windows. Sudden
spikes in demand may bring a server down if it is already running near its capacity
under normal conditions.
Administrators should set clear targets and limits for server load and capacity,
and closely monitor servers that are nearing that capacity. Bringing new capacity
online smoothly requires plenty of lead time and planning. Having to do it during
an emergency or under time pressure is likely to result in visible end-user downtime
and is likely to be more costly overall.
Change Control and Server Build Documentation
If an Exchange administrator calls Microsoft Customer Service and Support to get
technical support in solving an Exchange problem, one of the first questions that
the product support engineer will likely ask is "What has changed recently?" All
too often, a problem is caused by a change that one person made to the system without
informing anyone else. Knowing about such changes can dramatically shorten the time
required to troubleshoot and resolve such a problem.
Strict change control, including making a plan to back out of a change before making
it, is critical in an enterprise environment. Change control procedures can be annoying
to follow, because they require documenting and notifying other people before doing
things that one person may believe are simple or harmless. However, seemingly simple
changes can have unexpected repercussions. The history and context that change control
documentation provides about a particular environment and configuration are invaluable.
An organization needs thorough change control procedures to achieve high availability.
Closely related are server build documentation and procedures. The more alike and
standardized each system is in an organization, the more easily IT personnel can
manage and understand the systems and detect anomalies. Thorough server build documentation
coupled with strict change control allows reliable rebuild and configuration restoration
of any damaged system.
Microsoft IT uses the Microsoft Operations Framework (MOF) to manage its change
control process. For more information about MOF, see the video titled Introduction
to Microsoft Operations Framework (MOF) Fundamentals at
http://download.microsoft.com/download/3/2/9/329a5e25-aeac-45df-9630-86c65d1e35ef/MOFTrainingMM.wmv.
For additional information, see the MOF Web site at
http://www.microsoft.com/mof.
Disaster Recovery Planning
Disaster recovery planning can occur at many different levels of scope and sophistication.
Disaster recovery planning for a large organization is a complex specialty.
For some organizations, the entire disaster recovery plan consists of performing
regular backups and moving them off site. For a small business or a home computer
user, these activities may be perfectly adequate. Detailed discussion of disaster
recovery planning is beyond the scope of this document, but a fundamental principle
of such planning is that an organization should ensure not only that essential data
is preserved, but also that the data can be restored as quickly as needed after
a disaster. Every IT manager must assess whether disaster recovery planning has
occurred at the appropriate level for the organization.
A part of the disaster recovery plan of many large Exchange customers is to call
Microsoft Customer Service and Support. Microsoft Customer Service and Support consists
of expert engineers and product specialists whose everyday job is to respond to
disasters.
However, how well Microsoft Customer Service and Support or other experts can help
in recovery depends greatly on how well prepared an organization is before a disaster.
A lack of redundant infrastructure, spare parts, or trained personnel who understand
the architecture and systems will greatly hamper the recovery efforts of support
personnel. If there are no backups of critical data, Microsoft Customer Service
and Support cannot help to recover it.
The following white papers provide advice about developing an Exchange disaster
recovery plan:
Active Directory Architecture
Exchange Server 2003 must be used with Active Directory. In fact, if Exchange cannot
access an Active Directory global catalog server, none of the services of Exchange
can even start. The great majority of an Exchange server's individual configuration
is stored in Active Directory, not on the Exchange server. This design choice enables
automatic rebuild of a destroyed Exchange server, restoring almost all its previous
configuration simply by running the Exchange Setup program with the /disasterrecovery
startup switch.
During normal operation, Exchange queries and writes to Active Directory frequently.
In most organizations, Exchange is the heaviest user of Active Directory, with the
exception of client logon and authentication services. If responses to requests
from Exchange to Active Directory slow down, everything in Exchange slows down.
After a certain point, not only does this slowdown affect system performance proportionally,
but Active Directory slowness can become a bottleneck that can make message transfer
stop completely.
It is critical that the Active Directory design takes into account not only Exchange
load, but also placement of Exchange servers and clients. Designing Active Directory
correctly for Exchange is not incredibly complicated, but there are important principles
that an organization must follow to prevent Active Directory issues from becoming
a perennial problem. The following white papers provide information about Exchange
requirements:
Active/Active Clustering
An organization should not run Microsoft Exchange 2000 or Exchange Server 2003 in
a two-node active/active clustering configuration. This configuration is one in
which an Exchange Virtual Server instance runs on each node of the cluster during
normal circumstances. In the event of a failure, each Exchange instance can fail
over to the other node. In this case, the surviving cluster node must run both Exchange
instances.
Instead, an organization should run Exchange in an active/passive cluster node configuration,
whether the cluster has two or more nodes. (Clusters with more than two nodes require
Windows Server 2003 or Microsoft Windows 2000 Datacenter Edition.) In an active/passive
configuration, no cluster node ever runs more than one Exchange instance. Failover
is allowed only to nodes that are not already running an Exchange instance.
Leaving the passive nodes in a cluster idle except in an emergency may seem wasteful.
This perception may lead administrators to prefer active/active configurations.
When Exchange 2000 was released, Microsoft allowed two-node active/active clustering
to address this customer concern. However, real-world experience has shown that
using active/active clustering for Exchange is not a best practice for the following
reasons:
-
One of the strongest motivators for wanting to use active/active clustering is cost
savings. Therefore, each cluster node will sometimes be designed to handle its normal
load, but without enough additional capacity to efficiently handle another Exchange
instance. Although a technology architect may believe that degraded performance
is acceptable in an emergency, the reality is that after a disaster, the Exchange
server instances will likely be placed under even greater than normal load (for
example, as all clients try to come back online at once). A good recovery plan anticipates
providing as much or more capacity as under normal conditions.
-
A properly designed active/active cluster cannot handle as much client load as an
active/passive cluster. It is possible to safely place more mailboxes on a single
Exchange instance in an active/passive configuration than on two instances in an
active/active configuration. In terms of its actual ability to handle load and retain
high availability, an active/passive configuration can scale higher than an active/active
configuration.
-
Failover is more reliable, is faster, and requires fewer resources in an active/passive
configuration. In an active/active configuration, failover occurs to a cluster node
that is already busy hosting an Exchange instance or another application. The failover
will affect an already running server, and it may exhaust critical system resources
that multiple application instances must now share.
For information about how Microsoft IT designs its Exchange clusters and how it
uses passive nodes for tasks other than running an Exchange instance, refer to Backup
Process Used with Clustered Exchange Server 2003 Servers at Microsoft at
http://www.microsoft.com/technet/itsolutions/msit/operations/exchbkup.mspx.
For more information about limitations and best practices that an organization can
follow when running Exchange in an active/active cluster configuration, refer to
the Microsoft Knowledge Base article "Considerations when deploying Exchange on
an Active/Active cluster" at http://support.microsoft.com/kb/815180.
Conclusion
Much of the information in this paper is common knowledge for Exchange administrators.
Although the issues may seem obvious, the ExRAP found that even very large organizations
frequently overlook them. An organization can examine its own practices and configuration
against the topics of this paper to potentially reveal important issues that have
been neglected in its Exchange environment.
For More Information
For more information about Microsoft products or services, call the Microsoft Sales
Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information
Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact
your local Microsoft subsidiary. To access information through the World Wide Web,
go to: