Export (0) Print
Expand All

Reliability and Clustering Features of Exchange Server 2003

 

Topic Last Modified: 2005-05-25

This chapter provides information about some of the significant updates related to Microsoft® Exchange Server 2003 reliability and clustering. For complete information about how to ensure your Exchange 2003 environment is reliable with or without implementing Exchange clustering, see "Planning for Reliability" in the book Planning an Exchange Server 2003 Messaging System.

To increase the reliability of your Exchange organization, Exchange 2003 offers the following new or improved features:

Virtual memory management

The virtual memory improvements to Exchange 2003 reduce memory fragmentation and increase server availability.

Mailbox Recovery Center

The new Mailbox Recovery Center makes it easy to perform simultaneous recovery or export operations on multiple disconnected mailboxes.

Recovery Storage Group

The new Recovery Storage Group is a specialized storage group that can exist alongside the regular storage groups in Exchange. Essentially, the Recovery Storage Group provides flexibility in restoring mailboxes and mailbox databases.

Error reporting

The error-reporting component is improved in Exchange 2003. Exchange error reporting allows you to send information about any failures that may occur to Microsoft. Microsoft then uses that information to determine and prioritize potential updates to future product versions.

This section discusses each of these features in detail.

In Exchange 2003, the virtual memory management process is improved. Specifically, Exchange is much more efficient in the way it reuses blocks of virtual memory. These design improvements reduce fragmentation and increase availability for higher-end servers that have a large number of users.

Virtual memory management for clustered Exchange servers is also improved. In previous versions of Exchange, the Microsoft Exchange Information Store service (MSExchangeIS) continues to run on a passive node. As a result, if an Exchange Virtual Server is moved manually or failed back automatically to a node that failed, MSExchangeIS service runs on the server with fragmented virtual memory.

In Exchange 2003, when an Exchange Virtual Server is either moved manually or failed over to another node, the MSExchangeIS service on that node is stopped. Then, when an Exchange Virtual Server is moved or failed back to that node, a new MSExchangeIS service is started and, consequently, a fresh block of virtual memory is allocated to the service.

Even with these improvements to virtual memory, it is still important that you monitor virtual memory performance. The following table lists the MSExchangeIS counters used to monitor virtual memory performance.

Performance monitors for virtual memory

Counter Description

VM Largest Block Size

Displays the size (in bytes) of the largest free block of virtual memory. This counter is a line that slopes downward as virtual memory is consumed. When this counter drops below 32 MB, Exchange 2000 logs a warning in the event log (Event ID=9582) and logs an error if it drops below 16 MB. It is important to monitor this counter to ensure that it stays above 32 MB.

VM Total 16MB Free Blocks

Displays the total number of free virtual memory blocks that are greater than or equal to 16 MB. This line forms a pyramid as you monitor it. It starts with one block of virtual memory greater than 16 MB and progresses to smaller blocks greater than 16 MB. Monitoring the trend on this counter should allow a system administrator to predict when the number of 16 MB blocks is likely to drop below 3, at which point restarting all the services on the node is recommended.

VM Total Free Blocks

Displays the total number of free virtual memory blocks, regardless of size. This line forms a pyramid as you monitor it. This counter can be used to measure the degree to which available virtual memory is being fragmented. The average block size is the Process\Virtual Bytes\STORE instance divided by MSExchangeIS\VM Total Free Blocks.

VM Total Large Free Block Bytes

Displays the sum (in bytes) of all the free virtual memory blocks that are greater than or equal to 16 MB. This line slopes downward as memory is consumed.

When you monitor these counters, pay close attention that VM Total Large Free Block Bytes always exceeds 32 MB. For non-clustered servers, if VM Total Large Free Block Bytes drops below 32 MB, restart the services on that server. For clustered servers, if a node in the cluster drops below 32 MB, fail over the Exchange Virtual Servers, restart all of the services on the node, and then fail back the Exchange Virtual Servers.

If the virtual memory for your Exchange 2003 server becomes excessively fragmented, the MSExchangeIS service logs the following events (Examples 1 and 2).

Example 1   Warning that is logged if the largest free block is smaller than 32 MB.

EventID=9582

Severity=Warning

Facility=Perfmon

Language=English

The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.

Example 2   Error that is logged if the largest free block is smaller than 16 MB.

EventID=9582

Severity=Error

Facility=Perfmon

Language=English

The virtual memory necessary to run your Exchange server is fragmented in such a way that normal operation may begin to fail. It is highly recommended that you restart all Exchange services to correct this issue.

For more information about System Monitor and Event Viewer, see the Microsoft Windows Server™ 2003 online documentation.

Using the new Mailbox Recovery Center, you can perform simultaneous recovery or export operations on multiple disconnected mailboxes. This is a significant improvement over Exchange 2000, where such operations had to be performed individually on each disconnected mailbox. With this new feature, you can quickly restore Exchange mailboxes, and thereby reduce downtime.

With the addition of the Recovery Storage Group, Exchange 2003 provides added flexibility in restoring mailboxes and storage groups. With this new feature, you can quickly restore Exchange data, and thereby reduce downtime. For more information about using the Recovery Storage Group feature, see "Recovery Storage Groups" in Storage Features of Exchange Server 2003.

Although error reporting was included in Exchange 2000 SP2 and SP3, its implementation is improved in Exchange 2003.

Error reporting allows server administrators to easily report errors to Microsoft. Microsoft collects the error reports, and then uses the information to improve product functionality. By default, when fatal application errors occur in Exchange System Manager or an Exchange-related operation of Active Directory Users and Computers, a warning message notifies administrators of the error. Specifically, the message states that the application must close and provides an option to send an error report to Microsoft.

Warning message that displays after a fatal Exchange System Manager error occurs

0a1a6c60-8943-45c9-ac44-1d8b7e2c78b3

Similarly, when fatal service-related errors occur that relate to Exchange, a dialog box appears that provides and option to send a report to Microsoft.

The Microsoft Event Reporting dialog box that displays after service-related errors occur

202e46f6-0f0a-43ff-b1c7-4717b873f67e
noteNote:
By default, a service-related fatal error does not immediately initiate an error reporting prompt. Instead, the prompt for service-related errors appears the next time you log on to the server.

The error report is sent to Microsoft over a secure HTTPS connection, and usually consists of a 10 to 50 KB compressed file. The error report is known as a minidump file. For detailed technical information about how the information in a minidump file is gathered and sent, see Using Dr. Watson. For general information about error reporting, see Should I send Microsoft an error report when my program crashes?

Exchange 2000 SP2 and SP3 supported the standard error reporting dialog box that provided administrators with the option to send error reports to Microsoft. Exchange 2003 supports the same error reporting functionality included in Exchange 2000 SP3, including the following new features:

  • Exchange service-related errors (that occur close to each other in time), are queued and then presented to the administrator in a single list.

    noteNote:
    For information about how you can configure Exchange to automatically send service-related errors to Microsoft without requiring the administrator to use the error reporting dialog box, see "Configuring Exchange to Automatically Send Service-Related Error Reports" later in this section.
  • Corporate Error Reporting (CER) is now supported. CER is a tool designed for administrators to manage error reports created by the Microsoft Windows Error Reporting client, as well as error-reporting clients shipped with applications. For information about installing and using CER, see Corporate Error Reporting Web site.

  • Additional support for Exchange Setup errors (including queuing the errors so they are all presented to the administrator in a single list after Setup completes).

  • Improved support for errors relating to the Recipient Update Service. In Exchange 2003, critical errors relating to the Recipient Update Service (for example, access violations that occur when Recipient Update Service attempts to update a recipient object) now immediately generate a Microsoft Error Reporting error message that allows you to send information about the error to Microsoft. This is important, because RUS-related errors leave the System Attendant in an unstable state.

    These Recipient Update Service-related error reports are a significant improvement over Exchange 2000. In Exchange 2000, any Recipient Update Service-related errors resulted in an event being written to the Event Log. As a result, administrators were not immediately notified of the errors.

For detailed information about configuring Exchange to automatically send service-related error reports, see How to Enable Automatic Service-Related Error Reporting.

This section provides information about some of the significant updates related to Exchange 2003 clustering. For complete information about Exchange 2003 clustering, see the following references:

Exchange 2003 provides the following new or improved clustering features:

Support for up-to eight nodes

Exchange has added support for up to 8-node active/passive clusters when using Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition.

Support for volume mount points

Exchange has added support for the use of volume mount points when using Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition.

Improved failover performance

Exchange has improved clustering performance by reducing the amount of time it takes a server to failover to a new node

Improved security

Exchange cluster servers are now more secure. For example, the Exchange 2003 permissions model has changed.

Improved prerequisite checking

Exchange performs more prerequisite checks to help ensure your cluster servers are deployed and configured properly.

This section discusses each of these features in detail.

Exchange 2003 enhances clustering capabilities by introducing support for eight-node Exchange clusters. Eight-node clusters are supported only when running Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition. Another requirement for eight-node clusters is that at least one node must be passive.

noteNote:
All Exchange 2003 clustering recommendations are for active/passive cluster configurations. Active/active clustering will continue to be supported on two nodes.

Specific versions of Windows Server and Exchange Server are required to create Exchange clusters. The following table lists these requirements.

Windows and Exchange version requirements

Windows version Exchange version Cluster nodes available

Any server in the Windows® 2000 Server or Window Server 2003 families

Exchange Server 2003, Standard Edition

None

Windows 2000 Server or Windows Server 2003, Standard Edition

Exchange Server 2003, Standard Edition or Exchange Server 2003, Enterprise Edition

None

Windows 2000 Advanced Server

Exchange Server 2003, Enterprise Edition

Up to two

Windows 2000 Datacenter Server

Exchange Server 2003, Enterprise Edition

Up to four

Windows Server 2003, Enterprise Edition

Exchange Server 2003, Enterprise Edition

Up to eight

Windows Server 2003, Datacenter Edition

Exchange Server 2003, Enterprise Edition

Up to eight

Volume mount points are now supported on shared disks when the nodes of your cluster are running Window Server 2003 Enterprise Edition or Datacenter Edition with four or more nodes. Volume mount points are directories that point to specified disk volumes in a persistent manner (for example, you can configure C:\Data to point to a disk volume). Mount points bypass the need to associate each disk volume with a drive letter, thereby surpassing the 26 drive letter limitation.

For more information about mounted drives, see the Windows Server 2003 documentation.

For clustering in Exchange 2003, the amount of time it takes to failover to another node is reduced, thereby improving overall performance. This section provides information about these improvements to failover times.

To decrease the amount of time it takes to failover a server, Exchange 2003 provides an improved dependency hierarchy for Exchange services. Specifically, the Exchange protocol services, which were previously dependent on the Microsoft Exchange Information Store service, are now dependent on the Microsoft Exchange System Attendant service.

Hierarchy of Exchange dependencies in Exchange 2000

c93a76b1-f25b-497b-a416-caf2b99d74d2

Hierarchy of Exchange dependencies in Exchange 2003

34714516-6877-475d-897a-50e0ab4735b4
noteNote:
In Exchange 2003, the IMAP4 and POP3 resources are not created automatically when you create a new Exchange Virtual Server.

If a failover occurs, this improved hierarchy allows the Exchange mailbox stores, public folder stores, and Exchange protocol services to start simultaneously. As a result, all Exchange resources (except the System Attendant service) can now start and stop simultaneously, thereby improving failover time. Additionally, if the Exchange store stops, it is no longer dependent on other services to restart.

Another benefit is the reduction of downtime resulting from an Exchange Virtual Server failover. This reduction can save several minutes, which is significant when you consider that the average failover time for an Exchange Virtual Server running on Windows 2000 was only three to eight minutes (depending on the number of users hosted by the Exchange Virtual Server).

When running Exchange 2003 on Windows Server 2003, the speed at which Exchange detects an available node and then fails over to that node is reduced. Therefore, for both planned and unplanned failovers, downtime is reduced.

Exchange 2003 clustering includes the following security features:

  • Permission improvements

  • Kerberos enabled by default

  • IPSec support for front-end and back-end servers

  • IMAP4 and POP3 services no longer included when creating Exchange Virtual Servers

This section discusses each of these features in detail.

The permissions needed to create, delete, or modify an Exchange Virtual Server are modified in Exchange 2003. The best way to understand these modifications is to compare the Exchange 2000 permissions model with the new Exchange 2003 permissions model.

For an Exchange 2000 cluster administrator to create, delete, or modify an Exchange Virtual Server, the cluster administrator and the Cluster Service account require the following permissions:

  • If the Exchange Virtual Server is the first Exchange Virtual Server in the Exchange organization, the cluster administrator's account and the Cluster Service account must each be a member of a group that has the Exchange Full Administrator role applied at the organization level.

  • If the Exchange Virtual Server is not the first Exchange Virtual Server in the organization, the cluster administrator's account and the Cluster Service account must each be a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

In Exchange 2003, the permissions model has changed. The Windows Cluster Service account no longer requires that the Exchange Full Administrator role be applied to it, neither at the Exchange organization level nor at the administrative group level. The Windows Cluster Service account requires no Exchange-specific permissions. Its default permissions in the forest are sufficient for it to function in Exchange 2003. Only the logon permissions of the cluster administrator are required to create, modify, and delete Exchange Virtual Servers.

As with Exchange 2000, the cluster administrator requires the following permissions:

  • If the Exchange virtual server is the first Exchange Virtual Server in the organization, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at the organization level.

  • If the Exchange virtual server is not the first Exchange Virtual Server in the organization, you must use an account that is a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

However, depending on the mode in which your Exchange organization is running (native mode or mixed mode), and depending on your topology configuration, your cluster administrators must have the following additional permissions:

  • When your Exchange organization is in native mode, if the Exchange virtual server is in a routing group that spans multiple administrative groups, then the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at all the administrative group levels that the routing group spans. For example, if the Exchange Virtual Server is in a routing group that spans the First Administrative Group and Second Administrative Group, the cluster administrator must use an account that is a member of a group that has the Exchange Full Administrator role applied at First Administrative Group and must also be a member of a group that has the Exchange Full Administrator role applied at Second Administrative Group.

    noteNote:
    Routing groups in Exchange native-mode organizations can span multiple administrative groups. Routing groups in Exchange mixed-mode organizations cannot span multiple administrative groups.
  • In topologies such as parent/child domains where the cluster server is the first Exchange server in the child domain, the cluster administrator must be a member of a group that has the Exchange Administrator role or greater applied at the organization level to be able specify the server responsible for Recipient Update Service in the child domain.

The Kerberos authentication protocol is a security protocol that verifies data to help ensure that both user and network services are safe. In Exchange 2000, the default authentication for Exchange Virtual Servers was the NTLM protocol. This is because the Windows Cluster service did not support Kerberos enablement of a cluster group until Windows 2000 Service Pack 3 (SP3).

In Exchange 2003, the Kerberos authentication protocol is enabled by default when you create an Exchange Virtual Server on a server running Windows Server 2003 or Windows 2000 SP3.

You can use Internet Protocol security (IPSec) if a secure channel is required between front-end and back-end cluster servers. This configuration is fully supported when both the front-end servers and back-end servers are running Exchange 2003 on Windows Server 2003.

Because IMAP4 and POP3 protocols are not needed on all Exchange servers, the IMAP4 and POP3 protocol resources are no longer created when you create an Exchange Virtual Server.

Exchange 2003 performs more prerequisite checks on clusters than previous versions of Exchange. For example, Exchange performs more preinstallation checks on the nodes of your cluster to help ensure that Exchange is installed on your cluster nodes correctly. Similarly, Exchange 2003 performs more checks on your cluster when creating and removing Exchange Virtual Servers to help ensure that your Exchange Virtual Servers are configured correctly.

There are important requirements you must consider when planning your upgrade or installing Exchange 2003 on a Windows 2000 Server or Windows Server 2003 cluster. These requirements include:

  • System-wide requirements that define how you should configure Domain Name System (DNS).

  • Server-specific requirements that define which Windows operating systems are supported with specific types of cluster deployments.

  • Network configuration requirements that help ensure proper communication between the nodes of your cluster.

For complete information about these requirements, see "Cluster Requirements" in the Exchange Server 2003 Deployment Guide.

There are a number of requirements that must be met before upgrading or installing Exchange 2003 on Windows 2000 Server or Windows Server 2003. Many of these requirements are the same as the ones you must follow to install Exchange 2003 on a stand-alone (non-clustered) server. For example, you must ensure that Internet Information Services and other Windows services are running before you run Exchange Server 2003 Setup on the nodes of your cluster. Similarly, you must ensure that Active Directory is prepared for Exchange 2003.

There are also additional requirements to consider when running Exchange Server 2003 Setup on the nodes of your cluster. For example, you must first install Microsoft Distributed Transaction Coordinator (MSDTC) on the cluster.

For the requirements and procedures for installing Exchange 2003 in a cluster, see "Deploying a New Exchange 2003 Cluster" or "Upgrading an Exchange 2000 Cluster to Exchange 2003" in the Exchange Server 2003 Deployment Guide.

To upgrade a cluster from Exchange 2000 to Exchange 2003, you must first run Exchange Server 2003 Setup to upgrade the nodes of your cluster, and then use Cluster Administrator to upgrade the Exchange Virtual Servers. It is recommended that you upgrade one Exchange cluster node at a time.

When you upgrade each node, it is recommended that you move the Exchange Virtual Server from the node you are upgrading to another node. This procedure enables users to access their e-mail messages through the relocated Exchange Virtual Server during the Exchange 2003 upgrade process.

The following tables explain the requirements for upgrading Exchange 2000 cluster nodes and Exchange Virtual Servers to Exchange 2003.

noteNote:
For information about how to upgrade your Exchange 2000 cluster to Exchange 2003, see "Upgrading an Exchange 2000 Cluster to Exchange 2003" in the Exchange Server 2003 Deployment Guide.

Requirements for upgrading a cluster node

Area Requirements

Permissions

  • Account must be a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

Cluster resources

  • No cluster resources can be running on the node you are upgrading because Exchange Setup will need to recycle the Cluster service. One-node clusters are exempt.

  • The MSDTC resource must be running on one of the nodes in the cluster.

Other

  • Only servers running Exchange 2000 SP3 or later can be upgraded to Exchange 2003. If your servers are running previous versions of Exchange, you must first upgrade to Exchange 2000 SP3 or later.

  • You must upgrade your cluster nodes one at a time.

  • The Cluster service must be initialized and running.

  • If there are more than two nodes, the cluster must be active/passive. If there are two nodes or fewer, active/active is allowed.

If running Windows 2000

Requirements for upgrading an Exchange Virtual Server

Area Prerequisites

Permissions

  • If the Exchange Virtual Server is the first server to be upgraded in the organization or is the first server to be upgraded in the domain, the account must be a member of a group that has the Exchange Full Administrator role applied at the organization level.

  • If the Exchange Virtual Server is not the first server to be upgraded in the organization or the first Exchange server to be upgraded in the domain, the account only needs to be a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

Cluster resources

  • The Network Name resource must be online.

  • The Physical Disk resources must be online.

  • The System Attendant resource must be offline.

Other

  • The version of Exchange on the computer running Cluster Administrator must be the same version as the node that owns the Exchange Virtual Server.

  • You must upgrade your Exchange Virtual Servers one at a time.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft