Microsoft Exchange Server

Home , GNOME Evolution, Microsoft Entourage, Microsoft Messaging, Windows Messaging

Developer(s) Microsoft Corporation

Initial release June 11, 1996

Microsft Exchange Server 2010 Stable release Edition RTM[1] / November 9, 2009; 7 months ago

Development status Active

Written in C, C++

Operating system Microsoft Windows

Platform x86-64 (64-bit)

Available in Multilingual

Type Collaborative software

License Proprietary (MS-EULA)

Website www.microsoft.com/exchange

Microsoft Exchange Server is the server side of a client–server, collaborative application product developed by Microsoft. It is part of the Microsoft Servers line of server products and is used by enterprises using Microsoft infrastructure solutions. Exchange's major features consist of electronic mail, calendaring, contacts and tasks; support for mobile and web-based access to information; and support for data storage. Contents

 1 History o 1.1 Exchange 1.0 o 1.2 Exchange Server 4.0 o 1.3 Exchange Server 5.0 o 1.4 Exchange 2000 Server o 1.5 Exchange Server 2003 . 1.5.1 Editions o 1.6 Exchange Server 2007 . 1.6.1 New features o 1.7 Exchange Server 2010  2 Clustering and high availability  3 Licensing  4 Exchange hosting  5 Clients o 5.1 ActiveSync  6 See also  7 References o 7.1 Books  8 External links History

Planning the migration from Microsoft's internal "legacy XENIX-based messaging system" to Exchange Server environment began in April 1993 [2], and by January 1995 some 500 users were running on Exchange Server Beta 1. By April 1996 32,000 users were migrated to that environment.

Exchange 1.0

Microsoft Exchange 1.0

Windows Messaging running on Windows NT 4.0.

Developer(s) Microsoft

4.00.835.1374 (version 5.0) / Stable release October 14, 1996

Operating system Microsoft Windows

Type E-mail client

License Proprietary EULA

Website Exchange update for Windows 95

Windows Messaging, initially called Microsoft Exchange, is an e-mail client that was included with Windows 95 (beginning with OSR2), 98 and Windows NT 4.0. In Windows 98, it is not installed by default, but available as a separate program in the setup CD. Microsoft Exchange gained wider usage with the release of Windows 95, as this was the only e-mail client that came bundled with it. Exchange was included throughout later releases of Windows up until the initial release of Windows 98, which by then also included Outlook Express 4.0.

 In 1996, Microsoft Exchange was renamed Windows Messaging, because of Microsoft's release of another Exchange product, which was meant for servers.  Windows Messaging had two branches of successors: o In software bundled with Windows itself, these were Internet Mail and News in Windows 95 (and bundled with Internet Explorer 3), which was succeeded by Outlook Express 4.0 in Windows 98 (bundled with Internet Explorer 4.0 in Windows 95) and throughout newer Windows systems. These did not use the .pst file type. o Microsoft Outlook became the professional-grade and more direct successor of MS Exchange Client, which still uses the .pst file type.

Microsoft Fax, also called Microsoft at Work Fax (AWF), is the fax component to provide Send- and-Receive Fax capability; sent and received faxes were stored in the same .pst file as other messages, first attempt of unified messaging by Microsoft; also the ability to act as fax server[3], which is not available in later versions of Windows until Windows Vista

 Because Microsoft Outlook used the same basic Windows Messaging profile, account and e-mail settings (MAPI), MS Exchange users not familiar with it could have been led into thinking that Outlook created a double profile and that it made copies of all their mail while they were just checking to see what the new MS Outlook (ver. 97) looked like. This way some MS Exchange users could have unknowingly deleted all their e-mail that they perceived to be 'double', as MS Outlook did not have any front-end feature to notify users that it was actually using the same MS Exchange / Windows Messaging account.  The original version lacks support of Internet mail (SMTP and POP3 support). They are only available with the other-purchased Microsoft Plus! pack.  No support for International characters. Some e-mail that was sent with a non-ASCII or non-7/8-bit character set, was shown in the form of text attachments, which had to be saved and then read in a web browser, with the browser's text encoding set for a specified code page.  HTML e-mail was shown in such a way that the message contained an *.ATT or *.htm attachment, which had to be saved and then viewed in a browser, as MS Exchange did not have support for HTML-formatted messages.  In a similar fashion, e-mail that did not use traditional message formatting, was shown the same way: actual message content was delivered in the form of text attachments with the *.ATT extension, which could be opened through Notepad. These files were in turn saved in the active Temp directory and some sensitive e-mail could therefore have been made available for other users to see.

Exchange Server 4.0

Exchange Server 4.0, released on June 11, 1996, was the original version of Exchange Server sold to the public, positioned as an upgrade to Microsoft Mail 3.5. The original version of Microsoft Mail (written by Microsoft) had been replaced, several weeks after Lotus acquired cc:Mail, by a package called Network Courier, acquired during the purchase of Consumer Software Inc. in April 1991.[4] Exchange Server was however an entirely new X.400-based client–server mail system with a single database store that also supported X.500 directory services. The directory used by Exchange Server eventually became Microsoft's Active Directory service, an LDAP-compliant directory server. Active Directory was integrated into Windows 2000 as the foundation of Windows Server domains.

Exchange Server 5.0

On May 23, 1997, Exchange Server 5.0 was released, which introduced the new Exchange Administrator console, as well as opening up "integrated" access to SMTP-based networks for the first time. Unlike Microsoft Mail (which required a standalone SMTP relay), Exchange Server 5.0 could, with the help of an add-in called the Internet Mail Connector, communicate directly with servers using . Version 5.0 also introduced a new Web-based e-mail interface Exchange Web Access, this was rebranded as Outlook Web Access in a later Service pack. Along with Exchange Server version 5.0, Microsoft released version 8.01 of Microsoft Outlook, version 5.0 of the Microsoft Exchange Client and version 7.5 of Microsoft Schedule+ to support the new features in the new version of Exchange Server.

Exchange Server 5.5, introduced November, 1997, was sold in two editions, Standard and Enterprise. They differ in database store size, mail transport connectors and clustering capabilities. The Standard Edition had the same 16 GB database size limitation as earlier versions of Exchange Server, while the Enterprise Edition had an increased limit of 16 TB (although Microsoft's best practices documentation recommends that the message store not exceed 100 GB). The Standard Edition includes the Site Connector, MS Mail Connector, Internet Mail Service (previously "Internet Mail Connector"), and Internet News Service (previously "Internet News Connector"), as well as software to interoperate with cc:Mail, Lotus Notes and Novell GroupWise. The Enterprise Edition adds an X.400 connector, and interoperability software with SNADS and PROFS. The Enterprise Edition also introduced two node clustering capability. Exchange Server 5.5 introduced a number of other new features including a new version of Outlook Web Access with Calendar support, support for IMAP4 and LDAP v3 clients and the Deleted Item Recovery feature. Exchange Server 5.5 was the last version of Exchange Server to have separate directory, SMTP and NNTP services. There was no new version of Exchange Client and Schedule+ for version 5.5, instead version 8.03 of Microsoft Outlook was released to support the new features of Exchange Server 5.5.

Exchange 2000 Server

Exchange 2000 Server (v6.0, code name Platinum), released on November 29, 2000, overcame many of the limitations of its predecessors. For example, it raised the maximum sizes of databases and increased the number of servers in a cluster from two to four. However, many customers were deterred from upgrading by the requirement for a full Microsoft Active Directory infrastructure to be in place, as unlike Exchange Server 5.5, Exchange 2000 Server had no built- in Directory Service, and had a dependency upon Active Directory. The migration process from Exchange Server 5.5 did not have any in-place upgrade path, and necessitated having the two systems online at the same time, with user-to-mailbox mapping and a temporary translation process between the two directories. Exchange 2000 Server also added support for Instant Messaging, but that capability was later spun off to Microsoft Office Live Communications Server.

Exchange Server 2003

Exchange Server 2003 (v6.5, code name Titanium) debuted on September 28, 2003. Exchange Server 2003 (currently at Service Pack 2) can be run on Windows 2000 Server (only if Service Pack 4 is first installed) and 32-bit Windows Server 2003, although some new features only work with the latter. Like Windows Server 2003, Exchange Server 2003 has many compatibility modes to allow users to slowly migrate to the new system. This is useful in large companies with distributed Exchange Server environments who cannot afford the downtime and expense that comes with a complete migration.

The June 2, 2003, release of Exchange Server 2003 made the migration from pre-2000 versions of Exchange significantly easier (although still involved the same basic steps), and many users of Exchange Server 5.5 waited for the release of Exchange Server 2003 to upgrade. The upgrade process also required upgrading a company's servers to Windows 2000. Some customers opted to stay on a combination of Exchange Server 5.5 and Windows NT 4.0, both of which are no longer supported by Microsoft.

One of the new features in Exchange Server 2003 is enhanced disaster recovery which allows administrators to bring the server online more quickly. This is done by allowing the server to send and receive mail while the message stores are being recovered from backup. Some features previously available in the Microsoft Mobile Information Server 2001/2002 products have been added to the core Exchange Server product, like Outlook Mobile Access and server- side ActiveSync, while the Mobile Information Server product itself has been dropped. Better anti-virus and anti-spam protection have also been added, both by providing built-in APIs that facilitate filtering software and built-in support for the basic methods of originating IP address, SPF ("Sender ID"), and DNSBL filtering which were standard on other open source and *nix- based mail servers. Also new is the ability to drop inbound e-mail before being fully processed, thus preventing delays in the message routing system. There are also improved message and mailbox management tools, which allow administrators to execute common chores more quickly. Others, such as Instant Messaging and Exchange Conferencing Server have been extracted completely in order to form separate products. Microsoft now appears to be positioning a combination of Microsoft Office, Microsoft Office Live Communications Server, Live Meeting and Sharepoint as its collaboration software of choice. Exchange Server is now to be simply e-mail and calendaring.

Exchange Server 2003 added several basic filtering methods to Exchange Server. They are not sophisticated enough to eliminate spam, but they can protect against DoS and mailbox flooding attacks. Exchange Server 2000 supported the ability to block a sender's address, or e-mail domain by adding '*@domain.com', which is still supported in Exchange Server 2003. Added filtering methods in Exchange Server 2003 are:

Connection filtering Messages are blocked from DNS RBL lists[5] or from manually specified IP addresses/ranges Recipient filtering Messages blocked when sent to manually specified recipients on the server (for intranet- only addresses) or to any recipients not on the server (stopping spammers from guessing addresses) Sender ID filtering Sender ID, a form of Sender Policy Framework (SPF) Intelligent Message Filter A free Microsoft add-on that uses heuristic message analysis to block messages or direct them to the "Junk E-Mail" folder in Microsoft Outlook clients.[6]

Exchange 2003 mainstream support ended on April 14, 2009[7].

Editions

Exchange Server 2003 is available in two versions, Standard Edition and Enterprise Edition. Standard Edition supports up to two storage groups (with one of the storage groups, called the recovery storage group, being reserved for database recovery operations) and a maximum of 2 databases per storage group. Each database is limited to a maximum size of 16GB.[8] Beginning with the release of Service Pack 2, Standard Edition allows a maximum database size of 75 GB, but only supports 18 GB by default; larger sized databases have to be updated-in with a registry change.[9] Enterprise Edition allows an 16 TB maximum database size, and supports up to 4 storage groups with 5 databases per storage group for a total of 20 databases per server.[10]

Exchange Server 2003 is included with both Microsoft Small Business Server 2003 Standard and Premium editions and is 32-bit only, and will not install on the various 64-bit versions of Windows Server 2003.

Exchange Server 2007

Exchange Server 2007 was released on November 30, 2006, to business customers as part of Microsoft's roll-out wave of new products. It includes new clustering options, 64-bit support for greater scalability, voice mail integration, better search and support for Web services, better filtering options, and a new Outlook Web Access interface. Exchange 2007 also dropped support for Exchange 5.50 migrations, routing groups, admin groups, Outlook Mobile Access, X.400, and some API interfaces, amongst other features.[11]

Exchange Server 2007 (v8, code name E12, or with SP1 v8.1) runs only on 64-bit x86-64 versions of Windows Server. This requirement applies to supported production environments only; a 32-bit trial version is available for download and testing. Hence, companies currently running Exchange Server on 32-bit hardware will be required to replace or migrate hardware if they wish to upgrade to the new version. Companies that are currently running Exchange Server on 64-bit capable hardware are still required to migrate from their existing Exchange 2000/2003 servers to a new 2007 server since in-place upgrades are not supported in 2007.

The first beta of Exchange Server 2007 (then named "Exchange 12" or E12) was released in December 2005 to a very limited number of beta testers. A wider beta was made available via TechNet Plus and MSDN subscriptions in March 2006 according to the Microsoft Exchange team blog.[12] On April 25, 2006, Microsoft announced that the next version of Exchange Server would be called Exchange Server 2007.

Exchange Server 2007 is an integrated part of the Innovative Communications Alliance products.[13]

New features

The principal enhancements, as outlined by Microsoft, are:[14]

 Protection: anti-spam, antivirus, compliance, clustering with data replication, improved security and encryption  Improved Information Worker Access: improved calendaring, unified messaging, improved mobility, improved web access  Improved IT Experience: 64-bit performance & scalability, command-line shell & simplified GUI, improved deployment, role separation, simplified routing  Exchange Management Shell: a new command-line shell and scripting language for system administration (based on Windows PowerShell). Shell users can perform every task that can be performed in the Exchange Server graphical user interface plus additional tasks, and can program often-used or complex tasks into scripts that can be saved, shared, and re-used. The Exchange Management Shell has over 375 unique commands to manage features of Microsoft Exchange Server 2007.[15]  "Unified Messaging" that lets users receive voice mail, e-mail, and faxes in their mailboxes, and lets them access their mailboxes from cell phones and other wireless devices. Voice commands can be given to control and listen to e-mail over the phone (and also send some basic messages, like "I'll be late")  Increased the database maximum size limit. Database size is now limited to 16TB per database[16]  Increased the maximum number of storage groups and mail databases per server, to 5 each for Standard Edition (from 1 each in Exchange Server 2003 Standard), and to 50 each for Enterprise Edition (from 4 groups and 20 databases in Exchange Server 2003 Enterprise).  You can configure Outlook Anywhere (formerly known as RPC over HTTP) to provide external access to Microsoft Exchange Server 2007 for your clients. If you want Microsoft Office Outlook 2007 user profiles to be automatically configured to connect to Exchange 2007, configure the Autodiscover service. This also provides external URLs for Exchange services such as the Availability service and offline address book.

Exchange Server 2010

Microsoft Exchange 2010 Screenshot

Developer(s) Microsoft

Operating system Microsoft Windows

Type Server Client

License Proprietary EULA

Website [1]

Microsoft announced the Exchange 2010 to be available from the second period of 2009, and it was released to manufacturing (RTM'ed) on October 9, 2009. Exchange Server 2010 was officially launched on November 9, 2009 [17]; a month after hitting RTM. A 120 day trial is also downloadable from Microsoft at Microsoft.

Preliminary changes include: Storage Groups are being eliminated and incorporated into the Information Store. Clustering is now at the Database level, not Server level. LCR and SCC clustering no longer offered. CCR now at Datastore level, not Server Level although the terminology has changed. Clustering functionality is now known as DAG (Database Availability Group). Exchange 2010 is also only available in 64-bit as part of Microsoft's drive for all its future products to be solely 64-bit based. Exchange 2010 will run on Windows Server 2008 x64 with SP2 at least and Windows Server 2008 R2 (also only released in a 64-bit edition).[18] Clustering and high availability

Exchange Server Enterprise Edition supports clustering of up to 4 nodes when using Windows 2000 Server, and up to 8 nodes with Windows Server 2003. Exchange Server 2003 also introduced active-active clustering, but for two-node clusters only. In this setup, both servers in the cluster are allowed to be active simultaneously. This is opposed to Exchange's more common active-passive mode in which the failover servers in any cluster node cannot be used at all while their corresponding home servers are active. They must wait, inactive, for the home servers in the node to fail. Subsequent performance issues with active-active mode have led Microsoft to recommend that it should no longer be used.[19] In fact, support for active-active mode clustering has been discontinued with Exchange Server 2007.

Exchange's clustering (active-active or active-passive mode) has been criticized because of its requirement for servers in the cluster nodes to share the same physical data. The clustering in Exchange Server provides redundancy for Exchange Server as an application, but not for Exchange data.[20] In this scenario, the data can be regarded as a single point of failure, despite Microsoft's description of this set up as a "Shared Nothing" model.[21] This void has however been filled by ISV's and storage manufacturers, through "site resilience" solutions, such as geoclustering and asynchronous data replication.[22] Exchange Server 2007 introduces new cluster terminology and configurations that address the shortcomings of the previous "shared data model".[23]

Exchange Server 2007 provides built-in support for asynchronous replication modeled on SQL Server's "Log shipping"[24] in CCR (Cluster Continuous Replication)[25] clusters, which are built on MSCS MNS (Microsoft Cluster Service—Majority Node Set) clusters, which do not require shared storage. This type of cluster can be inexpensive and deployed in one, or "stretched" across two datacenters for protection against site-wide failures such as natural disasters. The limitation of CCR clusters is the ability to have only two nodes and the third node known as "voter node" or file share witness[26] that prevents "split brain"[26] scenarios, generally hosted as a file share on a Hub Transport Server.[27] The second type of cluster is the traditional clustering that was available in previous versions, and is now being referred to as SCC (Single Copy Cluster). In Exchange Server 2007 deployment of both CCR and SCC clusters has been simplified and improved; the entire cluster install process takes place during Exchange Server installation. LCR or Local Continuous Replication[27] has been referred to as the "poor man's cluster". It is designed to allow for data replication to an alternative drive attached to the same system and is intended to provide protection against local storage failures. It does not protect against the case where the server itself fails.

In November 2007, Microsoft released SP1 for Exchange Server 2007. This service pack includes an additional high-availability feature called SCR (Standby Continuous Replication). Unlike CCR which requires that both servers belong to a Windows cluster, typically residing in the same datacenter, SCR can replicate data to a non-clustered server, located in a separate datacenter. Licensing

Like Windows Server products, Exchange Server requires Client Access Licenses, which are different from Windows CALs. Corporate license agreements, such as the Enterprise Agreement, or EA, include Exchange Server CALs. It also comes as part of the Core CAL. Just like Windows Server and other server products from Microsoft, you can choose to use User or Device CALs. Device CALs are assigned to a device (workstation, laptop or PDA). User CALs, are assigned to a user or employee (not a mailbox). User CALs allow a user to access Exchange e-mail from any device. User and Device CALs are the same price, however cannot be used interchangeably. For Service Providers looking to host Microsoft Exchange, there is an SPLA (Service Provider License Agreement) available whereby Microsoft receives a monthly service fee in the place of the traditional Client Access Licenses. Two types of Exchange CAL are available: Exchange CAL Standard and Exchange CAL Enterprise. The Enterprise CAL is an add-on licence to the Standard CAL. Exchange hosting

Microsoft Exchange Server can also be purchased as a hosted service from a number of providers.[28] Clients

Microsoft Exchange Server uses a proprietary RPC protocol, MAPI/RPC[29], that was designed to be used by the Microsoft Outlook client. Clients capable of using the proprietary features of Exchange Server include Microsoft Outlook and Novell Evolution. Exchange Web Services (EWS), an alternative to the MAPI protocol, is a documented SOAP based protocol introduced with Exchange Server 2007 which significantly reduces synchronization time between the server vs. WebDAV, which is used by Exchange Server 2003. Exchange Web Services is used by the latest version of Microsoft Entourage for Mac. Also, since the release of Mac OS X v10.6 (also known as Mac OS X Snow Leopard), Mac computers running OS X include some support for this technology via Apple's Mail application. Built-in support with Mac OS X 10.6 requires the Exchange organization to be running Exchange Server 2007 SP1/SP2 or Exchange Server 2010.

Mac users wishing to access Exchange e-mail running on Exchange Server 2000 or 2003 must use Microsoft's Entourage client versions X, 2004 or 2008. Alternatively a limited version of Outlook Web Access is available to Mac users using a web browser. Entourage X, 2004 and 2008 do not support synchronizing tasks and notes with Exchange Servers 2000, 2003, 2007 or 2010. However Entourage 2008 "Web Services Edition", which is a free download from Microsoft for users of Office 2008, does support synchronizing tasks and notes with Exchange Server 2007 SP1 roll up 4 or later (including Exchange 2010).

E-mail hosted on an Exchange Server can also be accessed using SMTP, POP3 and IMAP4 protocols, using clients such as Outlook Express, Mozilla Thunderbird, and Lotus Notes. (These protocols must be enabled on the server. Recent versions of Exchange Server turn them off by default.)

Exchange Server mailboxes can also be accessed through a web browser, using Outlook Web Access (OWA). Exchange Server 2003 also featured a version of OWA for mobile devices, called Outlook Mobile Access (OMA).

DavMail Gateway allows any email client to connect to a Microsoft Outlook server with Outlook Web Access (OWA).

GNOME Evolution project can be used to Connect to MS-Exchange (in OWA mode for Exchange 2000/2003, native mode for Exchange 2007) [2]. Evolution is now also available for Windows.[30] [3]

ActiveSync

A component of Microsoft Windows

ActiveSync 4.5 on Windows XP Details

Replaced by Windows Mobile Device Center

Microsoft Exchange Server

Initial release 1.0 / September 10, 1996

Stable release 4.5 / February 13, 2007

License EULA

Website microsoft.com

Support for ActiveSync was added to Microsoft Exchange Server 2003. ActiveSync, in the context of Exchange Server, allows a compliant device such as a Windows Mobile device to sync mail, contacts and other data directly with the server. BlackBerry, Nokia, Apple Inc. and other companies have licensed the software to enable their devices to sync with Exchange Server as well.[31]

Support for Push E-mail was added to Exchange Server 2003 with Service Pack 2. Windows Mobile 5.0 requires the "Messaging and Security Feature Pack (MSFP)", later versions of the mobile operating system have the capability built in[32]. Many other devices now support ActiveSync push e-mail, such as the iPhone [33]. See also

 Messaging API (MAPI)  Extensible Storage Engine  List of collaborative software  List of Microsoft - Nortel (ICA) Products  Microsoft Exchange Client  Microsoft Servers  Comparison of mail servers

Books

 Walther, Henrik. How to Cheat at Configuring Exchange Server 2007. ISBN 1597491373.  Morimoto, Rand; Michael Noel, Chris Amaris, Andrew Abbate, Mark Weinhardt. Exchange Server 2007 Unleashed. ISBN 0672329204.  McBee, Jim; Barry Gerber. Mastering Microsoft Exchange Server 2007. ISBN 0470042893.  Cavalancia, MCSE, MCT, MCNE, MCNI, Nick. Microsoft Exchange Server 2007: A Beginner's Guide. ISBN 9780071486392.  Luckett, Richard; Bharat Suneja, William Lefkovics. Microsoft Exchange Server 2007: The Complete Reference. ISBN 0071490841. External links

 "Microsoft Exchange"  "Exchange Chinese Web Site"  "EHLO - The Exchange Team Blog"  "A brief history of time - Exchange Server way" Written by the Exchange Team  "Microsoft TechNet - Exchange Server Home"  "Exchange Server Supportability Matrix"  "OpenChange: a portable Open Source implementation of Microsoft Exchange Server and Exchange protocols."  "Features no longer supported by Exchange Server 2007"  "Active Directory LDAP Compliance" Microsoft Corporation, December 2, 2003. Retrieved November 2, 2005.  "How to setup Outlook anywhere" Plain and Simple IT  "Evaluation of Microsoft Exchange 2010 Beta at IT Reviews July 27 2009"  "iPhone Exchange Setup Guide + Common Activesync / Exchange myths"  "Evolution connecting to Exchange"  "Evolution Windows NSIS Installer"

Exchange Server

Welcome to the technical library for Microsoft Exchange Server, the messaging platform that provides e-mail, scheduling, and tools for custom collaboration and messaging-service applications. Easily create and manage your business communications both in the office and on the road by using Exchange Server. The technical library is organized in the following sections: Exchange Server Tools Documentation

Enhance your messaging environment by using the many tools available with Microsoft Exchange Server. This tools documentation provides detailed information about tools that can help you plan, install, manage, and troubleshoot Exchange Server.

 Microsoft Exchange Server Analyzer Articles  Exchange Remote Connectivity Analyzer Tool  Auto Accept Agent Deployment and Administration Guide  Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide  Microsoft Exchange Server User Monitor  Microsoft Exchange Server Quota Message Service  Deploying Exchange ActiveSync Certificate-Based Authentication  Microsoft Exchange ActiveSync Mobile Administration Web Tool  Microsoft Exchange Server MAPI Editor  Microsoft Exchange Server Stress and Performance Tool  Microsoft Exchange Load Generator  Microsoft Exchange Server Public Folder DAV-based Administration Tool  Microsoft Exchange Server Profile Analyzer  Microsoft Exchange 2007 Anti-Spam Migration  Microsoft Exchange Server Jetstress  Inter-Organization Replication Tool  Application Analysis Envisioning Process  Microsoft Application Analyzer 2006 for Lotus Domino  Exchange Server 2003 Coexistence and Migration for Lotus Domino Mail  Migrating from Lotus Notes to the Microsoft Collaboration Platform  Operations Manager Management Pack for Exchange 2010  Operations Manager Management Pack for Exchange 2010 Guide  Operations Manager Management Pack for Exchange 2007 Exchange Server 2003

Welcome to the Microsoft Exchange Server 2003 Technical Documentation Library, your source for guidelines and information from the Microsoft Exchange Server team, including technical reference material, case studies, security guides, developer resources, and performance tuning recommendations. Updated versions of documents are periodically added to this library, ensuring that you have the most up-to-date Exchange Server 2003 documentation.

The technical documentation for Exchange Server 2003 consists of the following categories:

 Getting Started  Planning and Architecture  Deployment  Operations  Security and Protection  Technical Reference  Development Getting Started

Find overview and set-up information as well as help about Microsoft Exchange Server 2003.

 What Is New in Exchange Server 2003  Online Help for Exchange Server 2003  Online Help for Exchange Server 2003 SP1  Online Help for Exchange Server 2003 SP2  Release Notes for Exchange Server 2003  Release Notes for Exchange Server 2003 SP1  Release Notes for Exchange Server 2003 SP2 What Is New in Exchange Server 2003

These topics provide important information about using Microsoft® Exchange Server 2003. The purpose is to outline the features in Exchange Server 2003 and provide the basic information necessary to begin using these new features. This is not a comprehensive document about Exchange, but a guide for getting started with testing and running Exchange 2003.

These topics supplement the release notes (releasenotes.htm), and should be read only after reviewing the release notes. The release notes contain critical information about known issues with Exchange 2003.

These topics are designed to benefit Exchange administrators who will be testing and deploying Exchange 2003. Furthermore, these topics assume that you have an excellent working knowledge of Exchange 2000 Server. The structure is based on Exchange components; specifically, each section itemizes the new component features and discusses how to begin using them.

Note:

For more information about Exchange Server 2003, see the Microsoft Exchange Server TechCenter.

Note:

Download What's New in Exchange Server 2003 to print or read offline. New in Exchange Server 2003 Service Pack 1

The sections listed in the following topics contain information about the updates made to Exchange Server 2003 in Service Pack 1.

 Administration Features in Exchange Server 2003  The Note in Moving Mailboxes in Exchange System Manager  Performance and Scalability Features of Exchange Server 2003  New in SP1: Improved Support for Multiple Processors  Deployment Features of Exchange Server 2003  New in SP1: Exchange Site Consolidation Tools  New in SP1: Exchange 2003 Migration Wizard  New in SP1: Support for Device Update 4 (DU4)  New in SP1: Security Enhancement for Outlook Web Access New in Exchange Server 2003 Service Pack 2 The sections listed in the following topics contain information about the updates made to Exchange Server 2003 in Service Pack 2.

 Administration Features in Exchange Server 2003  New in SP2: Enabling or Disabling MAPI Access for a Specific User  New in SP2: Enabling Direct Push Technology  New in SP2: Managing Security Settings for Mobile Clients  New in SP2: Remote Wiping of Mobile Devices  New in SP2: Global Address List Search for Mobile Clients  New in SP2: Certificate-Based Authentication and S/MIME on Mobile Devices  New in SP2: Tracking Public Folder Deletions  New in SP2: Manually Stopping and Resuming Replication  New in SP2: Synchronizing the Public Folder Hierarchy  New in SP2: Using the Manage Public Folders Settings Wizard  New in SP2: Moving Public Folder Content to a Different Server  Performance and Scalability Features of Exchange Server 2003  New in SP2: Improved Offline Address Book Performance  Transport and Message Flow Features of Exchange Server 2003  New in SP2: Step 3: Specifying the Servers to Exclude from Connection Filtering  New in SP2: Sender ID Filtering  New in SP2: Intelligent Message Filtering  Updated in SP2: Understanding How Enabled Filters Are Applied  Storage Features of Exchange Server 2003  New in SP2: Database Size Limit Configuration and Management Overview of Exchange Server 2003

Microsoft® Exchange Server 2003 builds on the Microsoft Exchange 2000 Server code base, providing many new features and improvements in areas such as reliability, manageability, and security. Exchange Server 2003 is the first Exchange release designed to work with Microsoft Windows Server™ 2003. Running Exchange 2003 on Windows Server 2003 provides several benefits, such as improved memory allocation, reduced Microsoft Active Directory® directory service replication traffic, and rollback of Active Directory changes. Running Exchange 2003 on Windows Server 2003 also allows you to take advantage of new features, such as the Volume Shadow Copy service and cross-forest Kerberos authentication. Exchange 2003 also runs on Microsoft Windows® 2000 Server Service Pack 3 (SP3) or later. Exchange 2003 works with Microsoft Office Outlook® 2003 to provide a range of improvements, such as cached mode synchronization, client- side performance monitoring, and support for RPC over HTTP (which allows users to connect directly to their Exchange server over the Internet without needing to establish a virtual private network (VPN) tunnel). When combined with Windows Server 2003 and Outlook 2003, Exchange 2003 provides a robust, feature-rich end-to-end messaging system that is both scalable and manageable. Exchange 2003 Test Environments

This section provides information about the test environments that you can use to deploy Exchange 2003. However, be aware that, because this document is designed to help you quickly learn about the new features, it does not provide detailed instructions about how to deploy Exchange 2003 in a production environment. For basic instructions about how to get Exchange 2003 up and running in a test environment, see "Deployment Features of Exchange Server 2003."

Operating Systems

Exchange 2003 runs on Windows Server 2003 and Windows 2000 Server SP3 or later versions. Exchange 2003 has been optimized to run on Windows Server 2003; in fact, several Exchange 2003 features require Windows Server 2003 functionality.

Exchange 2003 is supported in all Active Directory forest environments: native Windows 2000, native Windows Server 2003, or mixed Windows 2000 and Windows Server 2003 forests. When running in an environment that uses Windows 2000 domain controllers and global catalog servers, the domain controllers and global catalog servers that Exchange 2003 uses must all be running Windows 2000 SP3 or later versions. This requirement affects both Exchange 2003 servers and the Exchange 2003 version of Active Directory Connector (ADC). ADC does not work with domain controllers or global catalog servers that are running a version of Windows 2000 earlier than SP3.

Note:

Although Exchange 2000 SP2 and later versions is supported in an environment by using Windows Server 2003 domain controllers and global catalog servers, Exchange 2003 is the first version of Exchange that is supported when running on Windows Server 2003. Exchange 2000 is not supported on Windows Server 2003. Information about 32-bit Operating Systems Support

Exchange Server 2003 is supported on 32-bit operating systems and hardware. You can run Exchange Server 2003 on 32-bit operating systems on x64-bit-based hardware. However, Exchange Server 2003 is not supported on 64-bit operating systems, 64-bit Itanium hardware, or 32-bit emulators that are running on 64-bit operating systems. x64 refers to 64-bit processors that are backward compatible with 32-bit applications (typically known as x64 or AMD64/EM64T). For Intel, this is the 64-bit Xeon processor or Pentium processors with EM64T (not the Itanium or IA-64). For AMD, this includes all the AMD64 processors (Operton, Athlon, and Turion). For more information, visit the following Web site at http://www.intel.com/business/technologies/.

Note:

The third-party Web site information in this topic is provided to help you find the technical information that you need. The URLs are subject to change without notice. Coexistence and Upgrade from Previous Versions

Exchange 2003 can coexist with Exchange 2000 and, when running in Exchange mixed mode, with Microsoft Exchange Server 5.5 servers.

For Exchange 2000, Exchange 2003 supports in-place upgrades.

In-place upgrades are not supported for Exchange 5.5 servers. To upgrade from Exchange 5.5 to Exchange 2003, you must join an Exchange 2003 server to the Exchange 5.5 site, and then move Exchange resources, such as mailboxes, to the Exchange 2003 server. Use the Exchange Server Deployment Tools to migrate from Exchange 5.5 to Exchange 2003. For information about the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" in Deployment Features of Exchange Server 2003.

Although Exchange 2000 did support in-place upgrades from Exchange 5.5, the "move-resources" scenario is the recommended Exchange 5.5 to Exchange 2000 upgrade path.

What Features Have Been Removed

Although the bulk of these topics discuss what is new in Exchange 2003, there are several Exchange 2000 features that have either been discontinued or moved to other product lines. The following features have been removed:

 Connectors for Lotus cc:Mail and MS Mail  Real-time Collaboration Features  M: Drive  Key Management Service Connectors for Lotus cc:Mail and MS Mail

The Connector for Lotus cc:Mail and Connector for MS Mail components are not supplied with Exchange 2003. Using Exchange 2003 System Manager to manage MS Mail or cc:Mail connectors on Exchange 2000 servers is not supported. If you need to manage these connectors, use the Exchange 2000 SP3 or later version of System Manager.

If you want to upgrade an existing Exchange 2000 server to Exchange 2003 and either of these connectors is installed, you must use the Exchange 2000 Setup program to remove the connector before upgrading. If you want to retain these services in your organization, you should not upgrade the Exchange 2000 servers that are running these components. Instead, you should install Exchange 2003 on other servers in your organization.

Real-Time Collaboration Features

Exchange 2000 supports many real-time collaboration features such as chat, Instant Messaging, conferencing (using Microsoft Exchange Conferencing Server), and multimedia messaging (also known as unified messaging). These features have been removed from Exchange 2003. A dedicated real-time communications and collaboration server, Live Communications Server, will provide these real-time collaboration features. As with the cc:Mail and MS Mail connectors, you cannot upgrade a server that has Exchange 2000 real-time collaboration features installed. You must remove these components before upgrading.

M: Drive

The Exchange store (which uses the \\.\BackOfficeStorage\ namespace) has traditionally been mapped to the M: drive on an Exchange server. M: drive mapping provided file system access to the Exchange store. The M: drive is disabled, by default, in Exchange 2003. You can still use the file system to interact with the Exchange store, but you must enter the path directly using the \\.\BackOfficeStorage\ namespace. For example, to view the contents of the mailbox store on an Exchange server in the mail.adatum.com domain, you would type the following at a command prompt:

Copy Code dir \\.\BackOfficeStorage\mail.adatum.com\mbx

The reason for removing the M: drive mapping is because, in some cases, the mailbox store would become corrupted from file system operations, such as running a file-level virus scanner on the M: drive or running file backup software on the drive. For Exchange 2000, you should consider disabling the M: drive-mapping feature. For information about how to disable this feature, see Microsoft Knowledge Base article 305145, "HOW TO: Remove the IFS Mapping for Drive M in Exchange 2000 Server."

Key Management Service

Exchange 2000 includes Key Management Service, which works with Windows 2000 Certificate Services to create a public key infrastructure (PKI) for performing secure messaging. With PKI in place, users can send signed and encrypted messages to each other. Exchange 2000 Key Management Service provides a mechanism for enrolling users in Advanced Security, and manages key archival and recovery functions.

Exchange 2003 no longer includes Key Management Service. Exchange 2003 supports standard X.509v3 certificate implementation, and works with PKI solutions that support X.509v3 certificates. For example, you can use the PKI included with Windows Server 2003 in place of Key Management Service. Specifically, Windows Server 2003 PKI includes the ability to manage the key archival and recovery tasks that are performed by Key Management Service in Exchange 2000.

Administration Features in Exchange Server 2003

Microsoft® Exchange Server 2003 includes several new features that make Exchange administration easier and more efficient. From new recipient management features to an improved Queue Viewer, Exchange 2003 offers significant improvements over earlier versions of Exchange.

The following table lists the Exchange 2003 feature enhancements discussed in the following topics.

Exchange 2003 administration - feature enhancements

Feature Description

Recipient  Two new mail-enabled objects in recipient management—InetOrgPerson and Query-based Distribution management groups.

 Exchange Features tab of the user Properties includes Wireless Services and Protocols features.

 You can now run multiple instances of the Exchange Task Wizard simultaneously in a single console.

 You can use the Exchange Task Wizard in Exchange System Manager to move mailboxes.

 New in SP2: A feature has been added that allows you to disable and enable MAPI access for individual users.

Mobile client  New in SP2: Support added for mobile client synchronization by using direct push technology. When direct management push is enabled, new e-mail items are automatically pushed from the server to the mobile device without requiring SMS notification messages.

 New in SP2: Features have been added to allow administrators to manage security-related policy settings for mobile clients.

 New in SP2: A feature has been added to allow administrators to provision a mobile device and to wipe a mobile device remotely.

 New in SP2: Mobile device users can now view contact properties for individuals in the global address list (GAL).

 New in SP2: Support has been added for certificate-based authentication and S/MIME.

Queue Viewer  Improved Queue Viewer functionality provides visibility to more message queues.

 You can view both SMTP and X.400 queues from Queue Viewer instead of from their separate nodes.

 You can disable outbound mail from all SMTP queues.

 You can set the refresh rate for queues.

 Improved Find Messages option to search for messages within a queue.

 You can use the Additional queue information pane to view additional information about a particular queue.

 Hidden queues exposed, such as Failed message retry queue and display in Queue Viewer. Public Folders  New and improved public folder administration interface such as the Status tab and the Replication tab. Improved search capability to search all public folders.

 You can create a list of specific servers among which public folder referrals are allowed.

 Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new Microsoft Windows script file (.wfs) that allows you to create replicas of your system folders and public folders on the new Exchange 2003 server.

 New in SP2: You can now track the deletion of public folders.

 New in SP2: You can now manually stop and resume public folder replication.

 New in SP2: You can now use the Manage Public Folders Settings Wizard to modify client permissions, modify lists of replica servers, and overwrite public folder settings.

 New in SP2: You can now more easily move all public folder content from a public store to a different server.

Mailbox Recovery  Using the new Mailbox Recovery Center, you can perform recovery or export operations on multiple Center disconnected mailboxes at one time.

Message Tracking  You have greater control in Exchange System Manager over your message tracking log files. Center  You can now track messages after categorization.

Exchdump.exe  Exchdump.exe is a command line utility that collects and reports Exchange configuration information from utility various sources such as Microsoft Active Directory® directory service, the registry, and so on.

New Mail-Enabled Objects for Managing Recipients

Recipients are Active Directory objects. Users can either be mailbox-enabled or mail-enabled. Contacts, groups, and public folders can only be mail-enabled. These designations determine what tasks users can perform in Exchange. Exchange 2003 introduces two new recipient objects— InetOrgPerson and Query-based Distribution Group.

InetOrgPerson

The InetOrgPerson object is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization. Support for InetOrgPerson in Exchange 2003 makes migrations from other LDAP directories to Active Directory more efficient. InetOrgPerson objects in Active Directory can be either mailbox-enabled or mail-enabled. For detailed instructions, see How to Create an InetOrgPerson.

The InetOrgPerson object in Active Directory is derived from the user class; it functions like a user object and conforms to the LDAP standard. Furthermore, InetOrgPerson can be used as a security principal, just like the user class. Active Directory now includes InetOrgPerson in queries for users. Active Directory provides support for the InetOrgPerson object class, as well as its associated attributes, which are defined in RFC 2798. For more information about RFC 2798, see http://www.ietf.org/.

Note:

You can create an InetOrgPerson only if you are running a Microsoft Windows Server™ 2003 domain controller. InetOrgPerson can be mail- enabled or mailbox-enabled only in a native Exchange 2003 topology. Query-Based Distribution Groups

A query-based distribution group is a new type of distribution group introduced in Exchange 2003. This section explains what a query based distribution group is, how these groups work, and how to create them.

What Is a Query-Based Distribution Group?

A query-based distribution group provides the same functionality as a standard distribution group; however, instead of specifying static user memberships, a query-based distribution group allows you to use an LDAP query to dynamically build membership in the distribution group (for example "All full-time employees in my company"). Using query-based distribution groups allows for a much lower administrative cost, given the dynamic nature of the distribution group. However, query-based distribution groups require higher performance cost for queries that produce a large number of results. This cost is equated with server resources (such as high CPU and increased working set) because every time an e-mail message is sent to a query-based distribution group, an LDAP query is executed against Active Directory to determine its membership.

Important:

You cannot view the membership of a query-based distribution group in the global address list, because membership is dynamically generated each time mail is sent. How Does a Query-Based Distribution Group Work? When a message is submitted to a query-based distribution group, Exchange handles the message in a slightly different manner than messages that are destined for other recipients. A query-based distribution group flows through Exchange to the proper recipients in the following manner:

1. An e-mail message is submitted to the submission queue through the Exchange store driver or through SMTP. 2. The categorizer, a transport component responsible for address resolution, determines that the recipient is a query-based distribution group. 3. The categorizer sends the LDAP query request to the global catalog server. 4. The global catalog server executes the query and returns the set of addresses that match the query. 5. After receiving the complete set of addresses matching the query, the categorizer generates a recipient list containing all the users.

Note:

The categorizer must have the complete set of recipients before it can submit the message to routing; therefore if an error occurs during the expansion of the query-based distribution group to its individual recipients, the categorizer must restart the process.

6. After the categorizer sends the complete, expanded list of recipients to routing, the standard message delivery process continues, and the e-mail message is delivered to the users' mailboxes.

If a dedicated expansion server (a single server responsible only for expanding distribution groups) is used for query-based distribution groups, the process is slightly different. In this case, rather than sending a query to the global catalog server for expansion (as in Step 4), the message is first routed to the dedicated expansion server. After the message arrives at the expansion server, the expansion takes place, and the delivery follows the same process described above.

Creating Query-Based Distribution Groups

Query-based distribution works reliably in a pure Exchange 2003 deployment or in a native Exchange 2000 and Exchange 2003 deployment in which all Exchange 2000 servers are running Service Pack 3 (SP3) with Windows Server 2003 global catalog servers. If your global catalog servers are running Windows® 2000 Server, you can modify a registry key on your Exchange 2000 SP3 servers to achieve greater reliability. You do not need to add this registry key to your Exchange 2003 servers, because, by default, Exchange 2003 expands query-based distribution groups reliably with Windows 2000 and Windows Server 2003 global catalog servers. If you are running versions of Exchange earlier than Exchange 2000 SP3 in your organization, query-based distribution groups will not work reliably.

Modifying Exchange 2000 SP3 Servers for Use with Windows 2000 Global Catalog Servers

Use the following procedure to configure an Exchange 2000 SP3 server for improved reliability in organizations where query-based distribution groups will be expanded with Windows 2000 global catalogs. For detailed instructions, see "How to modify your Exchange 2000 SP3 Servers for Use with Windows 2000 Global Catalog Servers" in the Exchange Server 2003 Administration Guide.

Note:

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. Creating a Query-Based Distribution Group

To create a query-based distribution group, you must use the Exchange 2003 version of Exchange System Manager and Active Directory Users and Computers. You cannot create query-based distribution groups without upgrading your administration console. For detailed instructions on creating a query-based distribution group, see "How to Create a Query-Based Distribution Group" in the Exchange Server 2003 Administration Guide.

Note:

It is recommended that you upgrade all your administrative consoles to Exchange 2003 before deploying query-based distribution groups in your environment.

Active Directory Users and Computers provides an easy way to format the LDAP query with standard attributes, without requiring specific knowledge of LDAP. For example, you can select all mailboxes under the organizational unit or even customize the query to select all mailboxes under the organizational unit that exist on a particular server.

Additionally, after you construct a query, the Preview tab in the query's Properties provides the information necessary to ensure that your query functions properly. As mentioned earlier, you can ensure that all attributes selected for the query are available on the global catalog server. You can also use the Preview tab to learn how long a query takes to execute and, based on this time, you can break up the query into smaller queries for better performance and faster delivery times.

Guidelines for Creating Query-Based Distribution Groups

Use the following guidelines when creating query-based distribution groups:  You can only use query-based distribution groups in a pure Exchange 2003 environment or in a native mode environment with Exchange 2000 and Exchange 2003, where all Exchange 2000 servers are running Service Pack 3.  When creating distribution groups that span domains, use universal groups in multi-domain environments. Although you can add query-based distribution groups to global distribution groups, domain local and global security groups and can contain any of these groups; membership in these types of groups is not replicated to global catalog servers in other domains. Use universal distribution groups in situations where distribution spans a multi-domain environment.  When combining query-based distribution groups into an aggregate group, combine them in a universal group. Only universal groups are available on global catalog servers across domains.  When building query-based distribution groups, you should only include universal groups if you want the membership to be available in all domains in a multi-domain environment.  Index the attributes used in the query. Indexing greatly improves the performance of the query and reduces the time required to expand the distribution group and deliver the e-mail message to the intended recipients.  If the filter string contains bad formatting or incorrect LDAP syntax, then the global catalog server will not execute the query. Use Active Directory Users and Computers to create your query, which can help prevent you from constructing an incorrect query. You can also use the Preview tab in the query's Properties to view the result of the query; this will confirm the validity and desired results of the query. If you create a query-based distribution group based on an incorrect LDAP query, a user who sends a message to the query-based distribution group will receive a non-delivery report (NDR) with the code 5.2.4; furthermore, if categorizer logging is enabled, one of two events are logged with event identifiers of 6024 or 6025.  Always use the Preview tab to ensure that the attributes you include in your query are available on the global catalog server.  If the filter string is well formatted but no results are produced, then the sender will not receive an NDR. This is the same behavior that results when a message is sent to an empty distribution group. As mentioned earlier, use the Preview tab in Active Directory Users and Computer to confirm the result of your query.  Use Exchange System Manager in a security context that has the same permissions for reading objects in Active Directory as the Exchange server. It is important to note that Exchange System Manager runs in the security context of the user who is currently logged in. If an administrator is running Exchange System Manager and has lower security privileges than the Exchange server, it is possible that the query will show a subset of the actual results on the Preview tab. The preview pane only shows the Active Directory objects that the administrator has permission to read. When a message is sent to the query-based distribution group, however, the categorizer runs with the Exchange server permissions. Assuming that the Exchange server has permissions for all the objects in the query, the query returns the correct results.  Issues arise when a base distinguished name is deleted. Query-based distribution expansion relies on its base distinguished name referring to a valid container in the directory. If a query-based distribution group's base distinguished name container is deleted, the categorizer cannot execute the query, and the sender receives an NDR with the code 5.2.4. If categorizer logging is enabled, an event ID of 6024 or 6025 is logged. For example, suppose you created a Sales container within the Users container for all Sales employees and then used the Sales container to build a query-based distribution group. If you deleted the Sales container, the query would no longer work.

Combining Multiple Query-Based Distribution Groups

In Exchange System Manager, you can create query-based distribution groups based on the AND operator. This means you can create a query using two attribute values; the query includes results that meet both of the specified conditions. For example, if you create a query that includes users on mailbox store 1 and users located in Seattle, the results include only users who are on mailbox store 1 and also located in Seattle. To create distribution groups based on the OR operator using query-based distribution groups, create multiple query-based distribution groups and combine them in a single distribution group. For example, if you want to include users who are on mailbox store 1 or located in Seattle, you would need to create on query-based distribution group for users in Seattle and a second query-based distribution group for users residing on mailbox store 1. Then you would create a standard distribution group and include these two query-based distribution groups as members.

Note:

The distribution group you use to combine the query-based distribution groups cannot itself be a query-based distribution group.

For example, assume you want to create a query-based distribution group that includes all Marketing employees or all employees located in the Paris office. If you create a query-based distribution group with an LDAP query that contains all Marketing employees and all Paris employees, the query only returns users who are in both groups—any user who is not a member of both groups is excluded. To achieve OR functionality (thereby including members of either group), you must create two query-based distribution groups, one for Marketing employees and one for Paris employees; then you must combine the two groups to create a new distribution group (not a query-based distribution group) that contains the two groups as members. To do this, you would perform the following steps:

1. Create a query-based distribution group called Marketing for all Marketing employees. 2. Create a query-based distribution group called Paris employees for all employees in the Paris office. 3. Create a distribution group and add the query-based distribution groups—Marketing and Paris employees—as members of this group.

Important:

You cannot add query-based distribution groups as members of a distribution group the same way you add users to a group. You must right-click the distribution group, and then click Add Exchange Query-based Distribution Groups.

For detailed instructions about adding query-based distribution groups as members of a standard distribution group, see "How to add query- based distribution groups as members of a distribution group" in the Exchange Server 2003 Administration Guide.

Deployment Recommendations for Query-Based Distribution Groups

The following factors influence the amount of time it takes to expand and execute a query-based distribution group:

 Hardware The categorizer can require up to 2 KB of memory for each recipient. Use this conservative metric as a baseline. Using this baseline, if you send an e-mail message to a query-based distribution group of 6,000 users (meaning that the query returns 6,000 records), the categorizer requires 12 MB of RAM just to expand the query-based distribution group. Similarly, if you send an e-mail message to a larger query-based distribution group of 100,000 users, the categorizer requires approximately 200 MB of RAM. The processor speed and amount of available physical memory affects the time it takes to deliver the messages after the expansion.  Global catalog availability If you send a message to a query-based distribution group and all global catalog servers are unavailable, the message is placed in retry mode in the categorizer. This means that the complete expansion will restart after one hour. The general recommendation is to separate large query-based distribution groups into combinations of standard distribution groups, and then assign different expansion servers for each large distribution group. When expanding distribution groups, consider one of the following three options for designating and configuring expansion servers and global catalog servers: Option 1 Designate an Exchange 2003 server with no mailboxes, such as a public folder replica server or a bridgehead server, as the expansion server for a large query-based distribution group. Because this server has more bandwidth and resources to expand the query-based distribution group, expansion and delivery are more efficient. Option 2 Create a query-based distribution group for every Exchange server and limit each query-based distribution group to the mailboxes on that server. Assigning this same server as the expansion server optimizes mail delivery. Then, use aggregate standard distribution groups that contain these query-based distribution groups as members. For example, if you wanted to create a query-based distribution group for all full-time employees, you could create a query-based distribution group on each server for full-time employees, name them Server1 Full Time and Server2 Full Time, and then create a standard distribution group called AllFullTime that is comprised of the two server-based groups.

Note:

The distribution group you use to combine the query-based distribution groups cannot itself be a query-based distribution group.

 Option 3 Instead of using a single large query-based distribution group, create smaller query-based distribution groups and combine them in a standard distribution group. Suppose you want to create a query-based distribution group called All employees with one hundred thousand users. Divide the group into the following smaller query-based distribution groups, and then combine these groups into a single standard distribution group:  All Temps, 10,000 users  All Vendors, 5,000 users  All Full-Time, 65,000 users  All Interns, 2,000 users  All Contractors, 18,000 users

In this scenario All Full-Time is a large distribution group, so you may want to assign a specific expansion server to it. The other query-based distribution groups can be assigned an expansion server, based on how the users are distributed across your Exchange servers. For example, if all the interns reside on one Exchange server, you may want to have the same server as expansion server for All Interns. Overall, this approach performs much better than a single query-based distribution group with 100,000 recipients. Improved Ability to Restrict Submissions to Users and Distribution Lists (Restricted Distribution Lists)

In Exchange 2003, you can restrict who can send e-mail messages to an individual user or a distribution list. Submissions can be restricted to a limited number of security principles though the standard Windows discretionary access control list (DACL). Restricting submissions on a distribution list prevents non-trusted senders, such as unauthorized Internet users, from sending mail to an internal-only distribution list. For example, an All Employees distribution list should not be available to anyone outside the company (by spoofing or otherwise).

Note:

Restricted distribution lists and submission restrictions for users only function on the bridgehead servers or SMTP gateway servers running Exchange Server 2003.

For detailed instructions about setting submission restrictions on users, see "How to set restrictions on a user" in the Exchange Server 2003 Transport and Routing Guide. For detailed instructions about setting submission restrictions on distribution lists, see " How to set restrictions on a distribution group" in the Exchange Server 2003 Transport and Routing Guide.

Enhanced Exchange Features on User Properties

The Exchange Features tab in the user Properties now includes the Mobile Services and Protocols features. These Exchange features provide added functionality for your mailbox-enabled users. You can enable or disable the user's Mobile Services options (such as Microsoft Outlook® Mobile Access), or Protocols (such as Outlook Web Access). For detailed steps, see the following procedures:

 How to Enable or Disable Exchange Features for a Single User  How to Enable or Disable Exchange Features for Multiple Users Moving Mailboxes in Exchange System Manager

Exchange Task Wizard provides an improved method for moving mailboxes. You can now select as many mailboxes as you want and then, using the task scheduler, schedule the move to occur at some point in the future. You can also use the scheduler to cancel any unfinished moves at a selected time. For example, you can schedule a large move to start at midnight on Friday and automatically terminate at 6:00 A.M. on Monday, thereby ensuring that your server's resources are not being tapped during regular business hours. Using the wizard's multithreaded capabilities, you can move up to four mailboxes simultaneously.

Note:

New in SP1: With SP1, you can now move mailboxes across administrative groups while in mixed mode. Mailboxes should only be moved across administrative groups in mixed mode in certain scenarios (for example, during site consolidation). For more information, see "Deployment Features of Exchange Server 2003."

For detailed instructions on how to move mailboxes from Exchange System Manager, see "How to move mailboxes from one Exchange Virtual Server to another server" in the Exchange Server 2003 Administration Guide. You can also move mailboxes from Active Directory Users and Computers.

New in SP2: Enabling or Disabling MAPI Access for a Specific User

In Exchange Server 2003 SP2, you can disable MAPI access for a given user. You can also grant access to a user who has configured Microsoft Office Outlook to run in cached mode, but deny access otherwise. This functionality is valuable in a variety of scenarios. For example, if you provide hosting services, you can require that your hosted users connect to Exchange Server with Outlook Web Access, but not with Outlook.

The ProtocolSettings attribute on the user object in the Active Directory® directory service stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

MAPI§§§§§§§§

The eight § separators define exactly nine fields. The fields have the following meanings.

MAPI Specifies that this string contains settings that apply to the MAPI protocol.

Bool1 0 to block all MAPI access; 1 to determine MAPI access based on Bool2.

Bool2 0 for noop; 1 to deny access to non-cached mode Outlook clients.

Remaining 6 fields Currently not used.

If ProtocolSettings does not contain a MAPI string, all MAPI clients are allowed. Note:

If the MAPI string does not have the eight separators and conform to the expected data types, the behavior is undefined.

The access restrictions specified above do not apply in the following cases:

 MAPI access restrictions do not affect Exchange Server tasks. For example, user mailboxes can still be moved regardless of the MAPI access settings for the given mailbox.  MAPI access restrictions that have been applied to a specific user do not apply to that user's delegate access to another user's mailbox. New in SP2: Enabling Direct Push Technology

In Exchange Server 2003 SP2, support has been added for mobile client synchronization by using direct push technology. Direct push maintains an open connection between the mobile device and the server. When direct push is enabled, new mail items are automatically pushed from the Exchange server to the mobile device without requiring SMS notification messages.

Note:

To maximize performance, it is recommended that you increase your firewall time-out values when you use the Enable Direct Push over HTTP(s) option. For information about configuring Microsoft Internet Security and Acceleration (ISA) Server 2000 or ISA Server 2004, see the Product Documentation page of the Microsoft Internet Security and Acceleration Server Web site (http://go.microsoft.com/fwlink/?LinkId=48508). Additionally, for information about how to configure this setting in ISA Server 2004, see "To configure maximum number of concurrent connections allowed" in the ISA Server 2004 online Help.

For information about how to enable direct push technology for all your users, see "Enable Exchange ActiveSync for All Users" in the Exchange Server 2003 SP2 online Help.

New in SP2: Managing Security Settings for Mobile Clients

In Exchange Server 2003 SP2, support has been added to allow you to manage security policy settings for mobile clients. Security policy settings allow you to establish and then enforce security policies for your mobile device users.

Note:

The term password as used in this section refers to the password a user enters to unlock their mobile device. It is not the same as a network user password.

You can configure the following options.

 Password requirements You can specify the required length of the user's device password. The default setting is 4 characters. You can specify a password length of 4 to 18 characters. You can also require that users choose a password with both numbers and letters. The setting to require numbers and letters is not selected by default.  Logon requirements after periods of inactivity You can specify if you want your users to log on to their devices after a specified number of minutes of inactivity. This setting is not selected by default. If selected, the default setting is 5 minutes.  Wipe memory of device after a specified number of failed logon attempts You can specify if you want the device memory wiped after multiple failed logon attempts. This setting is not selected by default. If selected, the default setting is 8 attempts.  Interval that mobile device policy settings are sent to a device You can specify how often you want to send a provision request to devices. This setting is not selected by default. If selected, the default setting is every 24 hours.

You have the following options when you determine how to enforce your security policies:

 You can allow only devices that support mobile device security policy features to synchronize their devices. When this setting is selected, only users with devices that are running Windows Mobile 5.0 and the Microsoft Messaging and Security Feature Pack for Windows Mobile 5.0 and later will be able to synchronize their devices.  You can allow mobile devices that do not fully support mobile device security policy features. Specifically, users with devices that are running versions earlier than Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0 will be able to synchronize their devices. However, it is important to note that when you use this option, only users with devices that are running Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0 and later will be subject to mobile device security policy settings.  You can specify specific users who are exempt from device security settings. This option allows you to specify the user names of specific, trusted users of whom you do not need to require device security settings.

Important:

Before you implement the device security settings that are available in Exchange Server 2003 SP2, it is important that you consider that some or most of your mobile device users may not yet be running Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0. To allow mobile device users who are not yet using these products to synchronize their devices, you must select the Allow access to devices that do not fully support password settings option in the Device Security Settings dialog box. After all your clients upgrade to Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0, you can clear this option. When this option is cleared, all mobile device users are subject to mobile device security policy settings. Following this recommendation will allow your mobile device users whose devices are not yet running Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0, to synchronize their devices.

For information about configuring device security settings, see "Configure Security Settings for Mobile Devices" in Exchange Server 2003 SP2 online Help.

New in SP2: Remote Wiping of Mobile Devices

In Exchange Server 2003 SP2, a feature called remote wipe has been added to allow you to remotely erase sensitive data from a mobile device. This feature is useful if you need to remotely erase sensitive data from a lost or stolen mobile device. After you use this command and successfully erase sensitive data from a mobile device, you will receive a message acknowledging that the device has been successfully wiped.

New in SP2: Global Address List Search for Mobile Clients

In Exchange Server 2003 SP2, global address list (GAL) lookup enables mobile device users to receive contact information for users in the global address list on their mobile device. This feature lets a user quickly search for a person, based on name, company, and so on.

New to SP2: Certificate-Based Authentication and S/MIME on Mobile Devices

In Exchange Server 2003 SP2, the following support has been added:

 Support for certificate-based authentication  Use of S/MIME to sign and encrypt mail Enhancements to Queue Viewer

In Exchange 2003, Queue Viewer is enhanced to improve the monitoring of message queues. For example, you can now view X.400 and STMP queues in Queue Viewer, rather than from their respective protocol nodes. Other enhancements include:

 Disabling outbound mail Queue Viewer includes a new option called Disable Outbound Mail, which allows you to disable outbound mail from all SMTP queues. For detailed instructions, see How to Disable Outbound Mail for All SMTP Queues.  Setting the refresh rate You can use the Settings option to set the refresh rate of the queues. For detailed instructions, see How to Modify Queue Viewer Refresh Rate Settings.  Finding messages You can search for messages based on the sender, recipient, and message state using Find Messages. For detailed instructions, see How to Find Messages.  Viewing additional information You can click a specific queue to view additional information about that queue. For detailed instructions, see How to View Additional Information About a Queue.  Viewing previously hidden queues Queue Viewer in Exchange 2003 exposes three queues that were not visible in Exchange 2000: DSN messages pending submission, Failed message retry queue, and Messages queued for deferred delivery.

The following figure illustrates the new and improved Queue Viewer.

Queue Viewer

Viewing Previously Hidden Queues

Several queues that were hidden in Exchange 2000 are now visible in Exchange System Manager.

Note:

The X.400 queues and the SMTP queues now appear in Queue Viewer rather than under their respective protocol nodes.

The following table lists the new queues, their descriptions, and possible reasons for message accumulation in each queue.

New queues in Exchange 2003

Queue Name Description Causes for Message Accumulation

DSN messages Contains delivery status notifications (DSN), also Messages can accumulate in this queue if the Microsoft pending known as non-delivery reports, that are ready to be Exchange Information Store service is unavailable or not submission delivered by Exchange. running, or if problems exist with IMAIL Exchange store Note The following operations are unavailable for component, which is the component that performs message this queue: conversion. Check the event log for possible errors with the Microsoft Exchange Information Store service.  Delete All Messages (no NDR)

 Delete All Messages (NDR)

Failed message Contains messages that failed some sort of queue Possible causes for failed messages are: retry queue submission, often before any other processing has taken place. By default, messages in this queue are reprocessed in 60 minutes.  Corrupted messages.  Third-party programs or event sinks may be interfering with message queuing or fidelity.

 Low system resources causing the system to respond slowly or indicates performances issues. Restarting IIS temporarily may temporarily improve resource issues, but the root cause should be determined. Messages Contains messages that are queued for delivery at a Possible causes for message accumulation are: queued for later time, including messages that were sent by older deferred versions of Microsoft Office Outlook. (You can set this delivery option on Outlook client computers.)  If a message is sent to a user's mailbox while the Previous versions of Outlook depend on the message mailbox is being moved, messages can be queued here. transfer agent (MTA) for message delivery. Now, SMTP, not the MTA, handles message delivery.  When the user does not yet have a mailbox and no Therefore, messages sent by older versions of Outlook master account Security ID (SID) exists for the user. For treat deferred delivery differently. These messages remain in this queue until their more information, see Microsoft Knowledge Base article scheduled delivery time. 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts."

 The message may be corrupted or the recipient may not be valid.

 To determine if a message is corrupted, check its properties. If some messages are not accessible, this can indicate a corrupted message. You can also check that the recipient is valid.

Improved Public Folder Referral

In Exchange 2000 Server, you could specify whether or not to allow public folder referrals among routing groups. Exchange 2003 provides a richer interface, which you can use to create a list of specific servers among which referrals are allowed.

When a user connects to a public folder store that does not contain a copy of the content the user is looking for, the user is redirected to another store that has a copy of the content. You can use public folder referrals to control this redirect traffic (this is similar to public folder affinity in Exchange 5.5).

Using the default configuration, Exchange attempts to redirect the user to a server within the local routing group. If none of those servers has the required content, Exchange follows the organization's routing group structure to search for an appropriate server.

In Exchange Server 2003, you can create a list of specific servers among which referrals are allowed. For example, you can limit referrals to a single routing group, or only allow referrals between certain servers in each routing group. For detailed instructions on creating a custom list of referrals, see "How to Specify a Custom List for Public Folder Referrals" in the Exchange Server 2003 Administration Guide.

You can also assign "costs" to prioritize the servers in your referral list. Use costs to prioritize servers in the referral list. Higher-cost servers are used only if lower-cost servers are not available. For detailed instructions on assigning "costs" to prioritize the servers in your referral list, see "How to Assign Costs on the Public Folder Referrals List" in the Exchange Server 2003 Administration Guide.

Improved Public Folder Interfaces

To make public folders easier to manage, Exchange 2003 includes several new public folder interfaces. To view these new interfaces, in Exchange System Manager, expand Folders and then select a public folder (or in some cases, a public folder hierarchy). The following new tabs are displayed in the details pane.

 Content tab Use this tab to view the contents of a public folder in Exchange System Manager. You no longer have to open a separate client application to view public folder content. For detailed instructions, see How to View the Content of a Public Folder Using Exchange System Manager.  Find tab Use this tab to search for public folders within the selected public folder or public folder hierarchy. You can specify a variety of search criteria, such as the folder name or age. For detailed instructions, see How to Search for a Public Folder.

Note:

The Find tab is available at the top-level hierarchy level as well as the folder level.

 Status tab Use this tab to view the status of a public folder, including information about servers that have a replica of the folder and the number of items in the folder. For detailed instructions, see "How to Check Public Folder Replication Status" in Working with the Exchange Server 2003 Store.  Replication tab Use this tab to view replication information about the folder. For detailed instructions, see "How to Configure Public Folder Replicas" in Working with the Exchange Server 2003 Store. New tabs available for viewing public folder information

Manually Starting Replication

If you want to ensure that public folders replicate without waiting for the normal replication interval, you can start replication manually. Using the Send Contents or Send Hierarchy commands on a public folder, you can replicate changes from one specified server to another. The range of changes to replicate starts the specified number of days in the past and ends at the last replication cycle. For example, you can replicate all changes made over the past two days except for any changes made since the last replication cycle.

For detailed instructions on manually replicating public folder content, see "How to Replicate Public Folder Data Manually" in Working with the Exchange Server 2003 Store.

Microsoft Exchange Public Folder Migration Tool

Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new Windows Installation script (.wfs) that allows you to create replicas of your system folders and public folders on new Exchange 2003 servers. After the system folders and public folders have replicated, you can use the pfMigrate tool to remove replicas from the source server. Unlike Microsoft Exchange Server version 5.5, you do not need to set a home server for a public folder in Exchange 2003. Any replica acts as the primary replica of the data it holds, and any public folder server can be removed from the replica list. To determine how many folders must be replicated, you can use the pfMigrate tool to generate a report before you replicate folders. To determine whether the folders replicated successfully, you can generate the same report after you replicate folders.

To use the pfMigrate tool, the source server and the target server you specify must be in the same routing group. The pfMigrate tool does not allow you to create replicas of your system folders and public folders across routing groups. This is because, in mixed mode, moving folders across routing groups could prevent e-mail delivery to public folders.

The pfMigrate tool is located in the ExDeploy folder on the Exchange 2003 compact disc (under Support Tools). You can run the tool at the command prompt, either on a server or from the administrative console. For detailed instructions on running the pfMigrate tool, see "How to Run the Public Folder Migration (PFMigrate) Tool" in the Exchange Server 2003 Deployment Guide.

New in SP2: Tracking Public Folder Deletions

In Exchange Server 2003 SP2, you can use diagnostic logging to record events that indicate details associated with the deletion of public folders. The information provided in these events can help you follow up with users or administrators who may be deleting public folders and public folder content that should not be deleted. The logged event includes following information:

 The name of the public folder that was deleted  The time the public folder was deleted  The name of the mailbox and Windows user account that deleted the mailbox

By default, events indicating details of public folder deletion are not logged. However, if you set the appropriate logging category to Medium or Maximum, the following event is logged when a public folder is deleted:

 Event Type: Information  Event Source: MSExchangeIS Public Folder  Event Category: General  Event ID: 9682  Description: Folder with Folder ID was deleted by , .

Note:

When you log public folder deletions, you do not need to set the logging level to Maximum because this setting does not provide additional information. Setting the logging level to Maximum creates a large amount of logging data, which can negatively affect server performance.

For information about how to configure Exchange Server to track public folder deletions, see "Track Public Folder Deletions" in the Exchange Server 2003 SP2 online Help.

New in SP2: Manually Stopping and Resuming Public Folder Replication

In Exchange Server 2003 SP2, you can use this feature to stop all public folder content replication in an Exchange Server organization. This feature may be helpful if you need to stop a replication storm. A replication storm occurs when a large amount of data is replicated through the network, typically as a consequence of a change that affects many items or folders. The problem is particularly disruptive when the changes triggering the replication storm are unintended and the network topology includes low bandwidth connections.

When content replication is stopped, you can reconfigure public folder replica lists and replication schedules. After you make changes to minimize the affect of public folder replication, you can restart replication of public folder content. Depending on the size of the public folders that need to replicate and your network infrastructure, you may want to resume public folder replication during non-peak hours.

Note:

Stopping the replication of all public folder content does not stop the replication of the public folder hierarchy.

For information about how to manually stop and resume public folder content replication, see "Manually Stop and Resume Public Folder Content Replication" in the Exchange Server 2003 SP2 online Help.

New in SP2: Synchronizing the Public Folder Hierarchy

In Exchange Server 2003 SP2, you can use the Synchronize Hierarchy command to synchronize the public folder hierarchy in the server you are currently connected to with the rest of the servers in your organization. You may want to synchronize the hierarchy if you notice that the public folder hierarchy on one server looks different from the public folder hierarchy on other servers in your organization.

Synchronizing the hierarchies of your public folder tree does not automatically replicate the contents of the public folders. The replication of content occurs at the intervals you have scheduled. However, you can manually force replication of the content. For information about how to send content from one server to another, see "Send Contents of a Public Folder" in the Exchange Server 2003 SP2 online Help.

Note:

Although it is recommended that you use the Synchronize Hierarchy command to synchronize your public folder hierarchy, you can also use the Resend Changes command. Use this command to manually resend the public folders hierarchy replications messages that may not have reached their destination servers. For more information about how to resend public folders hierarchy replication messages to a specific set of servers, see "Resend Hierarchy of the Public Folder Tree" in the Exchange Server 2003 SP2 online Help.

For information about how to synchronize the public folder hierarchy, see "Synchronize the Public Folder Hierarchy" in the Exchange Server 2003 SP2 online Help.

New in SP2: Using the Manage Public Folders Settings Wizard

In Exchange Server 2003 SP2, you can use the Manage Public Folders Settings Wizard to manage public folders. The Manage Public Folders Settings Wizard was developed to help Exchange administrators to manage public folder settings. You can perform the following actions with the wizard:

 Modify client permissions Select this option to make client permissions changes to this folder and all subfolders. For information about adding or removing client permissions for a specific folder only, see "Set Permissions" in the Exchange Server 2003 SP2 online Help.  Modify lists of replica servers Select this option to make changes to the list of replica servers. Specifically, you can use this feature to add, remove, or replace replicas for all folders in a public folder subtree. For information about adding or removing an individual replica for a specific folder only, see "Choose Which Folders to Replicate" in the Exchange Server 2003 SP2 online Help.  Overwrite settings Select this option to use the settings of the folder that you selected to overwrite the settings of all the folders under it.

For information about how to start the Mange Public Folders Settings Wizard, see "Configure Database Size Limits" in the Exchange Server 2003 SP2 online Help.

New in SP2: Moving Public Folder Content to a Different Server

In Exchange Server 2003 SP2, you can use the Move All Replicas command to move all public folder content from a public store to a different server using a single command. This command is helpful if you need to uninstall Exchange Server 2003 from a server; you cannot uninstall Exchange Server 2003 from a server than contains any public folder replicas. For information about how to remove a server running Exchange Server 2003 from your organization, see "Remove a Server" in the Exchange Server 2003 SP2 online Help.

Note:

Moving all replicas to a different server may take time and result in large amounts of replication traffic. It may take several hours or longer until all public folder contents are moved. It is recommended that you verify that the contents of the public folder store have been moved

For information about how to move all public folder content from a public folder store, see "Move All Public Folders from a Public Folder Store" in the Exchange Server 2003 SP2 online Help.

Mailbox Recovery Center

Using the new Mailbox Recovery Center, you can simultaneously perform recovery or export operations on multiple disconnected mailboxes. This is a significant improvement over Exchange 2000 Server, where such operations had to be performed individually on each disconnected mailbox (a disconnected mailbox is a mailbox that is not associated with a user in Active Directory, usually because the user has been deleted). Use Mailbox Recovery Center to recover one or more mailboxes on one or more mailbox stores. You can export the mailbox properties, and you can associate the mailboxes with users in Active Directory and reconnect the mailboxes. For detailed instructions, see "How to Recover One or More Mailboxes on One or More Mailbox Stores" in the Exchange Server 2003 Administration Guide.

Note:

Some procedures are different for Windows 2000 Server and Windows Server 2003.

For detailed instructions, see:

 How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows 2000 Server  How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows Server 2003  How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows 2000 Server  How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows Server 2003

Improved Message Tracking

Exchange 2003 enhances message-tracking capabilities in two ways:

 When using Exchange System Manager, you have greater control over your message tracking log files. Exchange 2003 automatically creates a shared directory to the message tracking logs and allows you to change the location of the message tracking logs.  You can now track messages after categorization (which is the phase where users are located and distribution groups are expanded into individual recipients) and during the routing process. Enhanced Control of Message Tracking Logs in Exchange System Manager

To provide flexibility when viewing and managing message tracking logs, Exchange 2003 allows you to use Exchange System Manager to change the location of your message tracking logs.

Exchange 2003, like Exchange 2000, uses the format \\\.log to automatically create a path to a shared folder for message tracking. The individual message log file names are date specific, using the format YYYYMMDD. For example, 20021022.log is the log file for October 22, 2002. Ensure that any users who you want to monitor the log files have remote access to this share.

In Exchange 2003, you can use Exchange System Manager to move your message tracking logs. You no longer need to use directory modification tools to change the location of your message tracking logs on a server. For detailed instructions on changing the file location of the message tracking logs on an Exchange server, see "How to Select a Location for the Message Tracking Log Files" in the Exchange Server 2003 Administration Guide.

Enhanced Message Tracking Capabilities In Exchange 2003, you can now track a message beyond the categorization phase. Categorization is the phase during which the recipient address is verified in Active Directory and its route is determined. You can now track the message through post-categorization and during the routing process. For detailed instructions, see How to Track a Message.

Including Bcc Recipients in Archived Messages

When you enable archiving on a mailbox store, a copy of all messages sent or received by mailboxes on this store is sent to the mailbox you specify for archiving. In previous versions of Exchange, any recipients on the Bcc line were not archived. In Exchange Server 2003, you can enable a registry key to configure mailbox store archiving to include Bcc recipients. When you enable archiving to include the Bcc recipients, all message recipients are listed on the Bcc list (not just those on the Bcc line).

Note:

To view the recipients on the Bcc list, you must use the Outlook client to access the archive mailbox. You cannot use Outlook Web Access to view the Bcc recipients.

To include Bcc recipients in archived messages, perform the following steps:

1. Enable archiving on the mailbox store. For detailed instructions, see "How to Enable Standard Journaling" in Journaling with Exchange Server 2003. 2. Set the registry key on each server for which you want archiving to include Bcc recipients. For detailed instructions, see How to Enable Bcc Recipient Archiving on a Mailbox Store. 3. On each server that you set the registry key, restart the following services. For detailed instructions, see How to Restart the Necessary Services to Enable Bcc Recipients in Archived Messages. How to Create an InetOrgPerson

The InetOrgPerson object is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization. The procedures to create a mailbox-enabled or mail-enabled InetOrgPerson are the same as creating a user object. This procedure describes how to create an InetOrgPerson. Before You Begin You can create an InetOrgPerson only if you are running a Microsoft Windows Server™ 2003 domain controller. InetOrgPerson can be mail- enabled or mailbox-enabled only in a native Exchange 2003 topology.

Procedure To create an InetOrgPerson 1. Click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

2. In the console tree, navigate to the container where you want to create the InetOrgPerson, right-click the container, point to New, and then click InetOrgPerson.

3. In New Object – InetOrgPerson, complete the remaining steps.

Note:

Other than Step2 above, create an InetOrgPerson the same way you would create a standard user account.

How to Enable or Disable Exchange Features for a Single User

These Exchange features provide added functionality for your mailbox-enabled users. You can enable or disable the user's Mobile Services options (such as Microsoft Outlook® Mobile Access), or Protocols (such as Outlook Web Access). This procedure describes how to enable or disable Exchange features for a single user. Procedure To enable or disable Exchange features for a single user 1. Click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

2. In the console tree, expand the container where you want to enable or disable Exchange features, and then click Users.

3. In the details pane, right-click the user you want to modify, and then click Properties.

4. In Properties, click the Exchange Features tab. The Exchange Features tab

5. Under Features, select a feature, and then click Enable or Disable.

Note:

You can also use the Configure Exchange Features page in the Exchange Task Wizard to enable or disable Exchange features for a user. See the following procedure for information about how to do this.

How to Enable or Disable Exchange Features for Multiple Users

These Exchange features provide added functionality for your mailbox-enabled users. You can enable or disable the user's Mobile Services options (such as Microsoft Outlook® Mobile Access), or Protocols (such as Outlook Web Access). This procedure describes how to enable or disable Exchange features for a multiple users. Procedure To enable or disable Exchange Features for multiple users 1. Click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

2. In the console tree, expand the container where you want to enable or disable Exchange features, and then click Users.

3. In the details pane, right-click the users you want to modify, and then click Exchange Tasks.

4. In the Exchange Task Wizard, on the Available Tasks page, click Configure Exchange Features, and then click Next.

5. On the Configure Exchange Features page, under Features, select a feature, click Enable or Disable, and then click Next (see the following figure). The Configure Exchange Features page

Note:

The default setting for modifying multiple users is Do Not Modify. If you want to enable or disable multiple users, click Enable or Disable for the individual feature you are selecting.

6. On the Task Summary page, click Finish to complete the wizard.

How to Disable Outbound Mail for All SMTP Queues

The Disable Outbound Mail option allows you to disable outbound mail from all SMTP queues. For example, this can be useful if a virus is active in your organization.

Note:

The Disable Outbound Mail option does not disable the MTA or System queues. Procedure To disable outbound mail for all SMTP queues 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. Navigate to Queue Viewer by performing one of the following steps:

 If you do not have routing or administrative groups defined: Expand Servers, expand the server you want, and then click Queues.  If you have administrative groups defined: Expand Administrative Groups, expand , expand Servers, expand the server you want, and then click Queues. 3. In the details pane, click Disable Outbound Mail to disable mail from all SMTP queues.

4. A warning message appears asking Are you sure you want to disable outbound mail? Click Yes. Outbound mail is now disabled for all queues.

5. To re-enable SMTP queues that have been disabled, click Enable Outbound Mail, and then click Yes.

Note:

If you want to prevent outbound mail from being sent to a specific remote queue instead of disabling all SMTP queues, you can freeze the messages in that queue. To freeze all the messages in a particular queue, right-click the queue, and then click Freeze. To unfreeze the queue, right-click the queue, and then click Unfreeze.

How to Modify Queue Viewer Refresh Rate Settings

The Settings option allows to you determine the frequency at which the all the queues are refreshed. The default rate at which the queues are refreshed is every 2 minutes. You can set the refresh rate to 1 minute, 5 minutes, 10 minutes, or Never refresh. Procedure To modify Queue Viewer refresh rate settings 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. Navigate to Queue Viewer by performing one of the following steps:

4. In Settings, in the Refresh queue rate list, select the refresh rate you want.

5. Click OK.

How to Find Messages

You can use the Find Messages option to search for messages by specifying search criteria such as the sender or recipient, and the message state (such as frozen). You can also specify the number of messages you want your search to return. Procedure To find messages 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. Navigate to Queue Viewer by performing one of the following steps:

 If you do not have routing or administrative groups defined: Expand Servers, expand the server you want, and then click Queues.  If you have administrative groups defined: Expand Administrative Groups, expand , expand Servers, expand the server you want, and then click Queues. 3. In the details pane, click the queue in which you want to search for messages, and then click Find Messages. The Find Messages dialog box

4. In Find Messages - , select from the following search criteria:

 To search for a particular sender, click Sender, and then, in Select Sender, specify your search criteria.  To search for a particular recipient, click Recipient, and then, in Select Recipient, specify your search criteria.  To specify the number of messages returned by the search, in the Number of messages to be listed in the search list, select the number of messages (for example, 500) you want listed in the search.  To search for messages in a particular state, in the Show messages whose state is list, select from the following states. - All Messages This option shows all the messages, regardless of their state. - Frozen This option shows messages that are in frozen state. This does not mean that the entire queue is frozen—a single message can also be frozen. - Retry This option shows the messages that are awaiting another delivery attempt. Messages in the retry state have failed one or more delivery attempts. 5. Click Find Now to begin the search. The results of the search are displayed under Search Results.

6. To stop a search, click Stop. To begin a new search, click New Search (this resets the Find Messages dialog box to its default settings).

How to View Additional Information About a Queue

The Additional queue information pane (located at the bottom of the Queue Viewer pane) contains information about a particular queue, including:

 Troubleshooting information  Information about errors returned from Exchange specific extensions to the SMTP service, (for example, errors due to remote server connection problems)  Information about queue availability (for example, if the SMTP service has not started) Procedure To view additional information about a queue 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. Navigate to Queue Viewer by performing one of the following steps:  If you do not have administrative groups defined: Expand Servers, expand the server you want, and then click Queues.  If you have administrative defined: Expand Administrative Groups, expand , expand Servers, expand the server you want, and then click Queues. 3. In the details pane, click the queue you want. Any additional information for that queue appears under Additional queue information at the bottom of the details pane.

How to View the Content of a Public Folder Using Exchange System Manager

You can use Exchange System Manager to view the contents of a public folder. This procedure outlines how to view the content of a public folder. Procedure To view the content of a public folder using Exchange System Manager 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. If administrative groups are displayed, expand Administrative Groups, and then expand the group you want to work with.

3. Expand Folders, expand the appropriate top-level hierarchy, and then click the public folder whose content you want to view.

New tabs available for viewing public folder information

4. In the details pane, click the Content tab.

5. If prompted for a user name and password, type the user name and password of an account that has permission to view the folder contents. The folder contents, displayed in a manner similar to Outlook Web Access, will be listed in the details pane.

How to Search for a Public Folder

You can use the Find tab in Exchange System Manager to search for public folders within the selected public folder or public folder hierarchy. You can specify a variety of search criteria, such as the folder name or age. This procedure outlines how to search for a public folder.

Note:

The Find tab is available at the top-level hierarchy level as well as the folder level. Procedure To search for a public folder 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. If administrative groups are displayed, expand Administrative Groups, and then expand the group you want to work with. 3. Expand Folders, expand the appropriate top-level hierarchy, and then click the public folder that may contain the folder that you want.

4. In the details pane, click the Find tab.

5. To identify the folder you want, fill in the appropriate criteria:

 If you know part of the folder name, you can type that information in the Name contains box.  If you know that a particular user or group has certain permissions on the folder, click Permissions, and then fill in the user or group name and specify the permissions. Then click OK to return to the Find tab.  If you know that the folder is replicated to certain servers, click Replicated to, and then select the appropriate server. Then click OK to return to the Find tab.  If you know that the folder was created or modified within a certain date range, in the Specify folder list, click Modified or Created, and then use the Begin date and End date lists to specify the date range.  If you know when the folder was created, in the Folder Age list, click days or older, days or newer, or days, and then, in the Folder age box, type the appropriate number of days. 6. Click Find Now.

How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows 2000 Server

You can use Mailbox Recovery Center to recover one or more mailboxes on one or more mailbox stores. You can export the mailbox properties, and you can associate the mailboxes with users in Active Directory and reconnect the mailboxes.

Note:

Some procedures are different for Windows 2000 Server and Windows Server 2003.

This procedure describes how to specify a mailbox store to work with if you are running Exchange System Manager on Windows 2000 Server.

Procedure To specify a mailbox store to work with if you are running Exchange System Manager on Windows 2000 Server 1. Start Exchange System Manager: Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, expand Tools, right-click Mailbox Recovery Center (see the following figure), and then click Add Mailbox Store.

3. In Add mailbox store(s), click the mailbox store you want, and then click Add. You can add multiple mailbox stores in this manner.

4. Click OK to add the store. After the store has been added, the details pane will list any disconnected mailboxes in that store.

The Mailbox Recovery Center in Exchange System Manager

For More Information

 For more information about recovering one or more mailboxes on one or more mailbox stores, see "How to Recover One or More Mailboxes on One or More Mailbox Stores" in the Exchange Server 2003 Administration Guide.

How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows Server 2003

Note:

Some procedures are different for Windows 2000 Server and Windows Server 2003.

This procedure describes how to specify a mailbox store to work with if you are running Exchange System Manager on Windows Server 2003.

Procedure To specify a mailbox store to remove if you are running Exchange System Manager on Windows Server 2003 1. Start Exchange System Manager: Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, expand Tools, right-click Mailbox Recovery Center, and then click Remove Mailbox Store.

3. In Remove mailbox store(s), click the mailbox store you want, and then click Remove. You can remove multiple mailbox stores in this manner.

4. Click OK to remove the mailbox store.

For More Information

For more information on recovering one or more mailboxes on one or more mailbox stores, see "How to Recover One Or More Mailboxes on One or More Mailbox Stores" in the Exchange Server 2003 Administration Guide. How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows 2000 Server

You can use Mailbox Recovery Center to remove one or more mailboxes on one or more mailbox stores. You can export the mailbox properties, and you can associate the mailboxes with users in Active Directory and reconnect the mailboxes.

Note:

Some procedures are different for Windows 2000 Server and Windows Server 2003.

This procedure describes how to specify a mailbox store to remove if you are running Exchange System Manager on Windows 2000 Server.

Procedure To specify a mailbox store to remove if you are running Exchange System Manager on Windows 2000 Server 1. Start Exchange System Manager: Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, expand Tools, right-click Mailbox Recovery Center, and then click Remove Mailbox Store.

3. In Remove mailbox store(s), click the mailbox store you want, and then click Remove. You can remove multiple mailbox stores in this manner.

4. Click OK to remove the mailbox store.

For More Information

 For more information on recovering one or more mailboxes on one or more mailbox stores, see "How to Recover One or More Mailboxes on One or More Mailbox Stores" in the Exchange Server 2003 Administration Guide.

How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows Server 2003

Note:

Some procedures are different for Windows 2000 Server and Windows Server 2003.

This procedure describes how to specify a mailbox store to remove if you are running Exchange System Manager on Windows Server 2003.

Procedure To specify a mailbox store to remove if you are running Exchange System Manager on Windows Server 2003 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Tools, right-click Mailbox Recovery Center, and then click Remove Mailbox Store.

3. In Remove mailbox store(s), specify the following criteria for identifying the appropriate mailbox store:

 In the Enter the object names to select box, type the name of the mailbox store you want to remove.  To limit the search to a certain part of Active Directory, click Locations, select a directory container, and then click OK to return to the Remove mailbox store(s) dialog box.

Note:

If you are unsure about which mailbox store you need, click Advanced, specify criteria, and then click Find now to locate the mailbox store. Select the appropriate mailbox store, and then click OK to return to the Remove mailbox store(s) dialog box. 4. Click OK to remove the mailbox store.

For More Information

For more information on recovering one or more mailboxes on one or more mailbox stores, see How to Recover One Or More Mailboxes On One Or More Mailbox Stores" in the Exchange Server 2003 Administration Guide.

How to Track a Message

In Exchange 2003, you can track a message beyond the categorization phase. Categorization is the phase during which the recipient address is verified in Active Directory and its route is determined. You can track the message through post-categorization and during the routing process. This procedure describes how to track a message. Procedure To track a message 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, expand Tools, and then click Message Tracking Center.

3. In the details pane, specify your search criteria, and then click Find Now.

The following new categories are available:

 Messages categorized and queued for routing (enqueue for routing)  Messages routed and queued for local delivery (enqueue for local delivery)  Messages routed and queued for remote delivery (enqueue for remote delivery)  Messages queued for categorization retry  Messages queued for local delivery retry  Messages queued for routing retry

How to Enable Bcc Recipient Archiving on a Mailbox Store

To configure mailbox archiving to include Bcc recipients, you must change the value of the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\JournalBCC This procedure outlines how to enable Bcc recipient archiving on a mailbox store. Before You Begin This topic contains information about editing the registry.

Caution:

2. Navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\

3. If necessary, create a registry key named Parameters: In the console tree, right-click MSExchangeTransport, point to New, and then click Key.

4. Type Parameters for the key name.

5. Right-click Parameters, point to New, then click DWORD Value.

6. In the details pane, type JournalBCC.

7. Right-click JournalBCC, and then click Modify.

8. In Edit DWORD Value, under Value Data, type 1, and then click OK How to Restart the Necessary Services to Enable Bcc Recipients in Archived Messages

After setting the registry key on each server for which you want archiving to include Bcc recipients, you must restart the following services: IIS Admin Service (IISADMIN), Microsoft Exchange MTA Stacks service (MSExchangeMTA), and Microsoft Exchange Information Store service (MSExchangeIS). This procedure describes how to enable the necessary services.

Procedure To restart the necessary services to enable Bcc recipients in archived messages 1. Click Start, point to All Programs, point to Administrative Tools, and then click Services.

2. In Services, in the details pane, right-click each of the following services, and then click Restart:

 IIS Admin Service  Microsoft Exchange Information Store  Microsoft Exchange MTA Stacks

The archive mailbox now displays the Bcc recipients of any messages sent to or received from this mailbox store. All recipients, including recipients on the To and Cc lines, are displayed in the Bcc line of messages in the archive mailbox.

Note:

Remember to use an Outlook client to access this mailbox and view the Bcc recipients. You cannot use Outlook Web Access to view the Bcc recipients. For More Information

For more information, see How to Enable Bcc Recipient Archiving on a Mailbox Store

Performance and Scalability Features of Exchange Server 2003

To enhance the performance and scalability of your Exchange organization, Microsoft® Exchange Server 2003 provides the following new or improved features:

 New in SP1: Improved support for multiple processors  New in SP2: Improved offline address book performance  Improved distribution list caching  Suppression of Out of Office messages to distribution list members  Enhanced DNS-based Internet mail delivery  Improved Microsoft Office Outlook® synchronization performance  Improved Outlook Web Access performance  Monitoring Outlook client performance  Link state improvements  Virtual Address Space improvements  Changing the MTA file directory location using Exchange System Manager  Changing the SMTP mailroot directory location using Exchange System Manager  Tuning Exchange Server 2003

This chapter discusses each of these topics in detail.

For information about improvements to reliability, a closely related topic, see "Reliability and Clustering Features of Exchange Server 2003."

New in SP1: Improved Support for Multiple Processors

Previously, Exchange server performance has shown marginal improvements when the number of processors in back-end servers increases to more than four. With more than eight processors, the performance increase is marginal at best, and sometimes the performance is actually worse. The falloff in performance gain with additional processors has become more pronounced with the types of processors used on more recent computers.

With Exchange Server 2003 Service Pack 1 (SP1), scalability with additional processors is much improved. When hyper-threading is enabled, eight-processor servers now provide a 50 percent increase in performance over four-processor servers. Use of eight-processor computers for back-end servers is now appropriate in many scenarios. Two-processor servers are still recommended for front-end servers.

New in SP2: Improved Offline Address Book Performance

In Exchange Server 2003 SP2, improvements were made to the offline address book performance. Specifically, these improvements help minimize the network impact of users downloading offline address book information.

Note:

To realize this enhanced performance, Exchange clients must be running Microsoft® Office Outlook® 2003 Service Pack 2 (SP2) or later.

The following list describes some of the improvements:

 Fewer situations will cause an e-mail client to download the full offline address book. Specifically, the changes in SP2 make sure that clients perform a differences download of the offline address list rather than full downloads. A differences download does not affect network performance and client performance as much as a full download.

Important:

In some cases, although Exchange Server determines that a differences download is more efficient, Exchange Server may be unable to generate a differences file for clients earlier than Outlook 2003 SP2. In versions of Exchange Server earlier than Exchange Server 2003 SP2, a full offline address book download is always forced if a differences file cannot be generated. However, if this occurs on a server running Exchange Server 2003 SP2, Exchange Server will instead log an event indicating that it was unable to produce a differences file and will not produce a full offline address book file. In this case, your users will not be able to receive offline address book updates until the problem is corrected. The description in the event specifies what changed in the directory that caused the problem. If you notice that the change in the directory was intentional, you may want to consider changing the default behavior of the offline address book server so that full offline address book downloads are generated when a differences download cannot be generated. To change this setting, you must edit the Windows registry as specified in the event log message. For information about how to configure this setting, see "Generate a Full Offline Address Book Download File when a Differences File Cannot Be Generated" in the Exchange Server 2003 SP2 online Help. For clients running Outlook 2003 SP2 or later, the change in the offline address book format resolves the issues that would stop the server from generating a differences file. The server will never attempt to force a full offline address book download by not generating a differences file for clients that are using the new offline address book format. However, the clients may still decide to do a full download if the size of the differences files is larger than a preset fraction of the full offline address book size.

 Full offline address book downloads are significantly reduced in size than on a server without SP2. These improvements are made possible by the adoption of an improved compression mechanism for the offline address book file.  Offline address book indexing is based on the locale setting (language and country) of the client. This enables users on the same server (with different locale settings) to correctly view the offline address book, sorted based on their locale setting and not the servers.  Diagnostic logging improvements make it easier to notice problems that may occur with offline address book downloads. Specifically, events have been added to help you monitor the following problems.  A Warning event is logged when at least one attribute is removed from the offline address book because it exceeds its size limit.  An Information event is logged every time a record is altered because some attributes exceed their size limits.  An Error event is logged when there is a failure in the differential download generation.  Ability to manage the size of offline address book download files by allowing you to specify that specific property types be limited in size in offline address list download files. To do this, in the registry, you can specify the maximum size in bytes for individual property types. Events are logged in the Application Log to help you track changes to these settings. For information about how to manage the size of offline address book download files, see "Manage Offline Address Book File Sizes" in the Exchange Server 2003 SP2 online Help.

Improved Distribution List Membership Caching

Exchange 2000 Server and Exchange Server 2003 use a rules cache to look up distribution list memberships prior to sending messages. In Exchange 2003, the rules cache has been optimized. As a result, the processing time that is required to look up the membership of a distribution list has been reduced. This new functionality improves performance by redesigning the cache so that lookups, insertions, and expirations can be completed more efficiently, thereby resulting in a sixty percent reduction of distribution list-related Microsoft Active Directory® directory service queries. The net benefit of the redesigned cache is a small reduction in Active Directory usage (distribution list lookups are only a small percentage of overall Active Directory lookups).

Suppressing Out of Office Messages to Distribution List Members

In previous versions of Exchange, if you create an Out of Office message, that message is sent to all members of any distribution lists that appear on the To or Cc lines. In Exchange 2003, the Out of Office message is not sent to the entire membership of a distribution list appearing on the To or Cc lines. Instead, Out of Office messages are sent only to individual user names that have been specified on the To or Cc lines of incoming messages.

This change was implemented after determining that users who send e-mail messages to distribution lists frequently do not want to receive Out of Office messages from distribution list members. This change provides a minor performance benefit to Exchange servers; specifically, CPU usage is minimally reduced.

Enhanced DNS-Based Internet Mail Delivery

Domain Name System (DNS)-based Internet mail delivery has been enhanced for Exchange 2003. Specifically, load balancing of DNS-based Internet mail is now more efficient. In addition, Exchange 2003 provides improved tolerance to network and host unavailability, as well as to unresponsive external DNS servers.

This change provides a performance benefits to Exchange servers; specifically, DNS-based Internet mail is delivered more reliably.

Improved Outlook Synchronization Performance

Exchange 2003 improves the end-user experience for Outlook 2003 users.

The following are improvements to Exchange Server 2003 and Outlook 2003 communication:

 The number of change notifications is reduced.  Exchange 2003 detects the native format of messages (for example, HTTP) to be synchronized and only sends messages in that format to the client.  Improvements to the conditions in which Outlook clients request synchronizations that include nested folder hierarchies.  Users now receive a message indicating the number and size of messages to be downloaded.  Exchange 2003 performs data compression to reduce the amount of information sent between the Outlook 2003 client and the Exchange 2003 servers.  Exchange 2003 reduces the total number of requests for information sent between the user with Outlook 2003 and the Exchange server.

Exchange 2003 improves the Outlook synchronization performance for users working in Cached Exchange Mode.

The following is a list of enhancements that relate to Outlook clients running in Cached Exchange Mode:

 The number of change notifications is reduced.  Exchange 2003 detects the native format of messages (for example, HTTP) to be synchronized and only sends messages in that format to the client.  Improvements to the conditions in which Outlook clients request synchronizations that include nested folder hierarchies.  Users now receive a message indicating the number and size of messages to be downloaded. Users can select which messages they want to download.  Exchange 2003 performs data compression to reduce the amount of information sent between the Outlook 2003 client and the Exchange 2003 servers.  Exchange 2003 reduces the total requests for information between the client and server, whether or not an Outlook 2003 client is working in cached mode, thereby optimizing client and server communication.

These changes provide a reduction in CPU usage on the Exchange server. Specifically, the server uses less processing power as a result of fewer and less intensive client requests from Outlook clients.

Improved Outlook Web Access Performance

Exchange Server 2003 improves the end user experience for Outlook Web Access users by reducing the total amount of information sent between the computer running Outlook Web Access and the Exchange server.

Outlook Web Access client performance is improved in Exchange 2003 . For example, Outlook Web Access users will notice that their Inboxes load more quickly. They will also notice that tasks will be more responsive, especially over slow connections. A primary reason for this is because Exchange 2003 provides a reduction in the amount of bytes that must travel from the server to the browser. Monitoring Outlook Client Performance

Previous versions of Exchange could not monitor the end-user performance experience for Outlook users. However, with Exchange 2003 and Outlook 2003, administrators can analyze performance for their users.

Exchange 2003 servers record both RPC latency and errors on client computers running Outlook 2003. An administrator can use this information to determine the overall experience quality for their users, as well as to monitor the Exchange server for errors.

Outlook clients send RPC data (for example, latency data or error code) to the Exchange 2003 server on a subsequent successful RPC calls.

Note:

RPC data sent from the client computers to the Exchange server are not the primary method for detecting individual real time errors.

The following table lists the RPC-related operations that you can monitor using Microsoft Operations Manager. For information about using Microsoft Operations Manager, see http://go.microsoft.com/fwlink/?LinkId=16198 and http://go.microsoft.com/fwlink/?LinkId=18176.

Client-side performance monitors using Microsoft Operations Manager

Counter Description

Client: RPCs attempted The total number of RPC requests attempted by the users (since the Exchange store was started).

Client: RPCs succeeded The total number of successful RPC requests sent by the Outlook client (since the Exchange store was started).

Client: RPCs failed The total number of failed RPC requests (since the Exchange store was started).

Client: RPCs failed: Server The number of failed RPC requests (since the Exchange store was started) due to the "Server unavailable Unavailable" RPC error.

Client: RPCs failed: Server too busy The number of failed RPC requests (since the Exchange store was started) due to the "Server Too Busy" RPC error.

Client: RPCs failed: all other errors The number of failed RPC requests (since the Exchange store was started) due to all other RPC errors.

Client: RPCs attempted / sec The rate of RPC requests attempted by the user.

Client: RPCs succeeded / sec The rate of successful RPC requests.

Client: RPCs failed / sec The rate of failed RPC requests.

Client: RPCs failed / sec: Server The rate of failed RPC requests (since the Exchange store was started) due to the "Server unavailable Unavailable" RPC error.

Client: RPCs failed / sec: Server too The rate of failed RPC requests (since the Exchange store was started) due to the "Server Too busy Busy" RPC error.

Client: RPCs failed / sec: all other The rate of failed RPC requests (since the Exchange store was started) due to all other RPC errors. errors

Client: Total reported latency The total latency (in seconds) for all RPC requests (since the Exchange store was started).

Client: Latency > 2 sec RPCs / sec The rate of successful RPC requests with latencies > 2 seconds.

Client: Latency > 5 sec RPCs / sec The rate of successful RPC requests with latencies > 5 seconds.

Client: Latency > 10 sec RPCs / sec The rate of successful RPC requests with latencies > 10 seconds.

Link State Improvements

Exchange 2003 reduces the amount of link state traffic by suppressing link state information when no alternate path exists or a connection is oscillating. (An oscillating connection is a connection that fluctuates between available and unavailable). In both cases, the link state remains available, and therefore reduces the amount of link state traffic that is propagated.

For more information about link state improvements, see "Link State Improvements" in Transport and Message Flow Features of Exchange Server 2003.

Virtual Address Space Improvements

With Exchange 2000, administrators may have experienced issues regarding virtual address space management. To address these issues, Exchange 2003 presents the following improvements:  Multiple improvements to remove many small memory allocations made by Exchange components.  Multiple improvements to ensure that memory allocations are efficient. For example, requesting a 32 KB buffer instead of 17 KB buffer and not wasting the remaining memory.  At start-up, Epoxy now allocates a large 190 MB contiguous portion of memory, instead of allocating a smaller portion and then gradually requesting more memory. You can use DSAccess settings to change this Expoxy memory allocation.  The Store.exe process thread stack size is reduced from 512 KB to 256 KB.  Depending on a server's configuration, the Store.exe process now allocates a suitable Extensible Storage Engine (ESE) cache buffer size, instead of using a hard-coded value. For a server that has the /3GB option set, a cache size of 896 MB is set (for example, 28 pieces of 32 MB). If the /3GB option is not set, the cache size is set to 576 MB (for example, 18 pieces of 32 MB). For information about setting the /3GB option, see Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch With More Than 1 Gigabyte of Physical RAM."

Note:

You should set the /3GB switch only on servers that meet the following criteria:

Note:

The server hosts Exchange 2003 mailboxes or public folders.

Note:

The server has 1 GB or more of physical memory.

 If available virtual memory reaches 32 MB, Exchange 2003 sends a one-time request to the ESE buffer cache to increase by 64 MB (default). This 64 MB portion becomes available for message processing and provides the administrator with more time before it is necessary to start the Store.exe process.  Exchange performs an optimal memory configuration check when the Exchange store process starts. If the memory settings are not optimal, event 9665 will appear in Event Viewer. This message appears in the following instances:  The server is running Microsoft Windows® 2000 Server and the SystemPages value in the registry is set outside the range of 24000 to 31000.  The server has 1 GB of memory or more and does not have the /3GB switch.  The server is running Microsoft Windows Server™ 2003, has 1 GB of memory or more, and the /3GB switch is set, but the /USERVA setting is not present or is outside the range of 3030 to 2970.

If you see this event, check the SystemPages and HeapDeCommitFreeBlockThreshold settings in the registry, as well as the /3GB switch and the USERVA setting in the boot.ini file.

Note:

If you want to turn off the memory configuration check, you can create the following registry key.

Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\

Parameter Suppress Memory Configuration Notification

Type REG_DWORD

Setting 1

Changing the MTA File Directory Location Using System Manager

By default, the Exchange MTA database and run directories are located under the folder where Exchange 2003 is installed (:\Program Files\Exchsrvr\ MTADATA). On some servers, especially where Exchange is functioning as a bridgehead server, you can positively impact performance by relocating the MTA database on a fast disk array, such as a RAID 0+1 partition.

Note:

When you modify the location of the queue directory, you are modifying only the MTA database path and moving only the database files (.dat files); you are not moving any of the run files or the run directory.

Note: Do not attempt to relocate the MTA run directory as this can cause performance problems.

In Exchange 2003, you can now use Exchange System Manager to change the location of the MTA database. To do this, use the General tab in the X.400 Properties dialog box. For more information about how to change the location of the MTA database, see "Moving the X.400 (MTA) and SMTP Queue Directory Locations" in Chapter 6.

Changing the SMTP Mailroot Directory Location Using System Manager

In Exchange 2003, when messages arrive through SMTP, the data is written to a disk in the form of a Microsoft Windows NT File System (NTFS) file (specifically, an .eml file). By default, these files are written to a directory (:\Program Files\Exchsrvr\Mailroot) on the same disk partition where the Exchange 2003 binary files are installed.

In some scenarios, such as configuring a bridgehead or relay server, relocating the SMTP Mailroot directory to a faster disk partition may positively impact performance.

In Exchange 2003, you can now use Exchange System Manager to move the Mailroot directory. To do this, use the Messages tab in the SMTP Virtual Server Properties dialog box. For more information about how to move the Mailroot directory, see "Moving the X.400 (MTA) and SMTP Queue Directory Locations" in Transport and Message Flow Features of Exchange Server 2003.

Tuning Exchange 2003

Upon installation, Exchange 2003 performs very well and does not require much tuning. However, in situations where you are coexisting with previous versions of Exchange or implementing large scale-up Exchange 2003 servers, some manual tuning may be required.

Although this section does not provide a complete list of tuning recommendations, it does recommend tuning changes when upgrading an Exchange 2000 server to Exchange 2003.

Removing Exchange 2000 Tuning Parameters

Many Exchange 2000 tuning parameters (for example, those parameters listed in the technical article Microsoft Exchange 2000 Internals: Quick Tuning Guide), are no longer applicable in Exchange 2003; in fact, some of these parameters cause problems. If you previously tuned your Exchange 2000 servers by adding any of the settings listed in this section, you must manually remove them on your servers running Exchange 2003. The tools you use to remove those settings are Registry Editor, Internet Information Services Manager, and ADSI Edit. For information about how to use Registry Editor, Internet Information Services Manager, and ADSI Edit, see Windows Server Help.

Note:

Initial Memory Percentage

The Initial Memory Percentage registry key no longer works with Exchange 2003. Therefore, use Registry Editor to delete the following registry parameter when Exchange 2003 is installed.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Parameter: Initial Memory Percentage (REG_DWORD) Extensible Storage System Heaps

The optimum number of heaps is now automatically calculated with Exchange 2003. Therefore, use Registry Editor to delete the following registry parameter when Exchange 2003 is installed.

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ESE98\Global\OS\Memory

Parameter: MPHeap parallelism (REG_SZ) DSAccess MaxMemoryConfig Key

If you previously tuned DSAccess performance by adding a MaxMemoryConfig key, that key is no longer recommended. Therefore, you should use Registry Editor to remove the following registry parameter when Exchange 2003 is installed.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryConfig (REG_DWORD) DSAccess Memory Cache Tuning If you previously tuned the user cache in DSAccess, you can now remove your manual tuning. Exchange 2000 had a default user cache of 25 MB, whereas Exchange 2003 defaults to 140 MB. Therefore, you should use Registry Editor to remove the following registry parameter when Exchange 2003 is installed.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryUser (REG_DWORD)

Outlook Web Access Content Expiration

You should not disable content expiry for the \Exchweb virtual directory. The default expiration setting of 1 day should be used in all scenarios. You can view and modify this setting in Internet Information Services Manager.

Log Buffers

If you previously tuned the msExchESEParamLogBuffers parameter manually [for example, to 9000 (an Exchange 2000 SP2 recommendation), or 500 (an Exchange 2000 SP3 recommendation)], clear the manual tuning. Exchange 2003 uses a default value of 500. Previously, Exchange 2000 used a default value of 84.

To return this setting to the default setting of , open the following parameter in ADSI Edit, and then click Clear.

Location: CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=/CN=Administrative Groups/CN=/CN=Servers/CN=/CN=Information Store>/CN=

Parameter: msExchESEParamLogBuffers Max Open Tables

If you tuned the msExchESEParamMaxOpenTables parameter manually, you should clear the manual tuning. When the value of the parameter is cleared, Exchange 2003 automatically calculates the correct value for you; for example, on an eight-processor server, a value of 27600 is used.

To return this setting to the default setting of , open the following parameter in ADSI Edit, and then click Clear.

Location: CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=/CN=Administrative Groups/CN=/CN=Servers/CN=/CN=Information Store>/CN=

Parameter: msExchESEParamMaxOpenTables

Reliability and Clustering Features of Exchange Server 2003

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.

Reliability Features

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.

Improved Virtual Memory Management

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 Displays the size (in bytes) of the largest free block of virtual memory. This counter is a line that slopes downward as Block Size 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 Displays the total number of free virtual memory blocks that are greater than or equal to 16 MB. This line forms a pyramid 16MB Free as you monitor it. It starts with one block of virtual memory greater than 16 MB and progresses to smaller blocks greater Blocks 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 Displays the total number of free virtual memory blocks, regardless of size. This line forms a pyramid as you monitor it. Blocks 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 Displays the sum (in bytes) of all the free virtual memory blocks that are greater than or equal to 16 MB. This line slopes Large Free downward as memory is consumed. Block Bytes

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.

Mailbox Recovery Center

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.

Recovery Storage Group

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.

Improved Error Reporting

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

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

Note:

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.

Note:

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. Clustering Features

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:

 For planning information, read the section "Using Server Clusters" in Planning an Exchange Server 2003 Messaging System.  For deployment information, see "Deploying Exchange 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide.  For administration information, see "Managing Exchange Server Clusters" in the Exchange Server 2003 Administration Guide.

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.

Support for Up to Eight-Node Clusters

Note:

All Exchange 2003 clustering recommendations are for active/passive cluster configurations. Active/active clustering will continue to be supported on two nodes. Windows and Exchange Version Requirements

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

Cluster nodes Windows version Exchange version available

Any server in the Windows® 2000 Server or Window Exchange Server 2003, Standard Edition None Server 2003 families

Windows 2000 Server or Windows Server 2003, Exchange Server 2003, Standard Edition or Exchange None Standard Edition Server 2003, Enterprise Edition

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 Support for Volume Mount Points 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.

Improved Failover Time

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.

Improved Dependency Hierarchy for Exchange Services

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

Hierarchy of Exchange dependencies in Exchange 2003

Note: 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).

Improved Detection of Available Nodes 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.

Security Improvements

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.

Clustering Permission Model Changes

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.

Exchange 2000 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.

Exchange 2003 Permissions Model

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.

Note:

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. Kerberos Enabled by Default on Exchange Virtual Servers

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.

IPSec Support for Front-End and Back-End Cluster Configurations

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.

IMAP4 and POP3 Resources Not Added by Default

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.

Checking Clustering Prerequisites

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.

Exchange 2003 Cluster Requirements

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.

Exchange Server 2003 Setup Requirements

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.

Upgrading an Exchange 2000 Cluster and Exchange Virtual Server to Exchange 2003

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.

Note:

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 SP4 or Windows 2000 SP3 with hotfix 329938 is required. Windows 2000 To obtain Windows 2000 SP4, go to the Windows 2000 Service Packs Web site.

 To obtain the Windows 2000 SP3 hotfix, see the Microsoft Knowledge Base article 329938, "Cannot Use Outlook Web Access to Access an Exchange Server Installed on a Windows 2000 Cluster Node."

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  The Network Name resource must be online. resources  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.

How to Enable Automatic Service-Related Error Reporting

If you do not want to view the standard error reporting dialog box, you can configure Exchange to automatically send service-related error reports to Microsoft. This configuration is useful if you do not want to be interrupted when logging on after an error has occurred (for example, if you already check the Event Log at a specific time each day). Procedure To enable automatic service-related error reporting 1. Start System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then point to System Manager.

2. In the console tree, expand Servers, right-click the server on which you want to enable automatic error reporting, and then click Properties.

3. In Properties>, On the General tab, select the Automatically send fatal service errors information to Microsoft check box. The Automatically send fatal service errors information to Microsoft check box

4. In the confirmation dialog box that appears, click Yes.

Dialog box confirming that you want to automatically send service-related fatal error information to Microsoft

Transport and Message Flow Features of Exchange Server 2003

Microsoft® Exchange Server 2003 introduces several new features and functionality to improve transport and message flow. This topic explains the following:

Link state improvements

This section explains how link state improvements reduce the amount of link state information that is replicated throughout the Exchange organization, thereby reducing the negative effect on performance.

Cross-forest authentication configuration

Because Exchange 2003 prevents spoofing or forging e-mail addresses, you must perform specific configuration steps to enable cross- forest authentication. This section shows you how to enable cross-forest authentication. Internet Mail Wizard

Exchange 2003 provides a new version of Internet Mail Wizard to guide you through configuring Internet mail delivery in your organization. This section explains how to use the wizard to set up Internet mail delivery.

Delivery status notification (DSN) diagnostic logging and codes

Exchange 2003 now provides diagnostic logging for delivery status notifications (DSNs) and implements some new DSN codes. This section explains how to configure DSN diagnostic logging and explains the new DSN codes available in Exchange 2003.

Support for moving X.400 (MTA) and SMTP queue directories

In Exchange 2003, you can use Exchange System Manager to change the location where your SMTP and X.400 queue data is stored. This section explains how to use Exchange System Manager to move your queue directory.

Connection filtering

Exchange 2003 supports connection filtering based on block lists. This section explains how connection filtering works, and how you can set it up on your Exchange server.

Recipient filtering

Exchange 2003 also supports recipient filtering so that you can filter e-mail messages that are addressed to users who are not in the Microsoft Active Directory® directory service or e-mail messages that are addressed to well-defined recipients indicative of unsolicited commercial mail.

New in SP2: Sender ID filtering

In Exchange Server 2003 SP2, you can use Sender ID filtering features. Sender ID is an e-mail industry initiative that you can use to provide more protection against unsolicited commercial e-mail (UCE) and phishing schemes. Specifically, Sender ID helps prevent domain spoofing.

New in SP2: Intelligent message filtering

In Exchange Server 2003 SP2, Intelligent message filtering is now installed when you install Exchange Server 2003 SP2.

How enabled filters are applied

This section explains how filters and restrictions are applied during an SMTP session.

Improved ability to restrict submission to an SMTP virtual server

This section explains how you can restrict submissions based on security groups in Exchange 2003.

Improved ability to restrict relaying on an SMTP virtual server

This section explains how you can restrict relaying based on security groups in Exchange 2003.

Exchange 2003 also provides the following other features that enhance transport and mail flow:

 A new type of distribution group that is named query-based distribution groups allow you to use an LDAP query to dynamically build membership in the distribution groups. For more information, see "Query-Based Distribution Groups" and "Improved Message Tracking" in Administration Features in Exchange Server 2003.  You can now set restrictions on who can send mail to a distribution list. For more information, see "Improved Ability to Restrict Submissions to Users and Distribution Lists (Restricted Distribution Lists)" in Administration Features in Exchange Server 2003.  You can now track messages after categorization (which is the phase where users are located and distribution groups are expanded into individual recipients) and during the routing process. You can also use Exchange System Manager to move message-tracking logs. For more information, see "Improved Message Tracking" in Administration Features in Exchange Server 2003.  Improvements to Queue Viewer. More queues are exposed, so you can more easily diagnose problems with mail flow. For more information, see "Enhancements to Queue Viewer" in Administration Features in Exchange Server 2003.  With the archiving feature available on a mailbox store, you can archive all recipients, including those on the Bcc line. For more information, see "Including Bcc Recipients in Archived Messages" in Administration Features in Exchange Server 2003. Link State Improvements Exchange uses link state routing to determine the best method for sending messages between servers, based on the current status of messaging connectivity and cost. If no alternate path for the message exists, or if there is an oscillating connection (a connection that is intermittently available and unavailable), Exchange 2003 improves how link state information is communicated. Specifically, Exchange 2003 reduces link state traffic by attempting to determine if the connector state is oscillating or if no alternate path exists; if either of these conditions exists, Exchange suppresses the link state information.

Improved Link State Availability

In Exchange 2003, even if no alternate path exists for a link, the link state is always marked as up (in service). Exchange no longer changes the link state to unavailable if no alternate path exists. Instead, Exchange simply queues mail for delivery and sends it when the route becomes available. This change enhances performance because it reduces the propagation of link state information.

Link State Improvements for Oscillating Connections

Another significant improvement to link state routing is how Exchange 2003 handles oscillating connections. Exchange 2003 reviews the link state queue, and if there are multiple conflicting state changes in a given interval for a connector, the connector is considered an oscillating connection, and its link state remains up (in service). It is better to leave an oscillating connector up than to continually change the link state. This reduces the amount of link state traffic that is replicated between servers.

Configuring Cross-Forest SMTP Mail Collaboration

To prevent spoofing (forging identities), Exchange 2003 requires authentication before a sender's name is resolved to its display name in the global address list (GAL). Therefore, in an organization that spans two forests, a user who sends mail from one forest to another forest is not authenticated. Furthermore, the user's name is not resolved to a display name in the GAL, even if the user is a contact in the destination forest.

To enable cross-forest mail collaboration in Exchange 2003, additional configuration steps are required to resolve contacts outside your organization to their display names in Active Directory. You have two options to enable the resolution of these contacts:

 Option 1 (recommended) Use authentication so that users who send mail from one forest to another are authenticated users, and their names are resolved to their display names in the GAL.  Option 2 Restrict access to the SMTP virtual server that is used for cross-forest collaboration, and then configure Exchange to resolve anonymous e-mail. This configuration is supported, but not recommended. By default, in this configuration, the Exch50 message properties, which are the extended properties of a message, are not persisted when mail is sent from one forest to another.

To understand the benefits of configuring cross-forest mail collaboration, consider the following scenarios of anonymous mail submission and cross-forest authenticated mail submission.

Scenario: Anonymous Mail Submission

E-mail addresses are not resolved if the submission is anonymous. Therefore, when an anonymous user who attempts to spoof (forge) an internal user's identity sends mail, the return address does not resolve to its display name in the global address list (GAL).

Example:

Kim Akers is a legitimate internal user at Northwind Traders. Her display name in the GAL is Kim Akers, and her e-mail address is [email protected].

To send mail, Kim must be authenticated. Because she is authenticated, the intended recipients of Kim's mail see that the sender is Kim Akers. Additionally, the properties of Kim Akers are displayed as her GAL entry. However, if Ted Bremer attempts to forge Kim's address by using [email protected] in the From line and then sending the mail to the Exchange 2003 server at Northwind Traders, the e-mail address is not resolved to Kim's display name because Ted did not authenticate. Therefore, when this e-mail message displays in Microsoft Office Outlook®, the sender address appears as [email protected]; it does not resolve to Kim Akers, as authenticated mail from Kim does.

Scenario: Cross-Forest Mail Delivery

Consider a company that spans two forests: the Adatum forest and the Fabrikam forest. Both these forests are single domains forests with domains of adatum.com and fabrikam.com respectively. To allow cross-forest mail collaboration, all users in the Adatum forest are represented as contacts in the Fabrikam forest's Active Directory. Likewise, all users in the Fabrikam forest are represented as contacts in Adatum forest's Active Directory.

If a user in the Adatum forest sends mail to Fabrikam forest, and the mail is submitted over an anonymous connection, the sender's address is not resolved, despite the fact the sender exists as a contact in the Active Directory and in the Outlook GAL. This is because a user in the Adatum forest is not an authenticated user in Fabrikam forest.

Example:

Kim Akers is a mail user in the Adatum forest—her e-mail address is [email protected], and her Outlook GAL display name is Kim Akers. Adam Barr is a user in the Fabrikam forest—his e-mail address is [email protected], and his Outlook GAL display name is Adam Barr. Because Adam is represented as an Active Directory contact in the Adatum forest, Kim can view Adam's e-mail address and resolve it to the display name of Adam Barr in the Outlook GAL. When Adam receives mail from Kim, Kim's address is not resolved; instead of seeing Kim's display name as it appears in the GAL, Adam sees her unresolved e-mail address of [email protected]. Because Kim sent mail as an anonymous user, her e-mail address did not resolve. Although Kim is authenticated when sending mail, the connection between the two forests is not authenticated.

To ensure that senders in one forest can send mail to recipients in another forests, and to ensure that their e-mail addresses resolve to their display names in the GAL, you should enable cross-forest mail collaboration. The following sections explain the two options available for configuring mail collaboration between two forests.

Enabling Cross-Forest Authentication

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from the other forest. By doing this, any mail that is sent between the two forests by an authenticated user resolves to the appropriate display name in the GAL. This section explains how to enable cross-forest authentication.

Using the example of the Adatum forest and the Fabrikam forest (see the "Cross-Forest Mail Delivery" scenario earlier in this topic), follow these steps to set up cross-forest authentication:

1. Create an account in the Fabrikam forest that has Send As permissions. (For all users in the Adatum forest, a contact is located in the Fabrikam forest as well; therefore this account allows Adatum users to send authenticated mail.) Configure these permissions on all Exchange servers that will accept incoming mail from Adatum. 2. On an Exchange server in the Adatum forest, create a connector that requires authentication using this account to send outbound mail.

Similarly, to set up cross-forest authentication from the Fabrikam forest to Adatum forest, repeat these steps, creating the account in Adatum and the connector in Fabrikam. For detailed instructions, see "How to Enable Cross-Forest SMTP Authentication" in the Exchange Server 2003 Deployment Guide.

Enabling Cross-Forest Collaboration by Resolving Anonymous Mail

Another way you can configure Exchange to resolve contacts outside your organization to their display names in Active Directory is to configure Exchange to resolve anonymous e-mail. Assume that your company spans two forests, from the Adatum forest to the Fabrikam forest.

Important:

Configuring Exchange servers to resolve anonymous mail submissions lets unscrupulous users submit messages with a falsified return address. Recipients are not able to differentiate between authentic mail and spoofed mail. To minimize this possibility, ensure that you restrict access to the SMTP virtual server to the IP addresses of your Exchange servers.

Follow these steps to resolve contacts for Adatum users to their display names in the Fabrikam forest:

1. Create a connector in the Adatum forest that connects to the Fabrikam forest. 2. On the receiving bridgehead server in the Fabrikam forest, restrict access to the SMTP virtual server by IP address. By doing this, you can ensure that only servers from the Adatum forest can send mail to this server. 3. On the SMTP virtual server that hosts the connector, enable the Resolve anonymous e-mail setting. 4. Change a registry key to ensure that the extended message properties (Exch50 properties) are persisted across the forests. Otherwise, you can lose important message information.

After you complete these steps, all users who send mail from the Adatum forest to the Fabrikam forest will resolve to their display names in the Fabrikam GAL. Next, you need to repeat steps 1 through 3 for the Fabrikam forest.

The following procedures show you how to:

 Set up a connector in the Adatum forest to Fabrikam.  Restrict access to the receiving bridgehead server in the Fabrikam forest  Enable anonymous e-mail resolution on the SMTP virtual server on the receiving bridgehead server in order to resolve Adatum contacts in the Fabrikam forest.

In a production environment, you would then repeat this process to configure the resolution of Fabrikam contacts in the Adatum forest.

Step 1: Creating a Connector in the Connecting Forest

First, you need to create a connector in the connecting forest. For detailed instructions, see How to Create a Connector in a Connecting Forest. For detailed instructions about how to create the account used for cross-forest authentication, see "How to Create the Account Used for Cross- Forest Authentication" in the Exchanger Server 2003 Transport and Routing Guide.

Exchange will now route all mail destined to fabrikam.com (the Fabrikam forest) through this connector.

Step 2: Restricting IP Addresses on the Receiving Bridgehead Server

After you create the connector in the Adatum forest (the connecting forest) you must restrict access to the receiving bridgehead server. You do this by allowing only the IP address of the connecting servers in the Adatum forest to send mail to the receiving bridgehead server in the Fabrikam forest.

For detailed instructions, see "How to Restrict Access by IP Address on the Receiving Bridgehead Server" in the Exchange Server 2003 Transport and Routing Guide.

Step 3: Resolving Anonymous Mail on the SMTP Virtual Server

After you have restricted access to the receiving bridgehead server, you must configure the SMTP virtual server on this bridgehead to resolve anonymous e-mail addresses.

For detailed instruction, see "How to Configure an SMTP Virtual Server to Resolve Anonymous E-mail Addresses" in the Exchange Server 2003 Transport and Routing Guide.

Step 4: Enabling Registry Key to Persist Message Properties Across Forests

As explained earlier, when messages are sent anonymously across forests, the extended message properties on a message are not transmitted. For single companies that implement a cross-forest scenario, these message properties must be transmitted because information about the message can be lost. For example, the SCL property, an extended Exchange property contains a spam rating that is generated by third-party solutions. This property is not transmitted when mail is sent anonymously. So if a third-party anti-spam solution is deployed in the Adatum forest, and a message received in this forest is destined to a recipient in the Fabrikam forest, the third party solution stamps the SCL property on the message; however, when the message is delivered to the Fabrikam forest, the extended property containing the spam rating is not persisted.

To ensure that the extended message properties are transmitted across forests when you send mail anonymously, you must enable a registry key on the receiving bridgehead server.

To configure Exchange to accept the extended message properties, you can enable a registry key on the receiving bridgehead server or on the SMTP virtual server that resides on the bridgehead. Enabling the registry key on the Exchange server configures all SMTP virtual servers on the Exchange server to accept extended properties.

Configuring the Exchange Server to Accept Extended Message Properties on Anonymous Connections

Use the following procedure to configure the Exchange server to accept extended properties on anonymous connections. If your Exchange server functions solely as the bridgehead server for cross-forest communication, you may want to configure this setting at the server level. If you have other SMTP virtual servers on this Exchange server, consider setting this registry key on the SMTP virtual server only.

Note:

If you enable this registry key on an Exchange server, the setting applies to all SMTP virtual servers on the Exchange server. If you want to configure a single SMTP virtual server with this setting, enable the registry key on the SMTP virtual server.

Caution:

For detailed instructions, see "How to Enable an Exchange Server to Accept Message Extended Properties that Are Sent Anonymously" in the Exchange Server 2003 Transport and Routing Guide.

Configuring an SMTP Virtual Server to Accept Extended Message Properties Sent Anonymously

Use the following procedure to configure the SMTP virtual server on the Exchange server to accept extended properties

For detailed instructions, see "How to Enable an SMTP Virtual Server to Accept Message Extended Properties that Are Sent Anonymously" in the Exchange Server 2003 Transport and Routing Guide.

Internet Mail Wizard

In Exchange Server version 5.5, Internet Mail Wizard guided administrators through the process of setting up Internet mail. Exchange 2003 implements a version of Internet Mail Wizard to help you configure Internet mail connectivity with Exchange 2000 Server or Exchange Server 2003. Internet Mail Wizard is intended primarily for small and medium companies with less complex environments than large enterprise companies.

The wizard guides you through configuring your Exchange server to send and receive Internet mail. It creates the necessary SMTP connector for outgoing Internet mail and configures your SMTP virtual server to accept incoming mail. If you already set up SMTP connectors or created additional SMTP virtual servers on your Exchange server, you cannot run Internet Mail Wizard unless you revert your server configuration to its default state.

Note:

Internet Mail Wizard can only configure Internet mail for Exchange 2000 Server or a later version. If you are running previous versions of Exchange, these servers can still send mail to or receive mail from the Internet, but you cannot use Internet Mail Wizard to configure them for Internet mail.

When Internet Mail Wizard runs, it creates a log file (Exchange Internet Mail Wizard.log) of all the configuration changes it makes, including whether or not these changes were successful. The wizard saves this log file to the My Documents folder of the user who runs the wizard.

The following sections explain how to use Internet Mail Wizard to:

 Configure an Exchange server to send Internet mail  Configure an Exchange server to receive Internet mail  Configure an Exchange server or servers to send and receive Internet mail  Configure a dual-homed Exchange server for Internet mail Configuring an Exchange Server to Send Internet Mail

When you configure an Exchange server to send Internet mail, Internet Mail Wizard configures the selected server as an outbound bridgehead server. It creates a connector on this server to send mail to the Internet addresses you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Send Internet Mail.

Configuring an Exchange Server to Receive Internet Mail

After you run Internet Mail Wizard, the Exchange server will accept all Internet mail for the SMTP domains that you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Receive Internet Mail.

Configuring an Exchange Server to Send and Receive Internet Mail

After you run Internet Mail Wizard, the Exchange server will send and receive all Internet mail according to the configuration you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Send and Receive Internet Mail.

Configuring a Dual-Homed Exchange Server for Internet Mail

After you run Internet Mail Wizard, the Exchange server will send and receive all Internet mail according to the configuration you specify.

For detailed instructions, see How to Run Internet Mail Wizard on a Dual-Homed Server.

DSN Diagnostic Logging and DSN Codes

In Exchange 2003, the following improvements have been made to delivery status notifications (DSNs).

 A new DSN logging category is available.  New DSN codes are included to help troubleshoot message flow issues. Configuring DSN Diagnostic Logging

You can now configure diagnostic logging for DSNs, also known as non-delivery reports (NDRs).

For detailed instructions, see How to Configure Diagnostic Logging for DSN.

DSN Codes Available in Exchange Server 2003

The following table lists the DSN messages implemented in Exchange 2003 for transport and routing.

New delivery status notifications available in Exchange 2003

DSN Code Cause Solution

4.2.2 In Exchange 2000, this delivery status notification is generated when the Check the mailbox storage and the queue storage recipient's mailbox exceeds its storage limit. quota limit. On Windows® 2000 and Microsoft Windows Server™ 2003, this message is generated when the storage size of the drop directory (a directory where messages can be placed for delivery) exceeds the SMTP virtual server disk quota. The disk quota of the SMTP virtual server is 11 times the maximum message size on the virtual server. If no maximum size is specified, the disk quota defaults to 22 MB. If the disk space is within one maximum message size of the quota or if the disk space reaches 2 MB is no maximum message is defined, Exchange assumes that the incoming message will exceed the disk quota, and then issues the DSN.

4.4.9 This indicates a temporary routing error or bad routing Routing detects these situations, and configuration. Possible causes are: Exchange returns DSNs.

 Someone configured an SMTP connector using DNS (rather  To remedy the first scenario, configure than a smarthost) and added a non-SMTP address space, such as the SMTP connector to use a smarthost, an X.400 address, to this connector. instead of DNS, to resolve the non-SMTP

 Someone created a routing group, and a recipient in this address space. routing group was supposed to receive mail. A routing group  To remedy second scenario, ensure that connector using DNS was used to bridge the routing group, and you moved all users in the removed then this administrative or routing group was removed. Therefore, administrative group or routing group to a any mail sent to this routing group was sent in the MSGWIA.X500 valid group. format (the address encapsulation used for non-SMTP addresses); DNS does not recognize this format.

5.3.0 Exchange 2003 can operate without the message transfer agent (MTA). If Check your routing topology. Use the Winroute tool mail was mistakenly sent to the MTA, then Exchange returns this DSN to to ensure that the routes are correctly replicated the sender. This condition is enforced only if you have disabled the MTA between servers and routing groups. service and used specific registry settings to disable the MTA/Store Driver. A default configuration strands the misrouted mail on the MTA queues.

5.7.1 General access denied, sender access denied—The sender of the message Check system privileges and attributes for the does not have the privileges necessary to complete delivery. contact and retry the message. Also, for other Possible causes include: potential known issues, ensure that you are running Exchange 2000 Service Pack 1 or later. In Exchange 2003, check the permissions on the  The sender of the message does not have the privileges necessary distribution list to see if it is a restricted distribution to complete delivery. list.

 You are trying to relay your mail through another Exchange 2000 server, and the server does not permit you to relay. The remote server returns a 5.7.1 code.

 The recipient may have mailbox delivery restrictions enabled (for example, if a recipient's mailbox delivery restriction is configured to receive mail from a distribution list only, non-member's mail is rejected, and this DSN code is returned).

 New in Exchange 2003: An anonymous user tried to send mail to recipients or distribution lists that accept mail from an authenticated SMTP session only.

Moving the X.400 (MTA) and SMTP Queue Directory Locations

Exchange 2003 allows you to change the queue directory locations for SMTP virtual servers and the X.400 protocol.

For detailed instructions, see How to Move X.400 (MTA) Queue Data and How to Move SMTP Queue Data.

Connection Filtering

Exchange Server 2003 supports connection filtering based on block lists. Connection filtering leverages external-based services that list known sources of unsolicited e-mail sources, dial-up user accounts, and servers open for relay (based on IP addresses). Connection filtering compliments third-party content filter products. This feature allows you to check an incoming IP address against a block list provider's list for the categories you want to filter. If a match is found on the block list provider's list, SMTP issues a "550 5.x.x" error in response to the RCPT TO command, and a customized error response is issued to the sender. (The RCPT TO command is the SMTP command that the connecting server issues to identify the intended message recipient.) Furthermore, you can use several connection filters and prioritize the order in which each filter is applied.

With connection filtering, you can do the following:

 Set up connection filtering rules that check with a block list service provider for the following:  IP addresses of known senders of unsolicited commercial e-mail  Servers configured for open relay  Dial-up user account lists  Configure global accept and deny lists. A global accept list is a list of IP addresses from which you will always accept mail. A global deny list is a list of IP addresses from which will always deny mail. You can use global accept and deny lists with or without using a block list service provider.  Configure a recipient address as exception to all connection filtering rules. You can configure a recipient address as an exception to all connection-filtering rules. When mail is sent to this address, it is automatically accepted, even if the sender appears on a block list.

How Connection-Filtering Rules Work

When you create a connection-filtering rule, SMTP uses this rule to perform a DNS lookup to a list provided by a third-party block list service. The connection filter matches each incoming IP address against the third-party block list. The block list provider issues one of two responses:

 host not found Indicates that the IP address is not present on its block list.  127.0.0.x A response status code indicating that a match for the IP address was found in the list of offenders. The x varies, depending on your block list provider.

If the incoming IP address is found on the block list, SMTP returns a 5.x.x error in response to the RCPT TO command (The RCPT TO command is the SMTP command that the connecting server issues to identify the intended message recipient.)

You can customize the response that is returned to the sender. Additionally, because block list providers usually contain different offender categories, you can specify the matches you want to reject. Most block list providers do screening for three types of offenders:

 Sources of unsolicited commercial e-mail. These lists are generated from scanning unsolicited commercial e-mails and adding the source address to the list.  Known open relay servers. These lists are calculated by identifying open relay SMTP servers on the Internet. The most common reason for an open relay server is misconfiguration by the system administrator.  Dial-up user lists. These lists are created from either existing Internet service provider (ISP) lists that contain IP addresses with dial-up access, or from inspection of addresses that indicate a probable dial-up connection. How Block List Providers Match Offending IP Addresses

After you set up your connection filter, when an e-mail message is sent to your organization, Exchange contacts the block list provider. The provider checks for the existence of an A (host) record in its DNS. Exchange queries for this information in a specific format. For example, if the connecting address is 192.168.5.1, and the block list provider's organization is contoso.org, then Exchange queries for the existence of the following record:

. IN A 127. 0.0.x which, in this case, is:

1.5.168.192..contoso.org

If this IP address is found on the provider's list, the provider returns a 127.0.0.x status code that indicates an offending IP address and the type of offense. All block list providers return a response code of 127.0.0.x, where x indicates the type of offense. This number varies, depending on the block list provider.

Understanding Block List Provider Response Codes

As mentioned earlier, if a block list provider finds a match, the provider always returns a status code of 127.0.0.x. The status code is either an explicit return code or a bit mask, which is multi-functional return. If your block list provider returns a value, you can specify which values you want to filter against. However, if your block list provider returns a bit mask, you must understand how a bit mask works to specify the matches you want to filter.

A bit mask is a method used for verifying that a particular bit is set for an entry. A bit mask differs from a traditional mask in that it checks for a specific bit value, as opposed to a subnet mask, which checks for a range of values. Consider the following example.

For each match in its block list, assume a block list provider returns the status codes listed in the following table. Block list status code examples

Category Returned status code

Known source of unsolicited e-mail 127.0.0.3

Dial-up user account 127.0.0.2

Known relay server 127.0.0.4

However, if an IP address is a member of two lists, the block list provider adds the values of the last octet. Therefore, if an IP address is on the list of known relay servers and known sources of unsolicited e-mails, the block list provider returns a status code of 127.0.7, where 7 is the combined values of the last octet returned for known sources of unsolicited commercial e-mail and known relay servers.

To filter against only known sources of unsolicited commercial e-mail, enter a bit mask value of 0.0.0.3; the block list then filters against any of the possible values, in this case, 127.0.0.3, 127.0.0.5, and 127.0.0.7, and 127.0.0.9.

The following table lists the bit mask values associated with each of the example status codes.

Block list status code and corresponding bit mask examples

Category Returned status code Bit mask

Known source of unsolicited e-mail 127.0.0.3 0.0.0.3

Dial-up user account 127.0.0.2 0.0.0.2

Known relay server 127.0.0.4 0.0.0.4

Known relay server and dial-up user account 127.0.0.6 0.0.0.6

For the Known relay server and dial-up user account category, the bit mask 0.0.0.6 returns a match for an IP address only if it appears on both the known relay server and dial-up user account lists. It does not return a match if the IP address appears on only one of the two lists. You cannot use a bit mask to check for a single match in multiple lists.

Note:

A bit mask checks only against a single value. If you set a bit mask value that is returned when an IP address appears on two lists, the mask will match only IP addresses that appear on both lists. If you want to check for an IP address on either of two lists, enter the status codes for these settings.

Specifying Exceptions to the Connection Filter Rule

You can allow message delivery to specific recipients, regardless of whether they appear on a block list. This is useful if you want to allow legitimate organizations to communicate with your administrators by contacting the postmaster account. For example, if a legitimate company has a server inadvertently configured to allow open relaying, e-mail messages from this company to your users would be blocked. However, if you configured connection filtering to allow message delivery to the postmaster account in your organization, then the administrator in the blocked company could send mail your postmaster account to communicate their situation or inquire as to why their mail was rejected.

Enabling Connection Filtering

To enable connection filtering, perform the following steps:

1. Create the connection filter using the Connection Filtering tab on the Message Delivery Properties dialog box. 2. Apply the filter at the SMTP virtual server level. 3. New in SP2: Specify the servers in your internal network that you want to be excluded from connection filtering.

Each of these steps is detailed in the following sections.

Step 1: Configuring Connection Filtering

To configure connection filtering, perform the following tasks:

 Create global accept and deny lists  Create connection filtering rules  Create exceptions to the connection filtering rules.

Creating Global Accept and Deny Lists

Connection filtering allows you to create global accept and deny lists. You can use these lists to always accept or always reject mail sent from specific IP addresses, regardless of whether or not you use a block list service provider. Any IP address that appears on the global accept list is automatically accepted, and any connection filtering rules are bypassed. Similarly, any IP address that appears on the global deny list is automatically rejected.

Entries in the global accept list take precedence over the entries in the global deny list. Exchange checks the global accept list before the global deny list; so, if you wanted to reject connections from a specific subnet and mask, but accept connections from a single IP address within this range, you would:

 Enter the IP address from which you want to accept connections on the global accept list.  Enter the subnet and mask for the range of IP addresses from which you want to reject connections on the global deny list.

When the connecting IP address you added to the global accept list attempts to connect to your Exchange server, Exchange checks the global accept list first. Because Exchange finds a match for this IP address, the connection is accepted, and Exchange performs no additional connection filtering checks.

For detailed instructions, see "How to Create a Global Accept List" and "How to Create a Global Deny List" in the Exchange Server 2003 Transport and Routing Guide.

Creating a Connection Filtering Rule

For detailed instructions about creating a connection filter rule, see "How to Create a Connection Filter" in the Exchange Server 2003 Transport and Routing Guide.

You can create exceptions to the connection filter rule. Specifically, you can allow message delivery to specific recipients (for example, to the postmaster), regardless of whether the connecting IP address is on a block list.

For detailed instructions, see "How to Specify an Exception to a Connection Rule" in the Exchange Server 2003 Transport and Routing Guide.

Step 2: Applying the Connection Filter to the Appropriate SMTP Virtual Servers

After creating the connection filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the connection filter on the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail. Use the following procedure to apply a connection filter to an SMTP virtual server.

For detailed instructions, see "How to Apply a Connection Filter to An SMTP Virtual Server" in the Exchange Server 2003 Transport and Routing Guide.

New in SP2: Step 3: Specifying the Servers to Exclude from Connection Filtering

In Exchange Server 2003 SP2, you can enable connection filtering behind the perimeter of your network. To do this, on the General tab of the Message Delivery Properties dialog box, you specify the IP address of the servers in your internal network that you want to exclude from IP address validation.

You can specify individual IP addresses or groups of IP addresses. You must include all servers in your organization that process incoming SMTP mail. You must also include all servers that route mail to the Sender ID and connection filtering deployment servers. If any of the servers that process SMTP mail are located on the perimeter, you should include all perimeter IP addresses of these servers.

If an IP address on the e-mail message received by the Sender ID or connection filtering deployment server is found on this list, Exchange Server will skip the IP address without running Sender ID and connection filtering validation on it. You can add up to 196 IP addresses to the list.

For information about how to specify the server in your internal network, see "Specify IP Address Configuration Data for Connection Filtering" in the Exchange Server 2003 SP2 online Help.

Inbound Recipient Filtering

With recipient filtering, you can block mail that is destined to all invalid recipients. You can also block mail to any recipients who are specified in a recipient filter list, whether they are valid or invalid.

The recipient filter blocks mail destined to invalid recipients by filtering inbound mail (based on Active Directory lookups) for each intended recipient. You can filter mail based on the following criteria:

 If the recipient does not exist in Active Directory  If the sender does not have the appropriate permissions.

Any incoming mail matching these criteria is rejected, and the SMTP virtual server returns a 550 5.x.x error during the SMTP session. Note:

Exchange only performs Active Directory lookups and blocks invalid recipients for incoming mail destined to a domain for which it is authoritative. This setting is configured in recipient policies.

You can also configure recipient filtering to filter messages sent to specified e-mail address (valid or invalid) within your organization If a message is sent to any of the specified recipients, Exchange returns a 5.x.x level error during the SMTP session.

By default, Exchange accepts mail that is destined for any recipient (invalid or valid) and then sends non-delivery reports (NDRs) for all invalid recipients. Additionally, because unsolicited mail is typically sent from invalid addresses, Exchange attempts to re-deliver NDRs to non-existent senders, thereby expending more resources. If you enable recipient filtering, Exchange no longer expends resources in this manner because invalid recipients are filtered. However, enabling recipient filtering to resolve recipients in Active Directory can potentially allow malicious senders to resolve valid e-mail addresses; this is because SMTP sessions issue different responses for valid and invalid recipients.

Note:

Recipient filter rules apply only to anonymous connections. Authenticated users and Exchange servers bypass these validations.

Enabling Recipient Filtering

To enable recipient filtering, perform the following steps:

1. Create the recipient filter using the Recipient Filtering tab in the Message Delivery Properties dialog box. 2. Apply the filter at the SMTP virtual server level.

Each of these steps is detailed in the following sections.

Step 1: Creating a recipient filter

First, you need to create a recipient filter. For detailed instructions, see "How to Create a Recipient Filter" in the Exchange Server 2003 Transport and Routing Guide.

Step 2: Applying the Recipient Filter to the Appropriate SMTP Virtual Servers

After creating the recipient filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the recipient filter on the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail. Use the following procedure to apply a recipient filter to an SMTP virtual server.

For detailed instructions, see "How to Apply a Recipient Filter to an SMTP Virtual Server" in the Exchange Server 2003 Transport and Routing Guide.

New in SP2: Sender ID Filtering

In Exchange Server 2003 SP2, you can use Sender ID filtering. Sender ID is an e-mail industry initiative that you can use to provide greater protection against unsolicited commercial e-mail (UCE) and phishing schemes. Specifically, the Sender ID framework is a protocol created to help reduce e-mail domain spoofing and to provide greater protection against phishing schemes by verifying an e-mail message's sender. For more information about Sender ID, see the Sender ID Web site.

Configuring Sender ID

The following overview discusses the three steps you must follow to configure Sender ID filtering in Exchange Server 2003 SP2.

1. Specify how the server should handle messages that failed Sender ID validation by selecting one of the following options on the Sender ID Filtering tab of the Message Delivery Properties dialog box.  Select Accept (the Sender ID status will be attached to the message for further anti-spam processing) if you want the Sender ID filter to stamp the validation results to the message and be processed by further anti-spam processing, such as intelligent message filter. This is the default option.  Select Delete (the message will be accepted and then deleted; no NDR will be sent back to the sender) if you want the Sender ID filter to accept the mail and then delete it without sending the non-delivery report (NDR) to the user.  Select Reject (the message will not be accepted; the sending party will be responsible for NDR generation) if you want the Sender ID filter to reject the mail on the SMTP protocol level and issue an NDR message to the user. Specifically, the sending server is responsible for generating an NDR. 2. Specify the IP addresses of the servers in your internal network that you want to be excluded from IP address validation on the General tab of the Message Delivery Properties dialog box. You can specify individual IP addresses or groups of IP addresses. You must include all servers in your Exchange organization that process incoming SMTP mail. You must also include all servers that route mail to the Sender ID and connection filtering deployment servers. If any of the servers that process SMTP mail are located on the perimeter, you should include all perimeter IP addresses of these servers. If an IP address on the e-mail message received by the Sender ID or connection filtering deployment server is found on this list, Exchange Server will skip the IP address without running Sender ID and connection filtering validation on it. You can add up to 196 IP addresses to list. 3. Enable Sender ID on the SMTP virtual servers. After configuring Sender ID filtering options, you must enable Sender ID filtering on the SMTP virtual servers in your Exchange organization. For detailed information about how to perform each of these tasks, see "Configure Sender ID Filtering" in the Exchange Server 2003 SP2 online Help.

New in SP2: Intelligent Message Filtering

In Exchange Server 2003 SP2, intelligent message filtering is installed and ready to use when you install Exchange Server 2003 SP2.

Note:

If the Exchange Server 2003 installation program detects that you are running Intelligent Message Filter, it will prompt you to uninstall it before proceeding with the Exchange Server 2003 SP2 installation.

Intelligent message filtering allows you to block unsolicited commercial e-mail (UCE), also known as spam, on your gateway SMTP virtual servers. Gateway SMTP virtual servers are SMTP virtual servers that accept incoming Internet e-mail.

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site.

Configuring Intelligent Message Filtering

The following overview discusses the steps you must follow to configure Sender ID filtering in Exchange Server 2003 SP2.

1. Create an Intelligent Message Filter using the options on the Intelligent Message Filtering tab of the Message Delivery Properties dialog box. You can set two thresholds that determine how Intelligent Message Filter handles e-mail messages with various SCL ratings: a gateway threshold with an associated action to take on messages above this threshold, and a mailbox store threshold.  If a message has a SCL rating higher than the gateway threshold, Intelligent Message Filter takes the action you have specified. These options include Archive, Delete, No Action, and Reject.  If the message has a SCL rating below the gateway threshold, the message is sent to the Exchange mailbox store of the recipient. At the Exchange mailbox store, if the message has a higher SCL rating than the mailbox store threshold, the mailbox store delivers the message to the user's Junk E-mail folder rather than to the Inbox. 2. Enable Intelligent Message Filter on the SMTP virtual servers. After configuring Intelligent Message Filter options, you must enable Intelligent Message Filter on the SMTP virtual servers in your Exchange organization.

For detailed information about how to perform each of these tasks, see "Configure Intelligent Message Filtering" in the Exchange Server 2003 SP2 online Help.

Updated in SP2: Understanding How Enabled Filters Are Applied

Exchange Server 2003 supports the following filters:

 IP restrictions on a virtual server basis  Connection filtering  Recipient filtering  Sender filtering  Sender ID filtering  Intelligent message filtering

Although connection filtering, recipient filtering, sender filtering, Sender ID filtering, and intelligent message filtering are all configured in Message Delivery Properties, they must be enabled on individual SMTP virtual servers. In contrast, IP restrictions are configured directly on each SMTP virtual server.

This section shows the order in which these filters, when configured and enabled, are checked during an SMTP session. Filtering and IP restrictions are checked in the following manner. Note:

This section has been updated to provide information about the anti-spam process on servers running Exchange Server 2003 SP2. For the purposes of this example, it is assumed that Exchange Server 2003 SP2 is installed on a gateway computer.

1. An SMTP client attempts to connect to the SMTP virtual server. 2. The IP address of the connecting client is checked against the SMTP virtual server's IP restrictions (configured on the Access tab of the SMTP virtual server Properties):  If the connecting IP address is on the list of restricted IPs, the connection is immediately dropped.  If the connecting IP address is not on the list of restricted IPs, the connection is accepted. 3. The SMTP client issues an EHLO or HELO command. 4. The SMTP client issues a MAIL FROM: command, similar to the following: MAIL FROM: [email protected]

5. The IP address of the SMTP client is then checked against the global accept list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).  If the connecting IP address is on the global accept list, the global deny list is not checked. Proceed to Step 7.  If the connecting IP address is not on the list global accept list, Steps 6 and 7 are performed. 6. The IP address of the SMTP client is checked against the global deny list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).  If the IP address of the SMTP client is on the global deny list, the connection is dropped.  If the IP address of the SMTP client is not on the global deny list, the session continues. 7. Sender filtering checks the sender specified in the MAIL FROM command against its list of blocked senders (configured in Exchange System Manager on the Sender Filtering tab in the Message Delivery Properties dialog box).  If the sender appears on the blocked senders list, one of two things happen, depending on how sender filtering is configured: - If sender filtering is configured to drop the connection, the connection is dropped. - If sending filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.  If the sender does not appear on the sender-filtering list, the SMTP virtual server issues a response similar to the following. 250 2.1.0 [email protected] OK

8. The connecting SMTP server issues a RCPT TO command similar to the following: RCPT TO: [email protected]

9. The connection filtering rules check the connecting IP address against any block lists provided by their block list service providers.  If the IP address of the SMTP client is in the accept list, the connection filter rules are bypassed. Proceed to Step 10.  If the IP address of the SMTP client is on a block list service provider's block list, the SMTP virtual server returns an error code and then sends the customized error message configured for the connection filtering rule.  If the IP address of the SMTP client is not on a block list service provider's block list, the session continues. 10. Connection filtering checks to see if the intended recipient is on the connection filtering exception list.  If the recipient is on this list, the communication is accepted, and no other checks are applied at the RCPT TO command. Proceed to Step 13.  If the recipient does not appear on the exception list, the recipient is checked against other filters. 11. If the recipient does not appear on the exception list configured in connection filtering, the recipient is then checked against any blocked recipients configured in recipient filtering.  If the recipient is a blocked recipient, the SMTP virtual server returns an invalid recipient error.  If the recipient is not a blocked recipient, the session continues. 12. If the recipient is not a blocked recipient, then Active Directory is checked to ensure that the intended recipient exists in Active Directory.  If the intended recipient is not a valid recipient that exists in Active Directory, the SMTP virtual server returns an invalid recipient error.  If the recipient is a valid recipient that exists in Active Directory, the session continues. 13. For each additional recipient specified in a RCPT TO command, Steps 10 through 12 are applied. 14. The connecting server then issues a DATA command similar to the following DATA To: Kim Akers From: [email protected] Subject: Mail Message

15. Sender filtering then checks that the From address does not match a blocked sender.  If the sender specified in the DATA command is a blocked sender, one of two things happen: - If sender filtering is configured to drop the connection, then the SMTP virtual server returns a 5.1.0 "Sender Denied" error and drops the connection. - If sending filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.  If the sender specified in the DATA command is not a blocked sender, the message is accepted and queued for delivery. 16. Messages are processed by Sender ID validation. 17. Messages are processed by intelligent message filtering. Improved Ability to Restrict Submissions to an SMTP Virtual Server

In Exchange Server 2003, you can restrict submissions to an SMTP virtual server to a limited number of security principles though the standard Windows 2000 Server or Windows Server 2003 Discretionary Access Control List (DACL). This allows you to specify groups of users who can submit mail to a virtual server.

Note:

Do not restrict submissions on SMTP virtual servers that accept Internet mail.

For detailed instructions, see "How to Restrict Submissions to an SMTP Server Based on a Security Group" in the Exchange Server 2003 Transport and Routing Guide.

Improved Ability to Restrict Relaying on an SMTP Virtual Server

In Exchange 2003, you can restrict relaying to a limited number of security principles though the standard Windows 2000 Discretionary Access Control List (DACL). This allows you to specify groups of users who can relay through a virtual server.

Restricting relaying on virtual servers is useful if you want to allow a group of users to relay mail to the Internet, but deny relay privileges for a different group.

For detailed instructions, see "How to Restrict Relaying Based on a Security Group" in the Exchange Server 2003 Transport and Routing Guide.

How to Create a Connector in a Connecting Forest

This procedure explains how to create a connector in a connecting forest. Procedure To create a connector in a connecting forest 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click Connectors, point to New, and then click SMTP Connector.

3. On the General tab, in the Name box, type a name for the connector.

4. Click Forward all mail through this connector to the following smart hosts, and then type the fully qualified domain or IP address of the receiving bridgehead server.

5. Click Add to select a local bridgehead server and SMTP virtual server to host the connector. The General tab on an SMTP virtual server Properties

6. On the Address Space tab, click Add, select SMTP, and then click OK.

7. In Internet Address Space Properties, type the domain of the forest to which you want to connect, and then click OK. In this example, because the connector is sending from the Adatum forest to the Fabrikam forest, the address space matches the domain for the forest, fabrikam.com.

The Internet Address Space Properties dialog box

How to Run Internet Mail Wizard and Configure Your Server to Send Internet Mail

Xx2005-05-16 Use the following procedure to configure Exchange to send Internet mail.

Procedure To run Internet Mail Wizard and configure your server to send Internet mail 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click your Exchange organization, and then click Internet Mail Wizard. The Welcome page appears.

The Welcome to the Internet Mail Wizard page

3. Click Next.

4. On the Prerequisites for Internet Mail page, read the requirements, ensure that you have completed the tasks listed, and then click Next.

The Prerequisites for Internet Mail page

Note:

Only servers running Exchange 2000 Server and later are available for selection. As stated earlier, you cannot run the wizard on earlier versions of Exchange.

Note:

Your server must satisfy the following conditions:

 You have registered your company's SMTP domain or domains with an Internet registrar.  The Exchange server that you want to configure for Internet e-mail has an Internet IP address assigned to it.  DNS is correctly configured. Your DNS server must have a mail exchanger (MX) record pointing to the Internet IP address of your Exchange server and your DNS server must be able to resolve external Internet names. 5. On the Server Selection page, in the Server list, select the Exchange server you want to configure to send Internet e-mail.

The Server Selection page

As noted on the Server Selection page, you cannot run Internet Mail Wizard if any of the following conditions exist on your server:

 Your server is part of a Microsoft Windows cluster  Your server is part of a Network Load Balancing cluster.  Your server has multiple network interface cards configured with separate networks in which IP routing is enabled between the networks. 6. Click Next.

7. On the Wizard in Progress page, Internet Mail Wizard checks your server configuration to ensure that the server meets all necessary prerequisites. After the wizard checks these conditions, the results display under Report. The Wizard in Progress page

Select the appropriate option:

 If your server meets the necessary conditions, click Next.  If your server does not meet the necessary conditions, review the report, and then click Back to select another server, or click Cancel to exit the wizard. 8. On the Internet E-mail Functions page, you can specify whether you want this server to send Internet e-mail, receive Internet e- mail, or send and receive Internet e-mail. To configure your server to send Internet mail, select the Send Internet e-mail check box.

The Internet E-mail Functions page

Note:

When using Internet Mail Wizard to configure your Exchange server to send outgoing Internet mail, the server cannot already be configured as a bridgehead for any SMTP connectors in the Exchange organization. 9. Click Next.

10. On the Outbound Bridgehead Server page, under SMTP virtual server, ensure that the Exchange server and SMTP virtual server designated as the bridgehead are displayed. By default, the Internet Mail Wizard creates an SMTP connector on this server with the address space that you specify so that all mail destined to this address space is routed through this connector.

The Outbound Bridgehead Server page

11. Click Next.

12. If the Open Relay Configuration page displays, your server is configured to allow open relay. With open relaying, external users can use your server to send unsolicited commercial mail, which may result in other legitimate servers blocking mail from your

Note:

This page displays only if your SMTP virtual server is configured to allow open relay. If your SMTP virtual server does not allow open relay, this page does not display. Exchange server. 13. The Open Relay Configuration page

14. Click Disable open relay to secure your server, and then click Next.

15. On the Outbound Mail Configuration page, select one of the following options to configure how you want Exchange to send outgoing Internet mail:

 Click Use domain name system (DNS) to send mail if you want Exchange to use DNS to resolve all Internet addresses and then send mail.  Click Yes if your DNS server can resolve Internet addresses.  Click No if your DNS server cannot resolve Internet (external addresses). The wizard then guides you through the process of configuring an external DNS server that your SMTP virtual server will use to resolve external addresses.  Click Route all mail through the following smart host if you want to send mail to a smart host that assumes responsibility for DNS resolution and mail delivery. Then, in the Host name or IP address of the smart host box, type either a fully qualified domain name or an IP address for the smart host. The Outbound Mail Configuration page

16. Click Next.

17. Select one of the following options:

 If you configured Exchange to use a smart host to send outbound mail, proceed to Step 19.  If you configured Exchange to use DNS for outbound mail and your DNS server can resolve Internet address, proceed to Step 19.  If you configured Exchange to use DNS and the DNS server Exchange uses cannot resolve Internet addresses, proceed to Step 17. 18. On the External Domain Name System (DNS) page, configure your SMTP virtual server to use an external DNS server: Click Add, and then, in Enter an IP address, type the IP address of the external DNS server you want to use.

Important:

The external DNS server must have the ability to resolve external or Internet addresses. 19. The External Domain System (DNS) page

20. Click Next.

21. On the Outbound SMTP Domain Restrictions page, select from the following options to specify whether you want to send Internet e-mail to all external addresses or restrict delivery to a specified set of domains:

 Click Allow delivery to all e-mail domains to allow outbound Internet mail for all external domains.  Click Restrict delivery to the following e-mail domains(s) to restrict outbound Internet mail to specific domains, and then click Add to enter the domain to which you want to allow mail. If you want to enter a specific domain, type the domain name, for example example.com. If you want to allow e-mail to all domains with a specific extension, for example.edu, type *.edu.

Important:

Do not proceed the domain name with the at sign (@). 22. The Outbound SMTP Domain Restrictions page

23. Click Next.

24. The Configuration Summary page displays the configuration options you selected, as well as the location of the Internet mail log file where the configuration settings will be saved. Review these options carefully.

The Configuration Summary page

25. Click Next to start the configuration.

26. When the Completing the Internet Mail Wizard pagedisplays, select the View detailed report when this wizard closes check

Note:

Internet Mail Wizard writes the log file to the My Documents folder of the user running the wizard. The exact location displays on the Completing the Internet Mail Wizard page. box to view the log file, and then click Finish.

27. The Completing the Internet Mail Wizard page

How to Run Internet Mail Wizard and Configure Your Server to Receive Internet Mail

Use the following procedure to configure Exchange to receive Internet mail.

Procedure To run Internet Mail Wizard and configure your server to receive Internet mail 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click your Exchange organization, and click Internet Mail Wizard. The Welcome to the Internet Mail Wizard page appears. The Welcome to the Internet Mail Wizard page

3. Click Next.

4. On the Prerequisites for Internet Mail page, read the requirements, ensure that you have completed the tasks listed, and then click Next.

The Prerequisites for Internet Mail page

Your server must satisfy the following conditions:

Note:

Only servers running Exchange 2000 Server and later are available for selection. As stated earlier, you cannot run the wizard on earlier versions of Exchange.

5. On the Server Selection page, under Server, select the Exchange server you want to configure to receive Internet e-mail.

The Server Selection page

As noted on the Server Selection page, you cannot run Internet Mail Wizard if any of the following conditions exist on your server:

 Your server is part of a Windows cluster  Your server is part of a Network Load Balancing cluster.  Your server has multiple network interface cards configured with separate networks in which IP routing is enabled between the networks. 6. Click Next.

Select the appropriate option:

 If your server meets the necessary conditions, click Next.  If your server does not meet the necessary conditions, review the report, and then click Back to select another server, or click Cancel to exit the wizard. 8. On the Internet E-mail Functions page, you can specify whether you want this server to send Internet e-mail, receive Internet e- mail, or send and receive Internet e-mail. To configure your server to receive Internet mail, select the Receive Internet e-mail check box.

The Internet Mail Functions page

Note:

To receive incoming Internet e-mail, the server must have only one SMTP virtual server with a default IP address of "All Unassigned" and an assigned TCP port of 25. The default IP address is the address on which the SMTP virtual server listens on port 25 for incoming SMTP connections. A value of "All Unassigned" means that the SMTP virtual server listens on any of the available IP addresses. If more than one SMTP virtual server exists on the Exchange server, or if the IP information or TCP port assignments are different, the wizard will not continue. However, you can restore the Exchange server to its default configuration and rerun the wizard, or you can use Exchange System Manager to configure Exchange manually. 9. Click Next.

10. To accept Internet mail, your SMTP virtual server must allow anonymous access. If your server is not configured to allow anonymous access, the Anonymous Access Configuration page displays. If this page displays, leave the default option, Enable anonymous

Note:

This page displays only if your SMTP virtual server is not configured to allow anonymous access. If your SMTP virtual server allows anonymous access, this page does not display. access, so your server can accept incoming mail from the Internet.

11. The Anonymous Access Configuration page

12. Click Next.

The address displayed in bold is the primary SMTP address. This address displays as the return address on your users' outgoing mail.

The SMTP domains for which you want to receive Internet mail are configured in Exchange System Manager in Recipient Policies. You must have a recipient policy configured for every SMTP domain for which you want to accept Internet mail, and Exchange must be authoritative for this domain. If you created multiple recipient policies in Exchange System Manager, you cannot use the wizard to create additional recipient policies. In this case, if you need to add or modify recipient policies, you must use Exchange System Manager. The SMTP Domains for Inbound Mail page

Note:

This page displays only if your SMTP virtual server is configured to allow open relay. If your SMTP virtual server does not allow open relay, this page does not display.

14. Select from the following options:

 If all the SMTP domains for which you want to accept incoming Internet mail are listed, click Next.  If you have not modified your recipient policies and an SMTP domain for which you want to receive Internet mail does not display, click Add, and then add the proper SMTP domain. Click Set as From Address if you want this address to display as your user's return address in their outgoing e-mails.  If you created multiple recipient policies in Exchange System Manager and an SMTP domain for which you want to receive Internet mail does not exist, exit the wizard, and then use Exchange System Manager create or edit a recipient policy for the SMTP domain and make it authoritative. To ensure an SMTP domain is authoritative, on your recipient policy, edit or create the SMTP address, and then click the This Exchange Organization is responsible for all mail delivery to this address check box in SMTP Address Properties. 15. If the Open Relay Configuration page displays, your server is configured to allow open relay. With open relaying, external users can use your server to send unsolicited commercial mail, which may result in other legitimate servers blocking mail from your Exchange server. 16. The Open Relay Configuration page

17. Click Disable open relay to secure your server, and then click Next.

18. The Configuration Summary page displays the configuration options you selected, as well as the location of the Internet mail log file where the configuration settings will be saved. Review these options carefully.

The Configuration Summary page

19. Click Next to start the configuration.

20. When the Completing the Internet Mail Wizard page displays, select the View detailed report when this wizard closes check box to view the log file, and then click Finish.

Note: Internet Mail Wizard writes the log file to the My Documents folder of the user running the wizard. The exact location displays on the Completing the Internet Mail Wizard page.

21. The Completing the Internet Mail Wizard page

How to Run Internet Mail Wizard and Configure Your Server to Send and Receive Internet Mail

Use the following procedure to configure an Exchange server to send and receive Internet mail.

Procedure To run the Internet Mail Wizard and configure your server to send and receive Internet mail 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click your Exchange organization, and then click Internet Mail Wizard. The Welcome to the Internet Mail Wizard page appears. The Welcome to the Internet Mail Wizard page

3. Click Next.

4. On the Prerequisites for Internet Mail page, read the requirements, ensure that you have completed the tasks listed, and then click Next.

The Prerequisites for Internet Mail page

Your server must satisfy the following conditions:

Note: For information about how to configure DNS, see Microsoft Knowledge Base article 315982 "HOW TO: Configure DNS Records for Your Web Site

Note:

Only servers running Exchange 2000 Server and later are available for selection. As stated earlier, you cannot run the wizard on earlier versions of Exchange. in Windows 2000" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=315982).

5. On the Server Selection page, under Server, select the Exchange server that you want to configure to send and receive Internet e- mail.

The Server Selection page

As noted on the Server Selection page, you cannot run Internet Mail Wizard if any of the following conditions exist on your server:

Select the appropriate option:

 If your server meets the necessary conditions, click Next.  If your server does not meet the necessary requirements, review the report, and then click Back to select another server, or click Cancel to exit the wizard. 8. On the Internet E-mail Functions page, you can specify whether you want the server to send Internet e-mail, receive Internet e- mail, or send and receive Internet e-mail. To configure your server to send and receive e-mail, select both the Receive Internet e- mail and Send Internet e-mail check boxes. The wizard creates an SMTP connector so you can send mail to all external address or to specified addresses.

Important:

To receive incoming Internet e-mail, the server must have only one SMTP virtual server with a default IP address of "All Unassigned" and an assigned TCP port of 25. The default IP address is the address on which the SMTP virtual server listens on port 25 for incoming SMTP connections. A value of "All Unassigned" means that the SMTP virtual server listens on any of the available IP addresses. If more than one SMTP virtual server exists on the Exchange server, or if the IP information or the TCP port assignments are different, the wizard will not continue. However, you can restore the Exchange server to its default configuration and rerun the wizard, or you can use Exchange System Manager to configure Exchange manually.

Note:

To send outgoing Internet e-mail, the Exchange server cannot already be configured as a bridgehead for any SMTP connectors in the Exchange organization. The Internet E-mail Functions page

9. Click Next.

Note:

This page displays only if your SMTP virtual server is not configured to allow anonymous access. If your SMTP virtual server allows anonymous access, this page does not display.

11. The Anonymous Access Configuration page

12. Click Next.

13. On the SMTP Domains for Inbound Mail page, under SMTP domains, all the existing domains in your Exchange organization are displayed. Ensure that all the SMTP domains for which you want to accept Internet mail are displayed. The address displayed in bold is the primary SMTP address and this address displays as the return address on your users' outgoing mail.

If you have created multiple recipient policies in Exchange System Manager, you cannot use the wizard to create additional recipient policies. In this case, if you need to add or modify your recipient policies, you must use Exchange System Manager.

The SMTP Domains for Inbound Mail page

14. Select from the following options:

 If all the SMTP domains for which you want to accept incoming Internet mail are listed, click Next.  If you have not modified your recipient policies and an SMTP domain for which you want to receive Internet mail is not displayed, click Add,and then add the proper SMTP domain. Click Set as From Address if you want this address to display as your user's return address in their outgoing e-mails.  If you created multiple recipient policies in Exchange System Manager and an SMTP domain for which you want to receive Internet mail does not exist, exit the wizard, and then use Exchange System Manager to create or edit a recipient policy for the SMTP domain and make it authoritative. To ensure an SMTP domain is authoritative, on your recipient policy, edit or create the SMTP address, and then click the This Exchange Organization is responsible for all mail delivery to this address check box in SMTP Address Properties. 15. On the Outbound Bridgehead Server page, ensure that the Exchange server and SMTP virtual server designated as the bridgehead are displayed. Internet Mail Wizard will create an SMTP connector on this server with the address space of *, so that all mail destined to Internet addresses is routed through this connector. The Outbound Bridgehead Server page

16. Click Next.

17. If the Open Relay Configuration page displays, your server is configured to allow open relay. With open relaying, external users can use your server to send unsolicited commercial mail, which may result in other legitimate servers blocking mail from your Exchange server.

Note:

This page displays only if your SMTP virtual server is configured to allow open relay. If your SMTP virtual server does not allow open relay, this page does not display.

18. The Open Relay Configuration page

19. Click Disable open relay to secure your server, and then click Next

20. On the Outbound Mail Configuration page, select one of the following options to configure how you want Exchange to send outgoing Internet mail:  Click Use domain name system (DNS) to send mail if you want Exchange to use DNS to resolve all Internet addresses and then send mail.  Click Yes if your DNS server can resolve Internet addresses.  Click No if your DNS server cannot resolve Internet (external addresses). The wizard then guides you through the process of configuring an external DNS server that your SMTP virtual server will use to resolve external addresses.  Click Route all mail through the following smart host if you want to send mail to a smart host that assumes responsibility for DNS resolution and mail delivery. Then, in the Host name or IP address of the smart host box, type either a fully qualified domain name or an IP address for the smart host.

The Outbound Mail Configuration page

21. Click Next.

22. Select one of the following options:

 If you configured Exchange to use a smart host to send outbound mail proceed to the Step 23.  If you configured Exchange to use DNS for outbound mail and your DNS server can resolve Internet address, proceed to Step 23.  If you configured Exchange to use DNS, and the DNS server Exchange uses cannot resolve Internet addresses, proceed to Step 21. 23. On the External Domain Name System (DNS) page, configure your SMTP virtual server to use an external DNS server: Click Add, and then, in Enter an IP address, type the IP address of the external DNS server you want to use.

Important:

The external DNS server must have the ability to resolve external or Internet addresses. 24. The External Domain Name System (DNS) page

25. Click Next.

26. On the Outbound SMTP Domain Restrictions page, select from the following options to specify whether you want to send Internet e-mail to all external addresses or restrict delivery to a specified set of domains:

Important:

Do not proceed the domain name with the at sign (@). 27. The Outbound SMTP Domain Restrictions page

28. Click Next.

29. The Configuration Summary page displays the configuration options you selected, as well as the location of the Internet mail log file where the configuration settings will be saved. Review these options carefully.

The Configuration Summary page

30. Click Next to start the configuration.

31. When the Completing the Internet Mail Wizard page displays, select the View detailed report when this wizard closes check box to view the log file, and then click Finish.

Note:

Internet Mail Wizard writes the log file to the My Documents folder of the user running the wizard. The exact location displays on the Completing the Internet Mail Wizard page. 32. The Completing the Internet Mail Wizard page

How to Run Internet Mail Wizard on a Dual-Homed Server

Use the following procedure to configure a dual-homed Exchange server with two SMTP virtual servers to send and receive Internet mail.

Procedure To run the Internet Mail Wizard on a dual-homed server 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click your Exchange organization, and then click Internet Mail Wizard. The Welcome to the Internet Mail Wizard page appears. The Welcome to the Internet Mail Wizard page

3. Click Next.

4. On the Prerequisites for Internet Mail page, read the requirements, ensure that you have performed the tasks listed, and then click Next.

The Prerequisites for Internet Mail page

Your server must satisfy the following conditions:

For information about how to configure DNS, see Microsoft Knowledge Base article 315982, "HOW TO: Configure DNS Records for Your Web Site in Windows 2000" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=315982). 5. On the Server Selection page, under Server, select the Exchange server that you want to configure to send and receive Internet e- mail.

The Server Selection page

Note: Only servers running Exchange 2000 Server and later are available for selection. As stated earlier, you cannot run the wizard on earlier versions of Exchange.

As noted on the Server Selection page, you cannot run Internet Mail Wizard if any of the following conditions exist on your server:

Select the appropriate option:

 If your server meets the necessary conditions, click Next.  If your server does not meet the necessary requirements, review the report, and then click Back to select another server, or click Cancel to exit the wizard. 8. On the Internet E-mail Functions page, you can specify whether you want this server to send Internet e-mail, receive Internet e- mail, or send and receive Internet e-mail. To configure your server to send and receive e-mail, select both the Receive Internet e- mail and Send Internet e-mail check boxes. The wizard creates an SMTP connector so you can send mail to all external address or to specified addresses.

The Internet E-mail Functions page

Important:

To receive incoming Internet e-mail, the server must have only one SMTP virtual server with a default IP address of "All Unassigned" and an assigned TCP port of 25. The default IP address is the address on which the SMTP virtual server listens on port 25 for incoming SMTP connections. A value of "All Unassigned" means that the SMTP virtual server listens on any of the available IP addresses. If more than one SMTP virtual server exists on the Exchange server, or if the IP information or the TCP port assignments are different, the wizard will not continue. However, you can restore the Exchange server to its default configuration and rerun the wizard, or you can use Exchange System Manager to configure Exchange manually.

Note:

To send outgoing Internet e-mail, the Exchange server cannot already be configured as a bridgehead for any SMTP connectors in the Exchange organization.

9. Click Next.

10. On the Configure Your Server page, under Configure the dual-homed Internet gateway topology, click Yes to configure a dual-homed gateway server. Internet Mail Wizard then configures one SMTP virtual server to accept incoming mail using the Internet IP address and a second SMTP virtual server to send mail using an intranet IP address.

Note:

To configure a server as a dual-homed gateway, your server must have static IP addresses assigned to each network interface card. Otherwise, the Yes button is unavailable.

11. The Configure Your Server page

12. Click Next.

13. On the Create two SMTP virtual servers page, create two SMTP virtual servers and assign each one the proper IP address. The Create Two SMTP virtual servers page

Select the correct IP addresses for each SMTP virtual server:

 In the Internet SMTP virtual server IP list, assign an Internet IP address to the SMTP virtual server that accepts incoming Internet e-mail. To send mail to your users, external SMTP servers must be able to connect to your SMTP virtual server that accepts incoming Internet mail; therefore you must assign an Internet IP address to your SMTP virtual server.  In the Default SMTP virtual server IP (Intranet IP) list, assign an intranet IP to the SMTP virtual server that sends Internet mail. You must assign an intranet IP address to this server to allow only your authenticated internal users to send Internet mail using the SMTP virtual server. 14. Click Next

15. On the SMTP Domains for Inbound Mail page, under SMTP domains, all the existing recipient policies for SMTP addresses configured in your Exchange organization are displayed. Ensure that all the SMTP domains for which you want to accept Internet mail are displayed.

The address displayed in bold is the primary SMTP address, and this address displays as the return address on your users' outgoing mail.

If you created multiple recipient policies in Exchange System Manager, you cannot use the wizard to create additional recipient policies. In this case, if you need to add or modify your recipient policies, you must use Exchange System Manager. The SMTP Domains for Inbound Mail page

16. Select from the following options:

 If all the SMTP domains for which you want to want to accept incoming Internet mail are listed, click Next.  If you have not modified your recipient policies and an SMTP domain for which you want to receive Internet mail is not displayed, click Add,and then add the proper SMTP domain. Click Set as From Address if you want this address to display as your user's return address in their outgoing e-mails.  If you created multiple recipient policies in Exchange System Manager and an SMTP domain for which you want to receive Internet mail does not exist, exit the wizard, and then create or edit a recipient policy for the SMTP domain and make it authoritative. To ensure an SMTP domain is authoritative, on your recipient policy, edit or create the SMTP address, and then click the This Exchange Organization is responsible for all mail delivery to this address check box in SMTP Address Properties. 17. On the Outbound Bridgehead Server page, under SMTP virtual server, ensure that the Exchange server and SMTP virtual server designated as the bridgehead are displayed. By default, the Internet Mail Wizard creates an SMTP connector on this server with an address space of *, so that all mail destined to Internet addresses is routed through this connector. The Outbound Bridgehead Server page

18. If the Open Relay Configuration page displays, your server is configured to allow open relay. With open relaying, external users can use your server to send unsolicited commercial mail, which may result in other legitimate servers blocking mail from your Exchange server.

Note:

This page displays only if your SMTP virtual server is configured to allow open relay. If your SMTP virtual server does not allow open relay, this page does not display.

19. The Open Relay Configuration page

20. Click Disable open relay to secure your server, and then click Next.

21. On the Outbound Mail Configuration page, select one of the following options to configure how you want Exchange to send outgoing Internet mail:  Click Use domain name system (DNS) to send mail if you want Exchange to use DNS to resolve all Internet addresses and then send mail.  Click Yes if your DNS server can resolve Internet addresses.  Click No if your DNS server cannot resolve Internet (external addresses). The wizard then guides you through the process of configuring an external DNS server that your SMTP virtual server will use to resolve external addresses.  Click Route all mail through the following smart host if you want to send mail to a smart host that assumes responsibility for DNS resolution and mail delivery. Then, in the Host name or IP address of the smart host box, type either a fully qualified domain name or an IP address for the smart host.

The Outbound Mail Configuration page

22. Click Next.

23. Select one of the following options:

 If you configured Exchange to use a smart host to send outbound mail proceed to Step 24.  If you configured Exchange to use DNS for outbound mail, and your DNS server can resolve Internet address, proceed to Step 24.  If you configured Exchange to use DNS, and the DNS server Exchange uses cannot resolve Internet addresses, proceed to Step 22. 24. On the External Domain Name System (DNS) page, configure your SMTP virtual server to use an external DNS server: Click Add, and then, in Enter an IP address, type the IP address of the external DNS server you want to use.

Important:

The external DNS server must have the ability to resolve external or Internet addresses. 25. The External Domain Name System (DNS) page

26. Click Next.

27. On the Outbound SMTP Domain Restrictions page, select from the following options to specify whether you want to send Internet e-mail to all external addresses or restrict delivery to a specified set of domains:

Important:

Do not proceed the domain name with the at sign (@). 28. The Outbound SMTP Domain Restrictions page

29. Click Next.

30. The Configuration Summary page displays the configuration options you selected, as well as the location of the Internet mail log file where the configuration settings will be saved. Review these options carefully.

The Configuration Summary page

31. Click Next to start the configuration.

32. When the Completing the Internet Mail Wizard page displays, select the View detailed report when this wizard closes check box to view the log file, and then click Finish.

Note:

Internet Mail Wizard writes the log file to the My Documents folder of the user running the wizard. The exact location displays on the Completing the Internet Mail Wizard page. 33. The Completing the Internet Mail Wizard page

How to Configure Diagnostic Logging for DSN

Use the following procedure to configure diagnostic logging for DSN. Procedure To configure diagnostic logging for DSN 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. 2. In the console tree, expand Servers. 3. Right-click the server you want, and then click Properties. 4. In Properties, click the Diagnostics Logging tab. 5. Under Services, click MSExchangeTransport. 6. Under Categories, click NDR. 7. Under Logging level, click None, Minimum, Medium, or Maximum. Click Maximum for troubleshooting purposes.

How to Move X.400 (MTA) Queue Data

Use this procedure to move X.400 queue data.. Procedure To move X.400 (MTA) queue data 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. 2. Expand Servers, expand the server you want, expand Protocols, right-click X.400, and then click Properties. 3. In X.400 Properties, under Message Queue Directory, click Modify. The X.400 Properties dialog box

4. In Message Queue Directory, type the path where you want to store X.400 queue data.

The Message Queue Directory dialog box

Note: When you modify the location of the X.400 queue directory, you are modifying only the MTA database path and moving only the database files (.dat files); you are not moving any of the run files or the run directory. The database files are the core files required for starting the MTA, queue files, and message files.

How to Move SMTP Queue Data

Use this procedure to move SMTP queue data. Procedure To move SMTP queue data 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. 2. Expand Servers, expand the server you want, expand Protocols, and then expand SMTP. 3. Right-click the SMTP virtual server whose queue directory you want to move, and then click Properties. 4. In Properties, click the Messages tab. The Messages tab

5. On the Messages tab, under Queue directory, click Browse, and then select a new location for the queue data.

Storage Features of Exchange Server 2003

Microsoft® Exchange Server 2003 includes many improvements the Exchange store. In general, these improvements focus on making disaster recovery operations easier and faster and on streamlining internal processes such as public folder replication.

Specifically, the improvements include the following:

 Support for the new Volume Shadow Copy service, which is available as part of the Microsoft Windows Server™ 2003 backup API.  A new type of storage group (the Recovery Storage Group) provides a temporary location for restored mailbox data. After restoring the mailbox data to the Recovery Storage Group, you can then merge the data you need with the original mailbox store, whether that means restoring the entire mailbox store or a few individual mailboxes.  The Microsoft Mailbox Merge Wizard (Exmerge) is now available for download at the Exchange Downloads website (http://go.microsoft.com/fwlink/?LinkId=25097).  Public folder replication processes are overhauled and streamlined for more efficient use of bandwidth.  The Exchange Virus Scanning Application Programming Interface (VSAPI) is enhanced and expanded.  New in SP2: You can now configure settings related to the database size limits of Exchange Server databases. For example, you can configure the maximum database size, the threshold at which a warning event is logged, and the time of day at which database sizes are evaluated.

Shadow Copy Backup

Exchange Server 2003 supports the new backup infrastructure implemented in Windows Server 2003. Backup programs (including Microsoft Windows Backup) can use either the existing Microsoft Windows® 2000 backup and restore APIs, or the new APIs. The new APIs use the Windows Volume Shadow Copy service to create a shadow copy (also known as a snapshot) of the disk at the beginning of the backup process. Exchange then uses the shadow copy (rather than the working disk) to create the actual backup, therefore normal operation can continue. This method offers the following advantages over previous methods:

 A backup of a volume is produced. This backup reflects the state of that volume at the instant the backup started, even if the data changes while the backup is in progress. All the backup data is internally consistent and reflects the state of the volume at a single point in time.  Applications and services are notified that a backup is about to occur. The services and applications can then prepare for the backup by cleaning up on-disk structures and by flushing caches and log files.

Using Shadow Copy Backup

The Exchange API provides support for shadow copy backups.

You can still use the Windows Server 2003 Backup utility to back up Exchange Server 2003 databases (mailbox stores and public folder stores); however, this method uses the existing API's for non-shadow copy backups. Windows Server 2003 Backup supports backing up your Windows file system using the Volume Shadow Copy service, but it does not support the Exchange Volume Shadow Copy service APIs. To use the new shadow copy APIs to back up databases, you must use a third-party solution.

Recovery Storage Group

To provide greater flexibility when restoring mailboxes and mailbox stores, Exchange 2003 provides a Recovery Storage Group feature. The Recovery Storage Group is a specialized storage group that can exist alongside the regular storage groups in Exchange (even if the server already has four regular storage groups). You can restore mailbox stores from any regular storage group that meets the following conditions:

 The server housing the storage group is running Exchange 2000 SP3 or later.  The server housing the storage group is in the same Administrative group as the server housing the Recovery Storage Group.  If you are restoring multiple mailbox stores simultaneously, they must all be from a single storage group.

After you restore a mailbox store to the Recovery Storage Group, move the recovered mailbox data from the Recovery Storage Group to the regular storage group. With this method, you can recover an entire mailbox store (all of the database information, including the log data) or just a single mailbox. Mailboxes in the Recovery Storage Group are disconnected and are not accessible to users with mail clients.

Note:

You can only use the Recovery Storage Group to recover mailbox stores, not public folder stores.

Using a Recovery Storage Group

The following procedures represent a simple restore scenario; these procedures assume that you have already backed up your storage groups.

Before you begin these procedures, ensure that you are logged in with an account such as Backup Operators that has Receive As and Send As permissions on all of the Exchange mailboxes. If these permissions are denied, the restore process does not complete.

If you restore mailbox stores without creating a Recovery Storage Group, the data is restored directly to the original mailbox stores, as in previous versions of Exchange.

The process of using a Recovery Storage Group to restore mailbox data consists of three main steps:

1. Set up the Recovery Storage Group. 2. Restore a mailbox store to the Recovery Storage Group. 3. Merge the recovered mailbox data with regular user mailboxes.

For detailed instructions, see "How to Set Up a Recovery Storage Group" in Using Exchange Server 2003 Recovery Storage Groups.

Note:

When merging data, folder permissions and inbox rules are not included. Filtering what gets merged is also not supported. If you need this functionality, you can use Microsoft Exchange Mailbox Merge Wizard (Exmerge) instead of the recover data task. The Exmerge utility is available for download at the Exchange Downloads website (http://go.microsoft.com/fwlink/?LinkId=25097). After you restore the appropriate mailbox store to the Recovery Storage Group, start Exmerge and follow the instructions in the wizard to move the mailbox data.

For detailed information about overriding the Recovery Storage Group, see How to Set the Recovery Storage Group Override Registry Key.

Microsoft Exchange Mailbox Merge Wizard

Previously, the Microsoft Exchange Mailbox Merge Wizard (Exmerge) was available as an Exchange Resource Kit tool. Now, the wizard is available for download at the Exchange Downloads Web site. With this wizard, you can move data between identical mailboxes that exist in different mailbox stores; for example, to restore a mailbox from a backup, restore the mailbox store to the Recovery Storage Group, and then use the wizard to merge the restored mailbox data with the original mailbox. For detailed information about how to perform this procedure, see "Using a Recovery Storage Group" earlier in this topic. Improved Public Folder Store Replication

In Exchange 2003, the public folder replication algorithms have been refined for greater efficiency when backfilling. ("Backfilling" is when a server determines that it has not received all of the updates for a replicated folder and must retrieve the missing updates from another server.) To select a server (or servers) to use as a backfill source, Exchange first creates a list of all of the servers that have some portion of the necessary content, and then sorts the list as follows:

1. Sorts the list according to the lowest transport cost (servers in the same site have priority over servers in remote sites). 2. For servers with the same transport cost, sorts again according to newest Exchange version. In previous versions of Exchange, servers running newer Exchange versions are selected over servers running older versions, regardless of the transport cost. For example, a server in a remote site running Exchange 2000 would be selected over a local server running Microsoft Exchange Server version 5.5. In Exchange 2003, transport cost now has greater importance in the selection criteria. 3. For servers with the same transport cost and Exchange version, sort again according to the largest number of necessary changes available on the server. In previous versions of Exchange, a server holding all of the necessary updates is chosen over a server holding only some of the updates, regardless of transport cost. In Exchange 2003, this preference has been changed so that if some updates are available on a server with a lower transport cost, that server is selected to backfill those updates, even if the rest of the updates must be obtained from other (higher-cost) servers.

As an example of how the new behavior differs from that of all Exchange 2000 Server versions, consider an Exchange 5.5 deployment of several sites (with multiple servers per site, all replicating public folders) that must be upgraded to Exchange 2003. Add one Exchange 2003 server to each site. In each site, the Exchange 2003 server will backfill its public folders from the local Exchange 5.5 servers, rather than search for a newer server in one of the remote sites.

Improved Virus Scanning API

Exchange 2000 SP1 delivered the Virus Scanning API (VSAPI) version 2.0, which provided improved support for scanning Internet content and reporting on the sender and receiver of the virus. Exchange 2003 improves the VSAPI by allowing antivirus vendor products to run on Exchange servers that do not have resident Exchange mailboxes (for example, gateway servers or bridgehead servers). The Exchange 2003 VSAPI version 2.5 allows antivirus vendor products to delete an infected message and send a notification message to the sender of the infected message. The vendor products can also create additional virus status messages to allow clients to indicate the infection status of a particular message. For more information about antivirus applications that use the new VSAPI features, contact your antivirus manufacturer.

New in SP2: Database Size Limit Configuration and Management

With Exchange Server 2003 Service Pack 2 (SP2), you can now customize settings related to database size limits to meet the needs of your organization. SP2 adds the following primary features.

 You can configure a logical database size limit for each of your Exchange databases. The logical size of the database equals the physical size of the .edb file and the .stm file minus the logical free space in each. The limitation of this feature depends on the version of Exchange Server 2003 you are running:  Exchange Server 2003 Standard Edition By default, the size limit of each database on a server running Exchange Server 2003 Standard Edition is 16 GB. After you install Exchange Server 2003 SP2, the default size limit for each Exchange database is 18 GB. Additionally, you can configure database size limits of up to 75 GB for each database on servers running Exchange Server 2003 SP2.  Exchange Server 2003 Enterprise Edition By default, the size limit of each database on a server running Exchange Server 2003 Enterprise Edition is 8,000 GB. This size is generally a theoretical limit. The actual limit of an Exchange database is based on your server hardware and on the hardware of your storage subsystem. After you install Exchange Server 2003 SP2, you can customize the database size limit to a value up to 8,000 GB.  A warning event is logged in the Application log when a server running Exchange Server approaches the database limit that you configured for a specific database. You can specify the threshold at which you want to be notified. By default, the threshold for logging a warning event is when 90 percent of the maximum logical database size is consumed.  An error event is logged in the Application log when a server running Exchange Server reaches the database limit that you configured for a specific database. Additionally, Exchange immediately takes the database that exceeded the database limit offline. To temporarily restore e-mail service for your users on the database that reached the configured limit, you can restart the database. However, the database will be dismounted on each daily check that determines that the logical size limit for the database has been exceeded.  You can specify the time each day that Exchange Server checks database size limits based on the limits you have configured. By default, Exchange Server checks the size of each Exchange database at 5 hours after midnight (05:00).

For information about how to configure storage limits, see the following:

 The topic Database Size Limit Configuration and Management in the Exchange Technical Reference.  The topic "Configure Database Size Limits" in the Exchange Server 2003 SP2 online Help.

Disaster Recovery Planning Considerations

If you change the size limit of your Exchange databases, you may want to re-evaluate your Exchange database backup and restore plan. Specifically, if you increase the size limit of the Exchange databases, be sure to test your backup and recovery operations using the new database size limits to make sure that you can still meet your service level agreements. For example, if the previous size of a mailbox store was 15 GB and you were able to meet your service level agreement by recovering the data in less than 8 hours, you may no longer be able to recover the database that quickly if you increase the size of a mailbox store to 20 GB or larger.

For information about service level agreements, see "Establishing a Service Level Agreement" in "Setting Availability Goals" in the Exchange 2003 High Availability Guide.

For information about how to configure storage limits, see the following:

 The topic Database Size Limit Configuration and Management in the Exchange Technical Reference.  The topic "Configure Database Size Limits" in the Exchange Server 2003 SP2 online Help.

How to Set the Recovery Storage Group Override Registry Key

If you restore mailbox stores without creating a Recovery Storage Group, the data will be restored directly to the original mailbox stores, as in previous versions of Exchange. If you already created a Recovery Storage Group, you can restore directly to the original mailbox stores if you set the override registry key.

Note:

Procedure To set the Recovery Storage Group Override registry key 1. Start Registry editor (regedit). 2. In Registry Editor, navigate to the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 3. Create a new DWORD value Recovery SG Override = 1. After this key has been set, you can restore mailbox stores to their original locations, even though the Recovery Storage Group exists.

Development Features of Exchange Server 2003

Microsoft® Exchange Server 2003 contains important changes and additions for developers. You can find complete information about these changes in the Microsoft Exchange Server 2003 Software Development Kit (SDK). In addition, the following sections briefly describe the major changes.

New Development Technologies

The following are new development technologies for Exchange Server 2003.

The Windows Management Instrumentation (WMI) providers and classes that ship with Exchange 2000 Server provide operational status about Exchange servers, queues, links, and so on, and are intended for use in applications that monitor Exchange.

Exchange Server 2003 includes many new and improved WMI classes that are designed for use in Exchange management scripts and operator consoles. The new object classes support managing Exchange stores, public folders, user mailboxes, connectors, queues, links, and so on. The following table lists the new WMI classes.

New WMI Classes

WMI class Changes

ExchangeClusterResource Class No change.

ExchangeConnectorState Class No change.

ExchangeLink Class No change. Additional capabilities are provided in the new Exchange_Link class.

ExchangeQueue Class No change. Additional capabilities are provided in the new Exchange_Queue class. ExchangeServerState Class No change. Additional capabilities are provided in the new Exchange_Server class.

Exchange_DSAccessDC Class No changes.

Exchange_FolderTree Class New class.

Exchange_Link Class New class.

Exchange_Logon Class New class.

Exchange_Mailbox Class New class.

Exchange_MessageTrackingEntry Class Additional message tracking entry type values were added to provide more detailed tracking of internal message-transfer events.

Exchange_PublicFolder Class New class.

Exchange_Queue Class New class.

Exchange_QueueCacheReloadEvent New class. Class

Exchange_QueueData Class New class.

Exchange_QueuedMessage Class New class.

Exchange_QueuedSMTPMessage Class New class.

Exchange_QueuedX400Message Class New class.

Exchange_QueueSMTPVirtualServer New class. Class

Exchange_QueueVirtualServer Class New class.

Exchange_QueueX400VirtualServer New class. Class

Exchange_ScheduleInterval Class New class.

Exchange_Server Class New class.

Exchange_SMTPLink Class New class.

Exchange_SMTPQueue Class New class.

Exchange_X400Link Class New class.

Exchange_X400Queue Class New class.

Managed Wrappers for SMTP and Transport Sinks

You can find the code for the managed wrappers, along with the accompanying technical article, Writing Managed Sinks for SMTP and Transport Events, at http://go.microsoft.com/fwlink/?LinkId=16141.

Supported Development Technologies

The following development technologies are supported on Exchange Server 2003.

Data Access Methods

 CDO for Exchange 2000 (CDOEX). CDOEX cannot be used remotely.  ADO access using the Exchange OLEDB provider (ExOLEDB). ExOLEDB cannot be used remotely.  ADO access using Microsoft Data and Internet Publishing Provider (MSDAIPP). MSDAIPP can be used anywhere that it is installed, except for on an Exchange Server 2003 computer. MSDAIPP is not supported for use on the Exchange server itself.  CDO for Exchange Management (CDOEXM). CDOEXM can only be used on a computer running the full installation of Exchange Server 2003 or a computer running the Admin-only installation of Exchange Server 2003.  CDO 1.2x, both server and client.  HTTP and WebDAV.  MAPI (extended MAPI). For deprecated MAPI technologies, see "Deprecated MAPI Technologies" later in this topic.

Events and Notifications

 Exchange Server version 5.5 event agent service. This service is supported, but disabled by default in Exchange Server 2003.  ExOLEDB store events.  Transport events.  MAPI notifications.  WebDAV notifications.  Incremental Change Synchronization (ICS).

Application Technologies

 Exchange Web Forms.  Exchange 2000 Server workflow.  Exchange 5.5 routing engine. Samples provided in the Exchange 5.5 Exchange Development Kit (EDK) are not supported.

Monitoring

 Exchange 2000 Server WMI providers.

Specialized Programs

 Virus Scanning API (VSAPI) version 2.5.  Backup and Restore API.

Developing .NET Applications for Exchange Server 2003

For information about what is supported and not supported for developing .NET applications for Exchange Server 2003, see Microsoft Knowledge Base article 813349, "Support Policy for Microsoft Exchange APIs with .NET Framework Applications."

Active Directory Classes and Attributes

The installer for Exchange Server 2003 makes numerous changes to the Microsoft Active Directory® directory service classes and attributes to support the new features of Exchange Server 2003. For information about these changes, see the Exchange Server 2003 SDK.

Deprecated Exchange Development Technologies

The following Exchange 2000 Server application development-related technologies and features are removed and are not supported in Exchange Server 2003:

 Microsoft FrontPage® Extensions for Web Storage System Forms  Exchange Instant Messaging.  Programmatic access to the Exchange store using the M: drive via custom code.  SQL Create Index command.  Exchange store schema properties for versioning.  MSDAIPP on the computer running Exchange Server 2003. Remote access continues to be supported.

Deprecated MAPI Technologies

The following MAPI technologies, which formerly shipped with Exchange 2000 Server, are not available in Exchange Server 2003:

Simple MAPI

Simple MAPI is a wrapper around 12 high-level Extended MAPI functions that enable a client application to send, address, receive, and reply to messages. On the client, Simple MAPI is used by Microsoft Office to send mail directly from the application. It is only intended for use in the Microsoft Windows environment and offers limited functionality. Anything that can be done with Simple MAPI can also be done with Extended MAPI.

Common Messaging Calls (CMC)

CMC is a wrapper around 10 Extended MAPI functions and was created to abstract the complexities of MAPI and to create an API standard that was supported across platforms. The CMC API was developed in conjunction with the X.400 API Association (XAPIA) standards organization and is only accessible to C/C++ client developers. Anything that can be done with CMC can also be done with Extended MAPI.

CDOHTML Also referred to as CDO 1.2.1 Rendering, this API exposes a set of objects that can be used by Internet Information Services (IIS) to render CDO 1.2x objects and properties into HTML output. CDO 1.2.1 Rendering (CDOHTML.DLL) was intended for server-side use only.

Deployment Features of Exchange Server 2003

Whether you are installing a new Exchange organization or upgrading an existing organization, Microsoft® Exchange Server 2003 introduces several new features that make deployment easier. Aside from summarizing these new features (including the new deployment tools and setup features), this chapter provides information about required prerequisites for deploying Exchange 2003. Furthermore, you will learn how to perform the basic steps necessary for deploying or upgrading to Exchange Server 2003. For more information about deploying Exchange 2003 in your organization, see the Exchange Server 2003 Deployment Guide.

New Exchange 2003 Deployment Features

To help you successfully deploy Exchange in your organization, Exchange 2003 provides the following new or improved features (each of these features is discussed later in this section):

 Exchange Server 2003 Deployment Tools  Active Directory Connector (ADC) Tools  Microsoft Exchange Public Folder Migration Tool  Exchange 2003 Setup improvements  Running Exchange System Manager from computers running Microsoft Windows®

Along with these new or improved features, Exchange 2003 also takes advantage of Microsoft Windows Server™ 2003 improvements, such as Microsoft Active Directory® directory service and memory allocation enhancements.

Exchange Server Deployment Tools

Exchange Server 2003 is designed to coexist with Microsoft Exchange 2000 Server and Microsoft Exchange Server version 5.5. Establishing coexistence between Exchange 2003 and Exchange 2000 is fairly straightforward, simplified by the fact that both Exchange 2000 and Exchange 2003 rely on the Microsoft Active Directory directory service for directory services. However, Exchange 5.5 contains its own directory service, which means that you must synchronize the Exchange 5.5 directory with Active Directory, and then ensure that objects continue to properly replicate between the two directories.

A new Exchange 2003 feature, the Exchange Server Deployment Tools, significantly eases the process of upgrading from Exchange 5.5 to Exchange Server 2003. The Exchange Server Deployment Tools consist of a series of tools and documentation that lead you through the following process:

1. Planning your deployment 2. Preparing Active Directory by using ForestPrep and DomainPrep 3. Installing Active Directory Connector (ADC) and running ADC Tools (described in the next section) 4. Installing Exchange 5. Completing deployment and moving mailboxes and public folders

The tools, which you can run directly from the documentation, check such things as naming consistency, permissions conversion, and directory replication. Because some of the Exchange Server Deployment Tools run automatically during Exchange setup, you may not be able to install Exchange unless these tools have been run successfully. By running the tools in advance, you can identify and correct problems before you run Setup.

New in SP1: Exchange Site Consolidation Tools

Exchange 2003 Service Pack 1 (SP1) provides several features and deployment tools that allow you to move Exchange out of remote sites and consolidate data onto an Exchange 2003 server in a central site.

During Exchange 2003 deployment, you may want to consolidate your Exchange services by moving Exchange content from several remote sites to one central site. If you are running Exchange in native mode, there are no special considerations when consolidating sites; you can follow the standard process for consolidating Exchange 2000 administrative groups. However, if you are running Exchange in mixed mode (meaning that coexistence is established between Exchange Server version 5.5 and Exchange 2000 or Exchange 2003), use the Exchange Deployment Tools to help you migrate mailboxes, distribution lists, custom recipients (contacts), and public folders to the central site.

ADC Tools

The Active Directory Connector (ADC) management console now contains an ADC Tools option. ADC Tools is a collection of wizards and tools that help you set up connection agreements. Specifically, ADC Tools scans your current Active Directory and Exchange 5.5 directory and organization, and then automatically creates the recommended connection agreements. The following wizards are included in ADC Tools. Resource Mailbox Wizard

This wizard identifies Active Directory accounts that match more than one Exchange 5.5 mailbox. Using this wizard, you can match the appropriate primary mailbox to the Active Directory account and stamp other mailboxes with the NTDSNoMatch attribute, which designates the mailboxes as resource mailboxes. You can either make these changes online or export a comma-separated value (.csv) file that you can update and import into the Exchange 5.5 directory.

Connection Agreement Wizard

This wizard recommends public folder connection agreements and recipient connection agreements based on your Exchange 5.5 directory and Active Directory configuration. You can review the list of recommended connection agreements and select those you want the wizard to create.

The Exchange Server Deployment Tools lead you through the process of installing Active Directory Connector and running ADC Tools.

Microsoft Exchange Public Folder Migration Tool

The Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new tool that allows you to migrate both system folders and public folders to the new server. You can use the tool to create system folder and public folder replicas on the new server and, after the folders have replicated, remove replicas from the source server. Unlike Exchange 5.5, you do not need to set a home server for a public folder in Exchange Server 2003. Any replica acts as the primary replica of the data it contains, and any public folder server can be removed from the replica list.

To determine how many system folders or public folders need to be replicated, you can use the Microsoft Exchange Public Folder Migration Tool to generate a report before you run the tool. To determine whether the folders replicated successfully, you can generate the same report after you run the tool. For detailed instructions, see "How to Run the Public Folder Migration (PFMigrate) Tool" in the Exchange Server 2003 Deployment Guide.

Note:

After you run pfMigrate, only the hierarchy of the system folders and public folders is migrated immediately. You must wait for replication to occur before the contents of the system folders and public folders are migrated. Depending on the size and number of system and public folders, as well as your network speed, replication could take a considerable amount of time. New in SP1: Exchange 2003 Migration Wizard

Exchange 2003 SP1 Migration Wizard provides several new feature enhancements. Migration Wizard now supports merging mailboxes for Exchange migrations and includes support for the Profile Update Tool, which runs on a user's computer and updates their Microsoft Office Outlook® profile after a cross-site or cross organization move. Mailbox access control lists (ACLs) or delegate permissions are now preserved during a cross-forest move.

Exchange Server 2003 Setup Improvements

The following new Exchange 2003 Setup features make it easier for you to install and upgrade Exchange.

Identical schema files in ADC and Exchange

In Exchange 2000, ADC schema files were a subset of the Exchange 2000 core schema files. In Exchange 2003, the schema files that are imported during the upgrade of Active Directory Connector are identical to the core Exchange Server 2003 schema; therefore, you only need to update the schema once.

Exchange Setup does not require full organization permissions

In Exchange 2000, the user account that was used to run Setup was required to have Exchange Full Administrator rights at the organization level. In Exchange 2003, although a user who has Exchange Full administrator rights at the organization level must install the first server in a domain, you can now install additional servers if you have Exchange Full Administrator rights at the administrative group level.

Exchange Setup no longer contacts the schema FSMO role

In Exchange 2000, the Setup or Update program contacted the schema Flexible Single Master Operations (FSMO) role each time it ran. In Exchange Server 2003, Setup does not attempt to contact the schema FSMO role.

ChooseDC Switch in Setup

Exchange 2003 Setup includes the new /ChooseDC switch. You can enter the fully qualified domain name of an Active Directory domain controller to force Setup to read and write all data from the specified domain controller. When installing multiple Exchange 2003 servers simultaneously, forcing each server to communicate with the same Active Directory domain controller ensures that replication latencies do not interfere with Setup and cause installation failures.

Default permissions at the organization level are only stamped once Exchange 2003 Setup stamps default permissions on the Exchange Organization object once (during the first server installation or upgrade) and does not re-stamp permissions during subsequent installations. Previously, Exchange 2000 Setup re-stamped Exchange Organization permissions during each server installation. This action overwrote any custom changes to the permissions structure; for example, if you allowed all users to create top-level public folders, these permissions were removed.

Warning message appears if Exchange Groups are moved, deleted, or renamed

Exchange 2003 Setup ensures that the Exchange Domain Servers and Exchange Enterprise Servers groups are intact. If the administrator moves, deletes, or renames these groups, Setup stops, and a warning message appears.

Permissions to access mailboxes

Exchange 2003 Setup locks down security on the database objects; therefore Exchange administrators cannot open other user's mailboxes.

Outlook Mobile Access and Microsoft Exchange Server ActiveSync® components installed by Setup By default, Exchange 2003 includes support for mobile devices. The services that enable these devices are called Outlook Mobile Access and Exchange ActiveSync. Previously, to use these services, you had to install Microsoft Mobile Information Server. Now, the built-in mobile device support in Exchange 2003 supersedes the Mobile Information Server product.

Note:

Outlook Mobile Access is part of the typical Setup and is therefore installed on all servers. This component also requires the .NET Framework to be installed. Automatic installation of required Windows Server 2003 services on Microsoft Windows 2000

If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup automatically installs and enables .NET Framework and ASP.NET.

Automatic configuration of Internet Information Services (IIS) 6.0

In Windows Server 2003, IIS 6.0 introduces a new "worker process isolation mode," which offers greater reliability and security to Web servers. Worker process isolation mode ensures that all of the authentication, authorization, Web application processes, and ISAPI extensions that are associated with a particular application are isolated from all other applications. To take advantage of these benefits, when you install Exchange Server 2003 on Windows Server 2003, Exchange Setup automatically sets IIS 6.0 to worker process isolation mode. Exchange Setup also enables certain ISAPI extensions. By default, during Windows Server 2003 installation, ISAPI extensions are not allowed to load. However, Exchange 2003 requires certain ISAPI extensions for features such as Microsoft Outlook Web Access, WebDAV, and Exchange Web Forms; therefore, Exchange 2003 enables the required ISAPI extensions during setup. No action is necessary; Exchange Setup automatically configures the ISAPI extensions. The IsapiRestrictionList metabase key controls the ISAPI extension behavior. Exchange Setup sets the metabase key appropriately so that the ISAPI extensions can load; however, if the key is modified after Exchange is installed, certain parts of Exchange may not function correctly.

Automatic IIS 6.0 Configuration during Windows 2000 to Windows Server 2003 upgrade

If you install Exchange 2003 on Windows 2000 and subsequently upgrade to Windows Server 2003, Exchange System Attendant automatically sets the IIS 6.0 mode to worker process isolation mode. Event Viewer will contain an event indicating that this mode change has occurred. After the upgrade, you may find that some of the ISAPI extensions for other applications do not function properly in worker process isolation mode. Although you can set the IIS 6.0 mode to "IIS 5 isolation mode" to ensure compatibility with your ISAPI extensions, it is recommended that you continue to run IIS 6.0 in worker process isolation mode; Exchange 2003 features such as Outlook Web Access, WebDAV, and Web forms, will not work in IIS 5 isolation mode.

New in SP1: Support for Device Update 4 (DU4)

Exchange 2003 SP1 now includes support for additional world-wide devices. DU4 updates the list of supported mobile devices for Outlook Mobile Access and ensures that the mobile devices on the list have been tested and work well with Outlook Mobile Access.

New in SP1: Security Enhancement for Outlook Web Access

Exchange Setup adds new file extensions to the Outlook Web Access Level1 and Level2 block/force "safe lists" to prevent the running of unsafe code within the browser for certain MIME types. This update provides a list of known content types that are allowed to start within the browser.

Installing Exchange System Management Tools Only

To administer Exchange servers from a computer running Windows XP, Windows Server 2003, or Windows 2000 Server SP3, you can use Exchange Setup to install only Microsoft Exchange System Management Tools. For detailed instructions, see "How to install the Exchange System Management Tools" in the Exchange Server 2003 Administration Guide. Note:

If you have not installed an Exchange 2003 server in your organization, you must first run ForestPrep. ForestPrep extends the Active Directory schema to include Exchange-specific classes and attributes and creates the container object for the Exchange organization in Active Directory.

You must ensure that the computer meets the following requirements:

 The computer is running Windows XP, Windows Server 2003, Windows 2000 Professional, or Windows 2000 Server SP3.  The computer name does not contain unsupported characters.  The language version matches any previous installation of Exchange 2000 System Management Tools (except for upgrades from English to Korean, Traditional Chinese, or Simplified Chinese).

Also, depending on the version of Windows that is running on the computer, you will need to install the required services.

Windows Server 2003 Benefits

Exchange Server 2003 takes advantage of the following new Windows Server 2003 features, which greatly improve administration and performance:

Active Directory Improvements

Exchange Server 2003 benefits from the following improvements to Active Directory in Windows Server 2003:

 Reduced traffic between replicas  Ability to create a branch office replica from CD  Ability to roll back Active Directory changes Memory Allocation

Exchange Server 2003 benefits from an improved memory allocator in Windows Server 2003, which decreases the likelihood of running into situations that result in Virtual Machine (VM) fragmentation. In addition, Exchange customers who have more than 1 GB of memory no longer need to purchase the Advanced Server SKU, which previously supported the /3GB switch.

Prerequisites

Before you install or upgrade to Exchange Server 2003, ensure that your network and servers meet the prerequisites described in this section.

Hardware Requirements

The following are the minimum hardware requirements for computers running Exchange Server 2003:

 Intel Pentium or compatible 133 MHz or faster processor  256 MB of RAM recommended minimum; 128 MB supported minimum  500 MB of available disk space on the drive on which you install Exchange  200 MB of available disk space on the system drive  CD-ROM drive  VGA or higher-resolution monitor

File Format Requirements

To install Exchange Server 2003, disk partitions must be formatted for NTFS and not FAT. This requirement applies to the following:

 System partition  Partition that stores Exchange binaries  Partitions containing transaction log files  Partitions containing database files  Partitions containing other Exchange files

Operating System Requirements

Exchange Server 2003 is supported on the following operating systems:  Windows 2000 Service Pack 3 (SP3) or later  Windows Server 2003

Windows 2000 Server

If you intend to install Exchange Server 2003 on a server running Windows 2000, you must download and install Windows 2000 SP3 or later. Otherwise, the Exchange Server 2003 Setup program will stop the installation.

Windows 2000 SP3 or later is also a prerequisite for running the Exchange Server 2003 Active Directory Connector.

For more information about Windows 2000 service packs, see the Windows 2000 Service Packs Web site.

Upgrading the Operating Systems

If you plan to upgrade your Exchange 2000 servers running Windows 2000 SP3 or later to Windows Server 2003, you must first upgrade those servers to Exchange 2003. This upgrade sequence is required because Exchange 2000 is not supported on Windows Server 2003.

Active Directory

Exchange 2003 Setup must be able to contact at least one Active Directory server running Windows 2000 SP3 or later, or Windows Server 2003 within the local Active Directory Site. Domain controllers and global catalog servers must be running Windows 2000 SP3 or later or Windows Server 2003 for Exchange Server 2003 to recognize them.

Permissions

In Exchange 2000, the user account that was used to run Setup was required to have Exchange Full Administrator rights at the organization level. In Exchange Server 2003, although a user with Exchange Full administrator rights at the organization level must install the first server in a domain, you can now install additional servers if you have Exchange Full Administrator rights at the administrative group level.

Although this change allows for a more decentralized administrative model, there are still instances where higher-level permissions are required. A domain administrator with the appropriate privileges must manually add the machine account for the server on which you plan to install Exchange Server 2003 to the Exchange Domain Servers group. In addition, an administrator with Exchange Full Administrator rights at the organization level must still perform the following installations and upgrades:

 The first Exchange 2003 server in the organization.  The first Exchange 2003 server in an Active Directory domain.  Exchange 2000 servers acting as bridgehead servers for Directory Replication Connectors.  Exchange 2003 servers with Site Replication Services (both installation and removal).  The first instance of a Lotus Notes or Novell GroupWise connector.

Note:

The Exchange administrator roles in Exchange Server 2003 are equivalent to those in Exchange 2000. For example, anyone to whom you have delegated Exchange Full Administrator permissions in Exchange 2000 can install and fully administer Exchange 2003 servers.

In addition, if you are upgrading an Exchange 5.5 organization to Exchange Server 2003, you are no longer required to be an Exchange 5.5 Administrator; this is because the option to join an existing Exchange 5.5 organization occurs during Setup instead of during ForestPrep.

The following table lists the permissions required to run ForestPrep and DomainPrep and to install Exchange 2003.

Permission requirements for Setup tasks

Task Required permissions or roles

Run ForestPrep for the first time in the forest  Enterprise Administrator (updates the schema)  Schema Administrator

 Domain Administrator

 Local Machine Administrator

Run ForestPrep thereafter  Exchange Full Administrator at the organization level

 Local Machine Administrator

Run DomainPrep  Domain Administrator  Local Machine Administrator

Install Exchange Server 2003 on the first  Full Exchange Administrator at the organization level server in a domain  Exchange 5.5 Administrator under the organization, site, and configuration nodes (if installing into an Exchange 5.5 site)

 Local Machine Administrator

Install Exchange Server 2003 on additional  Full Exchange Administrator at the administrative group level servers in the domain  Exchange 5.5 Site Administrator (if installing into an Exchange 5.5 site)

 Local Machine Administrator

Install ADC  Domain Administrator

 Enterprise Administrator

 Local Machine Administrator

Install Exchange Server 2003 on a server with  Exchange Full Administrator at the organization level SRS enabled  Local Machine Administrator

Upgrading Front-End Servers

You must upgrade all front-end servers in an Administrative Group before you can upgrade or install Exchange Server 2003 on any other servers in the Administrative Group. Setup ensures that front-end servers are upgraded before back-end servers, such as bridgehead servers, public folder servers, and mailbox servers. Otherwise, Setup stops.

Note:

Exchange 2003 servers are compatible with Exchange 2000. Therefore, users can access information that is located on Exchange 2000 servers through an Exchange 2003 front-end server.

In addition, ensure that the required services are running before you upgrade. For Exchange 2003 Setup to run, you must install and enable the following services:

 Network News Transfer Protocol (NNTP) service (NntpSvc)  Simple Mail Transfer Protocol (SMTP) service (SMTPSVC)  World Wide Web Publishing Service (W3SVC)  IIS Admin Service (IISADMIN)

If the following services are disabled, Setup still runs; however, Setup enables these services automatically:

 Microsoft Exchange MTA Stacks service (MSExchangeMTA)  Microsoft Exchange IMAP4 service (IMAP4SVC)  Microsoft Exchange POP3 service (POP3SVC)  Microsoft Exchange Information Store service (MSExchangeIS)

Upgrading Active Directory Connector

You must upgrade all versions of Active Directory Connector (ADC) in the organization to the version provided with Exchange Server 2003. Setup retrieves information about the ADC versions that are running in the organization. If all ADC versions have been upgraded to the Exchange 2003 version, Setup will proceed. However, if older versions of ADC exist, Setup will stop and identify the servers that are running the older ADC versions.

Removing Mobile Information Server Components

Required Components for Mobility Support The Outlook Mobile Access component included with Exchange Server 2003 requires .NET Framework. Because the Outlook Mobile Access component is part of the typical server installation, you must install .NET Framework on the server before running Setup.

Removing Instant Messaging, Chat, ccMail, MSMail, and Key Management Service Components

The Instant Messaging service, Chat service, Key Management Service, MSMail connector, and ccMail connector components are not supplied with Exchange Server 2003. If you want to upgrade an existing Exchange 2000 server to Exchange 2003, and one or more of these components are installed, you must use Exchange 2003 Setup to remove the components before upgrading.

Note:

If you want to retain these services in your organization, you should not upgrade the Exchange 2000 servers running these components. Instead, you should install Exchange Server 2003 on other servers in your organization.

Third-Party Software

As part of your planning, you should ensure that all third-party software you want to use is compatible with Exchange Server 2003. Specifically, you should determine whether any compatibility issues could result from the following new Exchange 2003 features:

 Exchange-aware Antivirus Software New features have been added to the Exchange Virus Scanning Application Programming Interface (VSAPI) in Exchange 2003.  Exchange-aware Backup and Restore Software New features have been added to Backup (such as Restore Groups and Snapshot) in Exchange 2003.  Exchange-aware Enterprise Management New features and WMI providers have been added in Exchange 2003.

Installing Exchange 2003 or Upgrading from Exchange 2000

After planning your installation or upgrade and ensuring that your environment meets all of the prerequisites listed in this chapter, you can run the Exchange Server Deployment Tools to install Exchange 2003 on a new server or upgrade an Exchange 2000 server. The Exchange Server Deployment Tools consist of tools and documentation that lead you through the entire installation or upgrade process, including running ForestPrep and DomainPrep and ensuring that all of the required tools and services are installed and run properly.

Important:

For information about upgrading from an Exchange 5.5 organization, see "Upgrading from Exchange 5.5 to Exchange 2003" later in this topic.

For detailed instructions, see "How to Start the Exchange Server Deployment Tools" in the Exchange Server 2003 Deployment Guide. After you complete the Exchange Server Deployment Tools, Exchange 2003 is installed on the server.

Upgrading from Exchange 5.5 to Exchange 2003

Unlike Exchange 2000 servers, Exchange 5.5 servers cannot be directly upgraded to Exchange 2003. However, you can join a new Exchange 2003 server to an existing Exchange 5.5 organization. As part of this upgrade process, you must set up Active Directory Connector (ADC) and ensure that objects replicate properly between the Exchange 5.5 directory and Active Directory. To simplify this process, use the Exchange Server Deployment Tools, which consists of tools and documentation that lead you through the entire upgrade process, including running ForestPrep and DomainPrep, installing ADC, creating connection agreements, and installing Exchange 2003.

The Exchange Server Deployment Tools are a prerequisite for Setup when you are joining a server to an Exchange 5.5 organization. When you choose to join an existing Exchange 5.5 organization, Setup checks Active Directory for markers that indicate that the deployment tools have been run.

You can use the Exchange Server Deployment Tools to ensure that all of the required tools have been run. First, install the Exchange 2003 version of ADC. Then start the Exchange Server Deployment Tools. For detailed instructions, see "How to Start the Exchange Server Deployment Tools" in the Exchange Server 2003 Deployment Guide. After you complete the Exchange Server Deployment Tools, Active Directory Connector is set up, and Exchange 2003 is installed on the server.

How to Remove Mobile Information Server Components from a Server

If you previously installed the Microsoft Mobile Information Server Exchange Event Sink component on an Exchange 2000 server, you must remove the component before you can install or upgrade to Exchange Server 2003. If you want to retain Mobile Information Server functionality, do not upgrade the Exchange 2000 servers that are running Mobile Information Server. Instead, upgrade to Exchange 2003 on other servers in your organization. This procedure outlines how to remove Mobile Information Server components from a server. Procedure To remove Mobile Information Server components from a server 1. Verify that you have the proper permissions to uninstall Mobile Information Server. To uninstall Mobile Information Server, you must be a member of the Microsoft Mobility Admins group, as well as a member of the local Administrators group on the computer from which you are uninstalling Mobile Information Server.

2. On the server with Mobile Information Server installed, click Start, click Settings, and then click Control Panel.

3. Double-click Add/Remove Programs.

4. On the Change or Remove Programs screen, select Mobile Information Server.

5. Click Remove.

6. Click Yes to confirm that you want to remove Mobile Information Server.

7. On the warning about wireless enabled users, click Yes.

Schema Changes in Exchange Server 2003

For information about the changes Exchange Server 2003 made to the Active Directory Schema, see the Microsoft Exchange Server 2003 Software Development Kit Web site or download the Exchange 2003 SDK Documentation and Samples.

Microsoft Exchange Server 2003 Software Development Kit

Microsoft® Exchange Server 2003 provides a rich environment for messaging and collaborative application development. By closely integrating with Windows Server® 2003 and core services such as the Active Directory® directory service and Microsoft Internet Information Services (IIS), Exchange Server 2003 simplifies application development, deployment, and management, and helps ensure a faster return on the development investment. For more information about Exchange Server 2003, see the Microsoft Exchange Server Web site.

This is the "final" release of the Microsoft Exchange Server 2003 Software Development Kit (SDK). We do not plan to update the documentation or samples unless the product APIs change significantly. Developers are encouraged to use the APIs and features of Microsoft Exchange Server 2007, which is the successor to Exchange Server 2003. Microsoft and the Exchange Developer Documentation Group thank you for your ongoing support and comments on our work in this SDK. We look forward to working even more closely with you on the Exchange Server 2007 SDK.

This documentation contains the following sections to assist developers in building applications for Exchange Server 2003:

 What's New This topic summarizes the changes that have been made to this release of the Exchange Server 2003 SDK.  Introduction This section discusses collaborative applications — what they are, and what you need to know to develop them.  Architecture This section provides information about the Windows Server 2003 platform technologies that Exchange Server 2003 integrates with and uses, and describes the programming technologies that are available for use in Exchange Server 2003 applications.  Environment and Tools This section describes how to configure your environment for developing Exchange Server 2003 applications, and the tools and other developer resources that are supplemental to the Exchange Server 2003 SDK.  Tasks This section uses sample code to explain the programming tasks that are used to build custom applications for Exchange Server 2003.  Solutions This section provides sample applications that demonstrate how to develop collaborative Web applications for Exchange Server 2003.  Reference This section contains information about object models and APIs to use when building applications for Exchange Server 2003.

3. Planning and Architecture Design your Microsoft Exchange Server 2003 system with the aid of the resources in this topic.

 Planning a Microsoft Exchange Server 2003 Messaging System  Exchange Server 2003 Server Consolidation  Exchange 2003 High Availability Guide  Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000 Server  Exchange Server Client Access Guide  Windows Server System Reference Architecture

For more information about what's been updated recently in the Exchange Server 2003 documentation, see Exchange Server Documentation Updates.

Planning a Microsoft Exchange Server 2003 Messaging System

In addition to evaluation and design recommendations, these topics describe improvements in Microsoft® Exchange Server 2003, Microsoft Windows Server™ 2003, and Microsoft Office Outlook® 2003. These topics also identify network infrastructure, hardware, Active Directory® directory service, and administrative concerns. Reading these topics will help you design a highly reliable and consistently available messaging system, including storage technologies, clustering, server tuning, and client configuration.

The following sections discuss planning an Exchange Server 2003 messaging system from an IT Professional perspective:

 Introduction: Planning an Exchange Server 2003 Messaging System  Exchange 2003 Design Considerations  Planning Your Active Directory and Administrative Model  Planning Your Deployment Path  Planning for Site Consolidation  Planning Your Exchange Infrastructure  Optimizing Memory Usage for Exchange Server 2003

Introduction: Planning an Exchange Server 2003 Messaging System

A growing number of businesses today regard messaging systems as mission-critical systems. For this reason, companies place strict reliability and availability requirements on their e-mail systems. Equally important is the heightened demand for new messaging system features. An increasingly mobile work force and more geographically dispersed businesses mean that user requirements are continually evolving. All of these factors place demands on Information Technology managers and system architects, who are charged with designing highly reliable and consistently available messaging systems that meet users' needs.

To design a successful Microsoft® Exchange Server 2003 messaging system, you need to understand the capabilities and limitations of the software and hardware upon which you build your messaging system. Whether you are developing a new Exchange Server 2003 messaging system or upgrading from a previous Exchange implementation, you need to balance the limitations of your network infrastructure with the capabilities of your messaging system, operating system, and user software.

These topics help you with these challenges by guiding you through the process of evaluating your existing environment and pointing out the technical considerations that influence your design choices. Recommendations are given for designing an Exchange 2003 messaging system. Other topics also describe improvements in Exchange 2003, Microsoft Windows Server™ 2003 and Microsoft Office Outlook® 2003, and it identifies network infrastructure, hardware, Microsoft Active Directory® directory service, and administrative concerns. In addition, these topics discuss the considerations that help you design a highly reliable and consistently available messaging system, including storage technologies, clustering, server tuning, and configuration of client computers.

What Will You Learn from These Topics?

These topics provide detailed answers to the following questions:

 What factors do I need to consider when designing or upgrading an Exchange 2003 messaging system?  How do new features in Exchange 2003, Windows Server 2003, and Outlook 2003 affect the way I design the system?  How do I integrate Exchange with my Active Directory infrastructure?  What are the recommendations for public folder and free/busy folder placement?  How do I use site consolidation tools to move Exchange data from servers in remote sites to a server in a central site?  What are the recommendations for routing design and server placement? How can I optimize memory usage in my servers?  Based on my network infrastructure and requirements, to what extent can I centralize my servers? What are the scaling capabilities and limits of Exchange 2003?  How can I maximize the reliability and availability of the messaging system?

Who Should Read These Topics?

Information technology professionals who are responsible for planning and designing Exchange messaging systems for their companies should read these topics. Such professionals may be in the following roles:

 System architects—those people who are responsible for designing the overall server infrastructure, developing server deployment strategies and policies, and contributing to networking connectivity design.  Information technology managers—those people who are the technical decision makers and who manage the Information Technology staff responsible for the infrastructure, the desktop and server deployment, and server administration and operations across sites.  Systems administrators—those people who are responsible for planning and deploying technology across Microsoft Windows® servers and evaluating and recommending new technology solutions.  Messaging administrators—those people who are responsible for implementing and managing organizational messaging.

What Technologies Do These Topics Cover?

These topics discuss messaging system and related technologies at a high level to point out features and limitations. For detailed information about specific technologies, you should refer to Windows, Outlook, and Exchange product documentation. The technologies that these topics cover include the following:

 Microsoft Exchange Mobile Synchronization and Browse  Microsoft Office Outlook Web Access 2003  Microsoft Outlook 2003 Cached Exchange Mode  Microsoft Windows Server Active Directory forest and domain partitioning  Microsoft Windows Clustering  Redundant array of independent disks (RAID)  Remote procedure call (RPC) over HTTP (remote procedure call over HTTP)  Storage area networks  Volume Shadow Copy service

For More Information The following technical articles, resource kits, and Microsoft Knowledge Base articles provide more information:

Technical Articles Deploying Microsoft Exchange 2000 Server Clusters (http://go.microsoft.com/fwlink/?LinkId=6271) Storage Solutions for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=1715) Best Practice Active Directory Design for Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=17837) Best Practice Active Directory Design for Managing Windows Networks (http://go.microsoft.com/fwlink/?LinkId=18348) Design Considerations for Delegation of Administration in Active Directory (http://go.microsoft.com/fwlink/?LinkId=18349) Deploying Microsoft Exchange 2000 Server Clusters (http://go.microsoft.com/fwlink/?LinkId=14578) Disaster Recovery for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=18350) Migrating Mailboxes from Microsoft Exchange Server Version 5.5 to Exchange 2000 Server (http://go.microsoft.com/fwlink/?linkid=18351) Monitoring Exchange 2000 with Microsoft Operations Manager 2000 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=326236) Multiple Forest Considerations in Windows 2000 and Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=21177) Microsoft Identity Integration Server 2003 Scenarios (http://go.microsoft.com/fwlink/?LinkId=21270)

Tools Exchange Server 2003 Tools and Updates (http://go.microsoft.com/fwlink/?LinkId=21316) Exchange Server Best Practices Analyzer Tool (http://go.microsoft.com/fwlink/?LinkId=34707) Exchange Stress and Performance Tool (ESP)—Build 5531.0 (http://go.microsoft.com/fwlink/?LinkId=1709) Microsoft Exchange Server 2003 Load Simulator (LoadSim) (http://go.microsoft.com/fwlink/?LinkId=27882)

Resource Kits Microsoft Exchange 2000 Server Resource Kit (http://go.microsoft.com/fwlink/?LinkId=6543) You can order a copy of Microsoft Exchange 2000 Server Resource Kit from Microsoft Press® at http://go.microsoft.com/fwlink/?LinkId=6544. Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink/?linkid=25197) You can order a copy of Microsoft Windows Server 2003 Deployment Kit from Microsoft Press at http://go.microsoft.com/fwlink/?LinkId=27096. Windows 2000 Server Resource Kit (http://go.microsoft.com/fwlink/?LinkId=6545) You can order a copy of Microsoft Windows 2000 Server Resource Kit from Microsoft Press at http://go.microsoft.com/fwlink/?LinkId=6546. Knowledge Base Articles 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096) 266768, "XSTR: How to Modify the Store Database Maximum Cache Size" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768) 272314, "XADM: Preparing a Mixed Mode Organization for Conversion to Native Mode" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=272314) 305145, "How to: Remove the IFS Mapping for Drive M in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=305145) 311898, "XADM: Hot Split Snapshot Backups of Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311898) 315407, "XADM The 'HeapDeCommitFreeBlockThreshold' Registry Key" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=315407) 810371, "Using the /Userva switch on Windows Server 2003-based computers that are running Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371) 238573, "XADM: Installing, Configuring, and Using the InterOrg Replication Utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=238573) 238642, "XADM: Troubleshooting the InterOrg Replication Utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=238642)

Exchange 2003 Design Considerations

Before you begin planning a Microsoft® Exchange Server 2003 messaging system, you need to gather a large amount of business and technical information. Many companies have their own system development methodologies to guide them through the process of designing or upgrading systems. Such methodologies generally begin with gathering requirements and assessing the current environment. Even if your company does not follow a formal methodology, the proper approach to the planning phase begins with these first steps.

Planning your Exchange Server 2003 messaging system typically progresses as follows:

 Assessing Your Exchange Server 2003 Design Requirements First, evaluate your business, administrative, user, and security requirements, and conduct a technical assessment of the environment in which you plan to deploy the messaging system.  Understanding Your Current Network Environment Next, assess your technical solutions, and determine the target Exchange messaging system design.  Planning Active Directory with Exchange Server in Mind Along with assessing your current environment from a physical standpoint, you should understand how Windows Server and Active Directory are deployed in your organization.  Understanding Versions of Exchange, Windows, and Outlook Finally, perform a gap analysis to determine what you need to accomplish to move from your existing environment to your target design. Putting It All Together

When planning the placement of Exchange servers and the administration of directories and servers, it is usually recommended that you start with a centralized model and add servers, routing groups, and administrative groups only when necessary. With the features available in Exchange 2003, Windows Server 2003, and Outlook 2003, businesses may be encouraged to adopt more centralized messaging systems than have been possible in the past. In addition, with the proliferation of higher speed and higher bandwidth connections, companies made up of geographically dispersed offices can consider centralizing their hardware and administration so that they can reduce the number of servers required in remote locations. The factors that drive centralization break down into three main categories:

 Centralizing the hardware that serves remote offices Communication between the client computer and server is compressed, and traffic is significantly reduced due to improvements in Outlook RPC communication and Outlook Web Access 2003 compression. Exchange 2003 has a number of features that help you consolidate your sites and administrative groups. In addition, Cached Exchange Mode in Outlook 2003 helps you reduce the number of servers located in remote locations that are connected with high latency.  Reducing the number of servers To reduce total cost of ownership, it is common for companies to try to reduce the number of servers needed to sustain the messaging needs of their users. Your company may decide to reduce the number of servers needed by investing in high-end servers, including high performance processors and servers with multiple processors. Windows Server 2003 and Exchange 2003 also support hyperthreading technology, in which a single processor is able to run multiple threads (and appears as two processors instead of one). The processor must be hyperthreading-enabled and you must use Windows Server 2003 and Exchange 2003.  Centralizing server and directory administration Companies may want to combine and centralize their administrative workforce to reduce administrative costs. One feature that simplifies administration is the improved method for moving mailboxes in Exchange System Manager. Administrators can move mailboxes more efficiently and can recover from failures more easily when corrupt items are encountered. In addition, administrators can schedule mailbox moves to begin and end at a certain time. Assessing Your Exchange Server 2003 Design Requirements

Business, administrative, user, and security requirements directly affect the design of your Exchange Server 2003 messaging system. Because companies use various methodologies to gather and document requirements unique to their situations, this section does not provide an exhaustive list of all possible requirements. Instead, it focuses on some general types of requirements and the issues associated with each that can influence your planning.

Business Requirements

Some of the business requirements that you need to identify before you begin planning an Exchange messaging system include the following:

 Service Level Agreements (SLAs)  Network and hardware cost constraints  Software cost constraints

Business requirements, particularly cost constraints, determine the extent to which you must work within the existing infrastructure or whether it is feasible to upgrade the network infrastructure, hardware, and software.

Service Level Agreements

Service Level Agreement (SLA) requirements determine how things such as storage, clustering, and backup and recovery factor into your system. When assessing SLAs, be sure to determine your company's expectations regarding availability and recoverability, including message delivery time, percentage of server uptime, amount of storage per user, and amount of time to recover an Exchange database. Identify the hours of regular operation and the expectations around planned downtime. In addition, identify the company's estimated cost of unplanned downtime so that you can design the proper amount of fault tolerance into your messaging system.

New features in Exchange Server 2003 and Windows Server 2003 may affect the way you design your system to meet SLAs. In particular, the new Volume Shadow Copy service may challenge the limits that your SLAs previously imposed. Because backups can take a long time to complete, you previously may have had to limit the number of users you hosted on each mailbox store to meet SLA limitations for uptime. With Volume Shadow Copy service, however, the backup is performed from the shadow copy, so there is no affect on the database that the applications are using. Volume Shadow Copy service allows you to back up Exchange data (or any application data) quickly and with minimal impact to your e-mail clients. This helps you support larger databases and more users per server. When used in conjunction with software and hardware that supports Windows Server 2003 Volume Shadow Copy service, you can quickly back up or restore Exchange databases of any size, from 100 GB to several terabytes. You can also set up clusters that exist in different physical locations. All of these features provide improved service levels than may have been previously possible.

Network and Hardware Cost Constraints

Financial constraints surrounding upgrades to the existing network and hardware directly affect the design of your Exchange messaging system. Depending on the integrity of your existing network, certain upgrades may be necessary to meet business and user requirements. In cases where upgrade possibilities are limited, you may or may not be able to take advantage of certain messaging features, such as RPC over HTTP in Exchange 2003. This feature can help you provide a better messaging experience over existing low-speed, unreliable network connections.

If it is part of your business strategy to reduce total cost of ownership by consolidating or centralizing server hardware, certain features in Exchange 2003, Windows Server 2003, and Outlook 2003 can help facilitate this strategy. For example, Exchange 2003 is less subject to memory fragmentation, which means that Exchange 2003 servers with fast processors can handle more users per server before reaching a memory fragmentation limit. This is also the case with Windows Server 2003, which manages memory better so you can host more users on a server before you encounter memory fragmentation issues. Better memory management does not necessarily mean that you will see significant gains in CPU performance or scalability, but usually you can host more users on a server.

For more information about new features, see "Understanding Versions of Exchange, Windows, and Outlook."

Software Cost Constraints

As with network and hardware upgrades, financial constraints surrounding upgrades to operating systems, server applications, and applications for client computers directly affect the design of your Exchange messaging system. For example, if you can upgrade your client computers to Outlook 2003, the Cached Exchange Mode feature provides a better experience over slow or low bandwidth network connections.

Administrative Requirements Your company's administrative requirements have a significant impact on system design, especially if you want to reduce administrative costs by moving toward a more centralized model.

Businesses usually implement administrative models that generally fall into two categories:

 Centralized management A single group maintains complete control of the Exchange system. With this model, you implement a small number of administrative groups, whether you have a single data center or a large number of branch offices. A single information technology group performs all administrative tasks. This model is typical in small- or medium-sized companies, but can also be used in larger companies that have high bandwidth connectivity between all regional offices.  Distributed management Complete control over management of the Exchange system is distributed to company regions or divisions. The company might create at least one administrative group for each region or division, with each administrative group containing routing groups, policies, servers, public folder directory hierarchies, and other objects specific to each division. A central information technology group may be responsible for managing standards and guidelines, but not for daily system administration. Usually, each region or division controls its own assets and performs its own system administration.

Note:

In Exchange 5.5, a site defines both administrative and routing boundaries. In Exchange 2000, the site concept is split into routing groups and administrative groups for greater flexibility. In Exchange 2000 and Exchange 2003, a routing group refers to a collection of full-time, reliable servers in which messages are routed directly from server to server. An administrative group refers to a collection of users with administrative authority and is not confined by routing group boundaries.

Understanding your company's administrative requirements helps you determine whether to implement a centralized model, a distributed model, or a combination of the two. For more information about the interdependencies between Exchange administration and the Active Directory® directory service administration, see "Understanding Your Current Network Environment".

User Requirements

Some of the user requirements that determine how you plan your Exchange messaging system include the following:

 Remote access In companies whose offices are geographically dispersed and connected by slow- and low-bandwidth network connections, users may require a better offline experience. By assessing this requirement along with your business requirements and constraints, you can determine whether you can take advantage of features such as Cached Exchange Mode in Outlook 2003 to provide a better offline experience.  Web access Users may require the ability to access their Exchange information from the Internet. Several changes to Microsoft Office Outlook Web Access 2003 in the areas of user interface and performance improve the experience for users in remote offices. However, investments in operating system upgrades may be required; for example, the performance gains that result from new compression technology rely on using Windows Server 2003 as the operating system.  Mobile access Users may require the ability to access their Exchange information from mobile devices, for example, a Microsoft Pocket PC 2003 Phone Edition device.

For more information about improvements in user experience available in the latest releases of Microsoft Windows® and Exchange, see "Understanding Versions of Exchange, Windows, and Outlook."

Security

Your security requirements may affect your Active Directory design. For example, your company may require strict security boundaries between directories for separate business units, which means that you may need to establish multiple forests. For more information about establishing multiple forests, see "Planning to Deploy Exchange in a Multiple Forest Environment."

Understanding Your Current Network Environment

Before you design your Exchange messaging system, you need to understand the physical and logical aspects of your current environment. From a physical standpoint, your design depends on the type and integrity of your network infrastructure. These factors influence how you deploy Exchange, where you place servers, and the expected user experience. From a logical standpoint, Exchange 2003 depends on the Active Directory® directory service for its services, so your existing Active Directory framework must be sound. In fact, it is highly recommended that you design your Active Directory framework with Exchange in mind.

Important:

An Active Directory infrastructure must be in place before you deploy Exchange 2003. When designing Active Directory, you should understand how Exchange considerations affect your design.

This section describes various aspects of the network infrastructure and Active Directory framework that you should assess when planning an Exchange messaging system. For a checklist that outlines the physical and logical factors you should consider when assessing your current environment, see "Checklist for Evaluating Your Current Environment."

Exchange Server Best Practices Analyzer Tool

The Microsoft Exchange Server Best Practices Analyzer Tool automatically examines your network and determines if the configuration is set according to Microsoft best practices for an Exchange deployment. For more information, see the Microsoft Exchange Server Best Practices Analyzer Tool (http://go.microsoft.com/fwlink/?LinkId=34707).

Network Infrastructure

One of the first things you should do is build a complete picture of the existing physical network so you can determine how well your existing infrastructure supports Exchange. Going through this process can help you identify any needs for upgrades to the existing LAN or WAN. Start with a simple representation of the entire network to identify locations of offices and the connections between them, and then build in more detail, as illustrated by the following figure:

Start with a simple representation of your network infrastructure

To obtain a detailed picture of the LAN and WAN configuration, it is recommended that you diagram all site locations, connection types, and network topologies (such as bus, token ring, or star). Include the locations of firewalls and perimeter networks. Your assessment should also include a thorough inventory of the hardware that currently makes up your network infrastructure, including stand-alone and clustered servers, routers, and switches. Also note all data center logistics, including rack space, cabling, and power supplies. "Checklist for Evaluating Your Current Environment" lists specific items you examine during this assessment.

In general, you should assess your network infrastructure from the following perspectives:

 Geographical considerations  Bandwidth and latency  Current usage  Current messaging system

These areas are discussed in the following sections.

Geographical Considerations

After you map the locations of buildings, campuses, and branch offices, determine the types of network connections to each site, as well as the placement of routers and switches. A thorough understanding of this infrastructure can help you determine the number of Exchange routing groups you need, as well as the servers that will constitute each routing group. You also need to know the incoming and outgoing messaging points, including messages to servers within an Exchange organization and servers outside the Exchange messaging system.

Bandwidth and Latency

A key consideration for planning your messaging system is the total amount of data that can be transmitted over the network in a given amount of time. This quantity is determined by a combination of bandwidth and latency. Bandwidth is the speed of transmission over a network connection in kilobits per second. Latency refers to the amount of time it takes in milliseconds to transfer data from one point to another. Both of these factors combine to determine the amount of data that can be transmitted in a certain amount of time over the network. The product of these two factors directly affects user perception of how long it takes to process a transaction.

When evaluating your network connections, you need to evaluate bandwidth and latency, recognizing that although some types of network connections can maximize bandwidth, they may increase latency. For example, a satellite connection may offer high bandwidth, but latency may suffer when compared to ground connections such as frame relay or dial-up Integrated Services Digital Network (ISDN).

When mapping site locations and connections, determine the type and speed of network connectivity, and factor in the amount of latency introduced due to distances between sites. You may need to recommend network upgrades as part of the project.

Current Usage

The current usage of the network is another key consideration. Examine network usage from all angles, including use by applications and users. Along with identifying the current applications that use the network, consider the impact of future projects or initiatives. You need to plan for the additional impact that future applications will have on the network.

An extremely important consideration when assessing current usage is the network load at peak times. To determine user load on the network, look at the number of users in the various sites as well as their patterns of use.

In general, if a site has more than ten users and is connected by low-bandwidth, high-latency network connections, the site should work in offline mode. Sites connected by low-bandwidth, high-latency network connections benefit from upgrading to Windows Server 2003, Exchange 2003, and Outlook 2003, because they may be able to use the full features of Cached Exchange Mode in Outlook 2003.

Current Messaging System

During planning, you should ask the following questions about your current messaging system:

 What impact does your current messaging system have on your network?  Are you currently running an earlier version of Exchange? If so, are you running Exchange 5.5, Exchange 2000, or both versions in mixed mode?

During planning you should determine the impact of your current messaging system on your network. To simulate the usage of your current messaging system, use load-simulation tools such as Microsoft Exchange Server Load Simulation Tool (LoadSim.exe) and the Exchange Stress and Performance (ESP) tool. LoadSim simulates the effect of high usage by Outlook MAPI clients and helps you customize the Outlook profiles you want to use during testing. ESP simulates the effect of high usage by non-MAPI clients, such as Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), and Outlook Web Access 2003. You can also use ESP to simulate load in an architecture that incorporates front-end servers.

The method you follow for upgrading from an existing Exchange messaging system to Exchange 2003 depends on whether you are running Exchange 5.5 or Exchange 2000. If you are currently running Exchange 5.5 on Windows NT® Server version 4.0, you need to plan for moving user accounts to Active Directory and synchronizing directory information. Exchange 5.5 has its own directory service, whereas Exchange 2003 relies on Active Directory for its directory services. In your project plan, you need to build in a method for synchronizing the two directories. You may also need to plan for a period of coexistence until you can move entirely to Exchange 2003 and Active Directory. If you are running Exchange 2000 or a mixed Exchange 5.5 and Exchange 2000 environment, upgrading to Exchange 2003 is straightforward if Active Directory is already updated with current directory information. For this reason, you need to carefully examine the state of your directory information. For more information about how to plan your deployment path from Exchange 5.5 to Exchange 2003, see "Planning Your Deployment Path."

If you are currently running Exchange 5.5, another factor to consider is using Exchange 2003 with Outlook 2003 Cached Exchange Mode feature to host more users per server, thereby reducing the number of Exchange servers you need. For more information about Cached Exchange Mode, see "Understanding Versions of Exchange, Windows, and Outlook."

Checklist for Evaluating Your Current Environment

The following checklist outlines the physical and logical factors you should take into consideration when assessing your current environment before deploying Exchange.

Physical plant

Data center floor space

Rack space

Network sizing

WAN (may need to provision higher bandwidth connections)

Degree of separation between physical sites (latency introduced) LAN upgrades

Backbone

Modem pools or alternate dial-up

Hardware needs

Servers

Memory

Processor

Storage

High bandwidth network interface cards (NICs)

Routers

Memory

Processor

Switches

Firewalls

Power

Power grid Service Level Agreement (SLA)

Projected power draw

Uninterruptible power supply (UPS) or other power-insulating device (generators, etc.)

Designated "hot" site

Staffing

Training on newly introduced technologies and procedures

Augmentation

Administrators

Support staff

Geography

Time zone issues

Languages

WAN

Encapsulation upgrade (asynchronous transfer mode [ATM], etc.)

Optimization (permanent virtual circuit [PVC] for frame relay)

Overall quality of connections

LAN

Encapsulation change (token ring to Ethernet)

Layer 2 device removal or upgrade

Network

TCP/IP end-to-end

IP Hop count between endpoints

Subnetting considerations (Microsoft® Active Directory® directory service site considerations)

Device configuration

Routers and open ports Switches

Firewalls and open ports

Ports and layer 4 protocols enabled on filtering or blocking devices

All encryption and decryption operations

All format-change operations (for example, other mail gateways and X.400 connectors)

remote procedure call (RPC) connectivity

network basic input/output system (NetBIOS)

Public key infrastructure (PKI)

Virtual private network (VPN)

Shared dependencies between Internet Information Services (IIS), Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP)

DNS

Windows® Internet Name Service (WINS)

Network operating system

Shared dependencies between DHCP, NTLM, NTLMv2, and LM

Windows NT® Server version 4.0 domain structure: Trusts, primary domain controllers, backup domain controllers

Windows 2000 Server or Windows Server™ 2003 Active Directory

Forest structure

Domain structure

Migration

Site structure

Security

Kerberos

Migration

Security principles

Security identifier (SID) history

Directories

Migration

Active Directory Connector

Meta directories

Administration

Migration

Permissions delegation

Management

For more information see Understanding Your Current Network Environment.

Planning Active Directory with Exchange Server in Mind

Exchange 2003 uses the Active Directory® directory service to store and share directory information with Windows Server. Because the two are tightly integrated, your planning efforts need to include a thorough investigation of the impact that Exchange has on your Active Directory design, and vice versa. If Active Directory is already deployed, it is important for you to understand the existing Active Directory structure and how Exchange fits into this structure. This topic describes the key considerations.

If you have not yet deployed Active Directory, you are in a better position to design your Active Directory infrastructure with Exchange in mind. For comprehensive Active Directory deployment information, use the following resources:

 Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink/?linkid=25197)  Best Practice Active Directory Design for Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=17837). (This paper refers to Exchange 2000, but the information also applies to Exchange 2003.)

For more information about recommended ways to integrate Exchange 2003 with Active Directory, see "Planning Your Active Directory and Administrative Model."

The remainder of this topic discusses how to assess your existing Active Directory design as it relates to Exchange in the following areas:

 Physical site structure  Domain and forest partitioning  Administration  Domain controller and global catalog server placement Physical Site Structure

Start with an assessment of the locations of Windows Server sites and the connections between them as discussed in "Understanding Your Current Network Environment." Exchange uses your Windows network infrastructure so you do not have to create and maintain a separate infrastructure for Exchange. An important factor to consider is how point-to-point routing is structured. For example, determine whether site A can communicate to site C through site B or whether there are routing restrictions.

Domain and Forest Partitioning

Because of the tight integration between Exchange and Active Directory, the Active Directory forest structure directly affects your Exchange planning. There is a one-to-one relationship between an Active Directory forest and an Exchange organization. An Exchange organization can span only a single Active Directory forest. Likewise, an Active Directory forest can host only a single Exchange organization. Understanding your current forest structure and the reasoning behind those design decisions can help you to decide whether to use an existing forest to host Exchange or whether to create a new forest to host Exchange.

Although the recommended design for Active Directory consists of a single Active Directory forest for the entire organization. Your organization may contain multiple forests that represent separate business units. One reason this design may be necessary is if your organization needs strict security boundaries between the directories for each business unit.

In a multiple forest scenario, you need to determine which forest is to host Exchange. To reduce the administrative burden, you also need to implement a provisioning method so that changes made in one forest are propagated to the other forests, for example, by using Microsoft Identity Integration Manager (MIIS). Another option is to create a separate forest dedicated to running Exchange. For more information about reducing the administrative burden, see "Planning Your Active Directory and Administrative Model."

Important:

It is recommended that you establish a single Active Directory forest for your entire organization. However, if your company requires strict security boundaries between business units, multiple forests may be necessary. In Active Directory, a forest forms a strict security boundary, which means that administrators in the forest are isolated from other forests. Domains, however, are primarily administrative boundaries. For more information about Active Directory design and administration, see Best Practice Active Directory Design for Managing Windows Networks (http://go.microsoft.com/fwlink/?LinkId=18348) and Design Considerations for Delegation of Administration in Active Directory (http://go.microsoft.com/fwlink/?LinkId=18349).

Start by documenting the forests, domains, and Windows sites that make up your organization. Note the servers that make up each domain and the operating system software each server is running. Also, note the groups or individuals who own each forest, domain, and Windows site.

Active Directory Administration

Another key consideration is the administrative model that is in place in the organization. Because Exchange 2003 uses Active Directory, you administer Exchange in conjunction with the operating system. Active Directory provides a way for you to delegate administrative authority to directory objects through organizational units in Active Directory Users and Computers. You can delegate Windows administrative permissions at the organizational unit level in Active Directory. For Exchange server administration, you can group servers into an administrative group and delegate permissions to the administrative group.

When documenting the servers that make up each domain in a forest, also document the groups or individuals to whom Active Directory administrative permissions have been granted. Then, based on your business requirements, you can use this information to determine how the Exchange servers should be administered. For more information about planning your administrative model, see "Planning Your Active Directory and Administrative Model." Domain Controller and Global Catalog Server Placement

When documenting the servers in each domain, identify the domain controllers and global catalog servers. This information is critical for planning an Exchange organization because you need to know how users in various locations log on and how global address list information and Exchange objects will replicate throughout the forest. A domain controller is limited to the domain in which it is installed. The function of a global catalog server in Active Directory is to maintain a partial attribute set for user objects across all domains in the forest. You may need to make changes in the placement of these servers for Exchange. For more information about Active Directory server placement, see "Planning Your Active Directory and Administrative Model."

Understanding Versions of Exchange, Windows, and Outlook

After you assess your business requirements and document your existing environment, you can apply what you know about the capabilities of the messaging software and operating system software toward a design choice that meets your company's needs.

One of the biggest challenges in designing an Exchange messaging system is balancing business and user requirements against the capabilities of your existing system. To meet certain user requirements, you may have to recommend upgrades to the network backbone, server hardware, or operating system software. When planning your Exchange Server-based messaging system, keep in mind the features in the latest versions of Exchange, Windows Server, and Outlook that affect your design choices. They can help you determine whether technical upgrades may be necessary. Generally, it is recommended that you familiarize yourself with:

 Improvements in Windows Server 2003 that Benefit Exchange 2003 Windows Server 2003 includes several enhancements that enhance the reliability and availability of Exchange 2003.  Improvements in Exchange Server 2003 Exchange 2003 includes new features and enhancements for IT pros and information workers, such as added mobility features and an improved Outlook Web Access.  Improvements in Outlook 2003 Outlook 2003 includes new features that enable it to work better together with Exchange 2003, such as Cached Exchange Mode. Improvements in Windows Server 2003 that Benefit Exchange 2003

Windows Server 2003 includes several new features and changes that may affect the way you design Active Directory and Exchange. The features and changes include:

 Increased number of sites per forest Because of Windows Server 2003 improvements to the Knowledge Consistency Checker (KCC) and Intersite Topology Generator (ISTG), forests can contain a greater number of sites than in Microsoft Windows 2000 Server. In Windows 2000 Server the limit was 300 sites per domain; a Windows Server 2003 domain can contain 3,000 sites or more. These scalability improvements may affect your forest structure.  Volume Shadow Copy service Windows Server 2003 contains Volume Shadow Copy service capabilities that allow you to quickly perform online backups of application data volumes, with minimal impact to your e-mail clients. Volume Shadow Copy service works with applications, operating systems, backup programs, and storage hardware to create a consistent shadow copy of data. This feature allows creates high-fidelity backup recovery and data mining without significant impact to performance.  Storage Area Network support Windows Server 2003 contains several improvements to support for Storage Area Networks, including improvements in connecting to volumes, handling fiber channel Storage Area Networks, and the ability to start from a Storage Area Network.  Log on without a local global catalog server In Windows Server 2003 users can log on without a local global catalog server. This feature caches user credentials and significantly reduces requests to the global catalog server. However, the ability to log on without a local global catalog server is intended for use in Windows sites that do not contain Exchange users.

Important:

In Windows sites that contain Exchange users, it is always recommended that you install a local global catalog server.

Windows 2000 Server

If you continue to use Windows 2000 Server as the operating system or if you upgrade some servers to Windows Server 2003, some of the Windows Server 2003 features are not available until you upgrade to a pure Windows Server 2003 forest.

In particular, the RPC over HTTP feature in Outlook requires that the Exchange server and a global catalog server run Windows Server 2003 and that your Active Directory schema be upgraded to Windows Server 2003.

Other features of Exchange 2003, such as Volume Shadow Copy service, are available when you run Exchange 2003 on Windows Server 2003, but it is not required that you upgrade the Active Directory schema to Windows Server 2003. Improvements in Exchange Server 2003 Exchange 2003 provides improved functionality in the following areas:

 Routing  Support for Volume Shadow Copy service  Support for Outlook 2003 Cached Exchange Mode  Outlook Web Access for Exchange 2003  Mobile Device Support for Exchange 2003

Some of the improvements in these areas depend on whether you are running Windows Server 2003 or Outlook 2003. The following sections discuss these improvements and their dependencies.

Routing Improvements

In Exchange 2000, routing improvements over Exchange 5.5 helped you to move away from hub-and-spoke routing architectures. For example, you may have had to establish a hub-and-spoke routing architecture for Exchange 5.5 to support hard-wired routing paths. To accomplish this, you probably deployed a number of servers dedicated to message routing in the hub site.

Link state routing introduced in Exchange 2000 made it possible for sending servers to determine the best routing path by the state of the link. This change enabled a move toward peer-to-peer networks between routing groups because messages from any routing group can find a direct route to the receiving group over your network backbone.

Exchange 2003 further improves upon the link state routing features of Exchange 2000 by reducing the amount of link state traffic in two ways.

 Performance is improved over what are commonly known as oscillating links, or links that are intermittently available and unavailable. Exchange 2003 reduces link state traffic by attempting to determine if the connector is oscillating. If there are multiple conflicting state changes in the link state queue for a connector in a given interval, the connector is considered an oscillating link and its link state remains up (in service or available for that period). Leaving an oscillating connector up rather than continually changing the link state reduces the amount of link state traffic that is replicated between servers.  Performance is improved in the case of a site to which there is only one route. In this case, Exchange 2003 reduces link state traffic by determining that no alternate path exists and suppressing the link state information. If no alternate path exists for a link, the link state is always marked as up (in service). Exchange lets mail queue for delivery and sends it when the route becomes available.

Both of these changes enhance performance because they reduce the propagation of link state information.

Volume Shadow Copy Service

One of the practical limits to the number of users supported on a single server is the time it takes to back up the mail storage. To significantly reduce this limit, you need the ability to quickly back up and restore your mailbox stores and public folder stores. Exchange 2003 works with the Volume Shadow Copy service in Windows Server 2003 to help you quickly create backups of Exchange data at a specific point in time.

The Volume Shadow Copy service backup method solves several problems with previous backup methods. When an Exchange database is connected, e-mail transactions can continue to occur at any time. If you try to make a quick backup of the data at a particular point in time (a shadow copy), e-mail transactions may still occur while the backup is progressing. As a result, when the backup finishes, it may contain an inconsistent copy of the data. In addition, because it is recommended that you store Exchange database files (.edb files), transaction log files, and Multipurpose Internet Mail Extensions (MIME) content (.stm files) on separate volumes, data may be inconsistent. For example, if you make a shadow copy of the data undergoing a change, and it has not yet been written to the log file, the files do not match.

Without Volume Shadow Copy service, the way to work around this problem is to conduct backups while the database is offline, which means that backups must be performed during downtime. In other words, Exchange has to be shut down so you can perform a consistent backup. But this approach poses scheduling problems and negates any benefit of shadow copy backups. This approach also makes it difficult to complete backups because of the increasing demand for systems to be available 24 hours a day, 7 days a week.

Volume Shadow Copy service, however, creates a consistent point-in-time shadow copy of data while the system is online. After receiving a backup request, Volume Shadow Copy service notifies Exchange services that a backup is about to occur. Exchange then prepares for the backup by cleaning up on-disk structures and flushing caches and log files.

Support for Outlook 2003 Cached Exchange Mode

Exchange 2003 supports Outlook 2003 Cached Exchange Mode, which gives users access to Exchange information from a local cache in the form of an .ost file. Exchange ensures that the mailbox on the server and the .ost file on the client computer remain synchronized as long as the network connection is available. If the network connection is intermittent or is lost entirely, the user can continue to work by accessing e-mail data from the information stored in the local .ost file. Requests for updates from the client computer to the Exchange server are eliminated, so Outlook 2003 users will no longer see the message indicating that data is being requested from the Exchange server during periods of intermittent or no connectivity. The elimination of update requests from the client computer also results in less data traffic from the client computer to the server.

For more information about Cached Exchange Mode, see "Improvements in Outlook 2003." Outlook Web Access 2003 Improvements

The new version of Outlook Web Access in Exchange Server 2003 contains improvements such as forms based authentication, rules, spell checking, and the ability to send and receive digitally signed and encrypted e-mail messages. The user interface has also been significantly redesigned to provide a user experience similar to that provided with Outlook 2003, including a right-hand preview pane and improved navigation pane.

Outlook Web Access for Exchange 2003 has the ability to perform faster, especially over slow connections, and therefore will be far more responsive to user interactions.

The following list briefly describes the significant new features for Outlook Web Access for Exchange 2003:

 Bytes over the wire The speed of Outlook Web Access has been improved by reducing the amount of information that must travel from the server to the browser. Fewer bytes are sent over the wire from server to browser. However, be aware that the logon process involves more bytes than the logon process in Outlook 2003.  Compression support Administrators can configure compression support for Outlook Web Access and provide a performance improvement of nearly 50 percent for most actions on slow network connections. User performance for Outlook Web Access has been optimized for slow network connections with support for data compression. Outlook Web Access compression works by compressing either static or dynamic or both types of web pages, depending on the compression setting you are using. With data compression, your users can see performance increases of up to 50 percent on slower network connections such as traditional dial-up access. You can enable compression from Exchange System Manager.  Forms Based Authentication You can enable a new logon page for Outlook Web Access that will store the user's name and password in a cookie instead of in the browser. When a user closes his or her browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. The new logon page requires users to enter their domain, user name, and password, or their full user principal name (UPN) e-mail address and password. To enable the Outlook Web Access logon page, you must enable forms-based authentication on the server.

The improvements in features, functionality, and performance may affect decisions about how your users should primarily access their Exchange information. For example, in remote sites, Outlook Web Access may be the primary choice, which is a consideration when planning WAN connections and server placement.

Mobile Device Support for Exchange Server 2003

Exchange 2003 provides mobile device support by providing two applications that can support both Microsoft Windows Mobile™ 2003 powered devices and other mobile devices. You can deploy mobile device support to Exchange to provide your users the ability to access their Exchange information from a variety of mobile devices. You deploy your Exchange server to use Exchange ActiveSync® and Outlook Mobile Access in the same way that you deploy your Exchange server to use Outlook Web Access 2003. By default, when you install Exchange, all of your users are enabled for synchronization and for browse access with Outlook Mobile Access.

 Synchronization Synchronizing a device to an Exchange server gives your users access to their Exchange information without their being constantly connected to a mobile network. Users can use their mobile carrier connection to synchronize their Exchange information to their Pocket PC 2003 Phone Edition or Smartphone device and then access this information while offline.  Up-to-Date Notification Up-to-date notifications are automatically generated SMS messages that are sent to a user's Windows Mobile device when a new e-mail message, calendar appointment, or contact arrives in the user's mailbox. Users must configure their devices to receive up-to-date notifications.  Mobile browse access Exchange Server 2003 includes the Outlook Mobile Access application, which makes it possible for users to access their Exchange server to view e-mail messages, contacts, calendar, and tasks with mobile devices. Improvements in Outlook 2003

Outlook 2003 provides improved functionality in the following areas:

 Cached Exchange Mode  RPC over HTTP  Kerberos authentication

Some of the improvements in these areas depend on whether you are running Windows Server 2003 or Outlook 2003. These improvements and their dependencies are discussed below.

Cached Exchange Mode Cached Exchange Mode in Outlook 2003 significantly improves the experience for users who are located in offices that have low-bandwidth, high-latency connections because it gives users access to mail from either a local cache (.ost file) or from the Exchange 2003 server. Exchange 2003 provides better support for Cached Exchange Mode than previous versions of Exchange because it efficiently synchronizes the mailbox on the server and the .ost file on the client computer. Requests for updates from the client computer to the Exchange server are eliminated.

Cached Exchange Mode is especially useful in branch office scenarios, where remote offices have slow or unreliable connections. Users can work from their local cache with or without a network connection, and Exchange synchronizes the local cache and the server mailbox when a connection is available. In addition, Cached Exchange Mode requires fewer requests to the server, which reduces server load per user and helps you support more users per server.

Note:

When Outlook users are using Cached Exchange Mode and a significant directory change occurs, each Outlook client computer receives a full download of the offline address book. This full download occurs not only for client computers in the site being consolidated, but in all remote sites. One situation in which this full download occurs is during site consolidation. For more information about this issue, see "Planning for Site Consolidation."

Deployment Considerations for Cached Exchange Mode

When you deploy Outlook 2003 in your messaging environment, you can allow your users to use the Cached Exchange Mode feature for Outlook. However, when you deploy this feature, you should make sure to stage your rollouts. A user's .ost file is created on his or her computer when the user attempts to synchronize with an Exchange server. This means that all of the information in the user's mailbox will be transferred from the server to his or her computer. For this reason, you should stage rollouts to reduce the number of users attempting to perform an initial synchronization between their Exchange server and their computer running Outlook 2003. Staging your rollout for Cached Exchange Mode is necessary because users will effectively download a complete copy of their mailbox from the Exchange server to use on their local computer. This initial download could adversely affect performance on your Exchange server if many of your users download their mailboxes at one time.

The amount of data is of special concern if the connection is slow and several users connect at the same time. If users' mailboxes are very large (for example, greater than 2 GB each), synchronization with the .ost file could have a significant impact on the network connection. This situation can occur especially in organizations that place no limits on mailbox size.

You should also note that the .ost file is placed in the profile directory by default so, if a user has roaming profiles (for example, across different branch offices), the cache is available in only one of the profiles.

RPC over HTTP

The RPC over HTTP feature in Windows Server 2003 eliminates the need for remote office users to connect to their Exchange servers by using a virtual private network (VPN). Users running Outlook 2003 can connect directly to an Exchange 2003 server within a corporate environment over the Internet. For Exchange to support RPC over HTTP, all Exchange servers that users with Outlook 2003 will access must be running Exchange Server 2003. Additionally, RPC over HTTP is supported only by Outlook 2003. Finally, all computers in your messaging environment that your users will need to use with RPC over HTTP communication must be running Windows Server 2003. This includes the following computers:

 All global catalog servers  All Exchange servers that your Outlook 2003 users will access

After you configure the recommended Exchange front-end and back-end server architecture with Internet Security and Acceleration (ISA) Server, users can use RPC over HTTP to connect to your Exchange 2003 servers.

Important:

To use RPC over HTTP, your Active Directory schema must be upgraded to Windows Server 2003.

The recommended method for deploying RPC over HTTP is to install ISA Server with Feature Pack 1 in the perimeter network and position your RPC proxy server within the corporate network. Your RPC proxy server can be either your Exchange front-end server or another Web server that you allow users to connect to from the Internet. For more information about deployment options, see "Exchange Server 2003 RPC over HTTP Deployment Scenarios."

To enable RPC over HTTP for your organization, you need to do the following:

 Configure a server as an RPC proxy server If you have a server that your users can access from the Internet, such as an Exchange front-end server, you can configure the server to be your RPC proxy server. This RPC proxy server is responsible for specifying which ports communicate with the global catalog servers and all Exchange 2003 servers with which the Outlook 2003 client computer needs to communicate.  Configure your internal network to use RPC over HTTP Computers that Outlook 2003 users will access, including any Exchange Server 2003 computers and the global catalog servers, must be configured for RPC over HTTP communication. Additionally, the perimeter network must be configured to allow for RPC over HTTP communication. Kerberos Authentication

Exchange 2003 and Outlook 2003 can now use Kerberos to authenticate users to the Exchange servers. If your network uses Windows Server 2003 domain controllers, your users can authenticate across forests to the domain controllers in trusted forests, thereby allowing user accounts and Exchange servers to exist in different forests.

Exchange 2003 uses Kerberos when sending user credentials between an Exchange front-end server and the Exchange back-end servers. Previous versions of Exchange used Basic authentication for applications such as Outlook Web Access to send their credentials between an Exchange front-end server and an Exchange back-end server. As a result, companies had to use a security mechanism such as Internet Protocol security (IPSec) to encrypt information from the Exchange front-end server to the Exchange back-end servers.

Planning Your Active Directory and Administrative Model

After you have examined your current Microsoft® Active Directory® directory service model (if Active Directory is already implemented) and assessed your administrative requirements, you can plan how to integrate Microsoft Exchange Server 2003 into your Active Directory model. You can also plan Exchange administration by evaluating the roles in your organization as they relate to the administrative model you choose for your Exchange organization.

Because Microsoft Windows Server™ 2003 and Exchange 2003 both rely on Active Directory for directory services, you must determine how to integrate Exchange into your Active Directory structure.

To deploy Exchange, you need to begin with an established Active Directory infrastructure that is in a stable, working state. If you are upgrading from a Microsoft Windows NT® environment, the ideal condition for deploying Exchange is for all Windows NT accounts and resources to have been migrated to Active Directory. However, you can deploy Exchange even if you are still in the process of migrating Windows NT objects to Active Directory or if you need to retain a Windows NT forest to hold certain resource objects. Within each forest, you can combine resources for administering Windows Server 2003 and Exchange or you can manage these resources separately. The ability to combine resources is made possible by the integration between Exchange and Windows Server 2003.

There are four main scenarios for integrating Exchange with Active Directory:

 Single forest  Dedicated Exchange forest  Multiple forests running Exchange  Mergers and acquisitions Active Directory Scenarios for Exchange

Active Directory scenario Why use this scenario Related topic

Single forest  Richest set of mail system features. Using a Single Forest Users and their mailboxes are contained in the same forest. Topology  Streamlined administration.

 Uses existing Active Directory Structure.

 Does not require synchronization with other forests.

Dedicated Exchange forest  Security boundary between Active Using a Dedicated (Resource forest) Exchange Forest One forest is dedicated to running Exchange and hosting Directory and Exchange administration. Exchange mailboxes. The user accounts associated with the mailboxes are contained in one or more separate forests.

Multiple forests running Exchange  You have multiple business units Using Multiple Forests (Classic multiple forest) with Exchange Exchange runs in separate forests, but mail functionality is that require data and service isolation. available across forests.  You have multiple business units that have separate schema requirements.

 You are confronted with a merger, acquisition, or divestiture.

Mergers and acquisitions  Mergers and acquisitions are a Active Directory Mergers and acquisitions often involve coexistence between Implications of Exchange organizations until they are merged. The planning special case for a multiple forest Mergers and considerations are similar to those of the multiple forest deployment that requires more attention Acquisitions scenario, with additional migration concerns. to migration issues.

Once you have identified the Active Directory scenario that best matches your situation, see Selecting an Active Directory Administration Model.

For More Information

The following resources provide information that can help you with design decisions:

Note:

Although some of these resources refer to Exchange 2000, the information is also applicable to Exchange 2003.

 Multiple Forest Considerations in Windows 2000 and Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=21177)  Best Practice Active Directory Design for Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=17837)  Design Considerations for Delegation of Administration in Active Directory (http://go.microsoft.com/fwlink/?linkid=18349)  Best Practice Active Directory Design for Managing Windows Networks (http://go.microsoft.com/fwlink/?linkid=18348)

Using a Single Forest Topology

If your organization has a single Active Directory forest, you can implement Exchange in that forest. The single forest Exchange design is recommended because it offers the richest set of mail system features and has the most streamlined administrative model. Because all resources are contained in a single forest, a single global address list (GAL) contains all users across the entire forest. The following figure illustrates this scenario. Two examples of implementing Exchange in a single Active Directory forest

The single forest option offers the following advantages:

 Provides the richest set of mail system features  Allows for a streamlined administrative model  Leverages an existing Active Directory structure  Uses existing domain controllers and global catalog servers  Does not require provisioning or synchronization The main disadvantage associated with this option is that administrators need to determine how to share or divide responsibilities for managing Active Directory and Exchange objects.

Using a Dedicated Exchange Forest

There are some cases in which you may need to set up a separate Active Directory forest that is dedicated to running Exchange. For instance, you may have a Windows NT forest that you want to retain. Or, you may need to separate administration of Active Directory objects and Exchange objects; therefore, you may want to set up a separate Active Directory forest dedicated to running Exchange. Companies that require security (forest) boundaries between Active Directory administration and Exchange administration may choose this option.

The Exchange forest (also known as the resource forest) is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests, referred to as the account forests, which are separate from the resource forest. For more information about deploying Exchange in a multiple forest environment, see Planning to Deploy Exchange in a Multiple Forest Environment.

The enabled user from the account forest is associated with a mailbox attached to a disabled user in the resource forest. This configuration allows users to access mailboxes that reside in different forests. In this scenario, you configure a trust between the resource forest and the account forest. You may also need to set up a provisioning process so that each time an administrator creates a user in Active Directory, a disabled user with a mailbox is created in Exchange.

Note:

If the user accounts have a security identifier (SID) history, you must turn off SID filtering between the account forest and the resource forest (otherwise, users will not be able to access their mailboxes). Two ways in which accounts acquire a SID history are: • If you follow the external migration path to migrate from Exchange 5.5 to Exchange 2003, each new account retains its old SID in the SIDHistory attribute. • If you use the Active Directory Migration Tool (ADMT) to move accounts from one forest to another, each new account retains its old SID in the SIDHistory attribute.

Because all Exchange resources are contained in a single forest, a single GAL contains all users across the entire forest. The following figure illustrates a dedicated Exchange forest scenario.

Separate, dedicated Exchange forest

The main advantage of the dedicated Exchange forest scenario is a security boundary between Active Directory and Exchange administration.

The disadvantages associated with this scenario include the following:

 Does not leverage the benefits of integrating Exchange and Active Directory administration, giving you more administrative overhead.  Requires installing duplicate domain controllers and global catalog servers in Microsoft Windows® sites where Exchange will run, which increases the cost.  Requires a provisioning process so that Active Directory updates are reflected in Exchange. (For example, creating a new Active Directory user in Forest A generates a mailbox-enabled placeholder object with permissions.) When you create an object in one forest, you must ensure that corresponding objects are created in the other forest. For example, if you create a user in one forest, ensure that a placeholder is created for that user in the other forest. You can create the corresponding objects manually, or you can automate the process by creating scripts or implementing third-party software. Important:

The GAL Synchronization feature of Microsoft Identity Integration Server 2003 (MIIS 2003) is not designed to work in a resource forest model (in which a user account exists in a separate forest from its mailbox). Although you cannot use the GAL Synchronization feature in MIIS 2003, you can configure MIIS 2003 to provision objects between a resource forest and an account forest. In addition, you can use GAL Synchronization to synchronize the resource forest and other Exchange forests (but not the account forest).

A variation of the resource forest scenario is multiple forests with one forest hosting Exchange. If you have multiple Active Directory forests, the way you deploy Exchange depends on the degree of autonomy you need to maintain between the forests. Companies with business units that require security (forest) boundaries for directory objects, but can share Exchange objects, may choose to deploy Exchange in one of the forests and use it to host mailboxes for the other forests in the company. Because all Exchange resources are contained in a single forest, a single GAL contains all users across all forests. The following figure illustrates this scenario.

Multiple Active Directory forests with one forest hosting Exchange

The main advantages associated with this scenario include the following:

 Leverages an existing Active Directory structure  Uses existing domain controllers and global catalog servers  Provides strict security boundaries between forests

The disadvantages associated with this scenario include the following:

 Requires a provisioning process so that Active Directory updates are reflected in Exchange. For example, creating a new Active Directory user in Forest A generates a mailbox-enabled object with permissions that is disabled in Forest B.  Requires that forest administrators determine how to share or divide responsibilities for managing Active Directory and Exchange objects. Using Multiple Forests with Exchange

Although a single-forest topology is recommended because it provides the richest set of messaging features, there are various reasons for implementing multiple forests. Some of these reasons include:

 You have multiple business units that require data and service isolation.  You have multiple business units that have separate schema requirements.  You are confronted with a merger, acquisition, or divestiture.

Whatever the case may be, the only way to establish strict boundaries between business units is to create a separate Active Directory forest for each business unit. If this is your Active Directory configuration, the preferred way to implement Exchange is to create an Exchange resource forest. For more information about this, see "Using a Dedicated Exchange Forest." For additional information on how mergers and acquisitions can impact your Active Directory topology, see "Active Directory Implications of Mergers and Acquisitions."

However, if the resource forest option is not feasible (for example, with mergers or acquisitions, or because multiple forests are already running their own instances of Exchange), you can implement Exchange across multiple forests, as illustrated in the following figure.

Exchange deployed in multiple forests, with synchronization between forests (classic multiple forest configuration)

This implementation is the classic multiple forest configuration. In this scenario, a company has multiple Active Directory forests, each containing an Exchange organization. Unlike the resource forest scenario, user accounts are not separated from their mailboxes. Instead, a user account and its associated mailbox are in the same forest. The main advantage to implementing the classic multiple forest scenario is that you can maintain data isolation and security boundaries between the Exchange organizations.

The disadvantages associated with this scenario include the following:

 The multiple forest scenario does not provide the richest set of messaging features.  Rules are not preserved during a cross-forest move.  Because a user or group from another forest is represented as a contact, you cannot delegate mailbox access to someone in another forest. Contacts cannot be designated in a mailbox's access rights.  Mailbox delegate permissions are not preserved when you move mailboxes from one forest to another.  Although you can synchronize free and busy information across forests and use it to schedule meetings, you cannot use the Open Other User's Folder feature in Microsoft Office Outlook® to view the calendar details for a user in another forest.  Because a group from another forest is represented as a contact, you cannot view the group's members. Group membership is not expanded until mail is sent to the source forest.  A front-end server cannot proxy requests to a back-end server in a different forest. This limitation applies whether you are using a front-end server for Outlook Web Access or Outlook Mobile Access.  When upgrading a multiple forest organization from Exchange 5.5 to Exchange 2003, as you disconnect the Exchange 5.5 directory replication connectors (DRCs), information is no longer replicated to other forests until the new synchronization tool (such as MIIS 2003) takes effect. Therefore, some information (such as distribution list membership) is lost and must be manually re-entered.

Keep these issues in mind when deciding whether you want to deploy single or multiple forests. If you currently have separate Exchange 5.5 sites and want to retain these boundaries, you should evaluate the advantages and disadvantages of deploying multiple Active Directory forests and Exchange 2003 organizations.

For more information about configuring Exchange in a multiple forest environment, see "Planning to Deploy Exchange in a Multiple Forest Environment."

Active Directory Implications of Mergers and Acquisitions

A merger, acquisition, or divestiture of business units may involve merging two or more separate Exchange organizations. During this process, there is likely a period of time during which you must retain coexistence between the Exchange organizations before you can merge them. In this scenario, the concerns are similar to those in a classic multiple forest scenario. In particular, you must ensure that basic messaging, shared global address list, and shared free/busy information are available during coexistence.

When the time comes to merge organizations, the method you follow depends on the versions of Exchange you are running:

 When merging two forests that are running Exchange 2000 or Exchange 2003, use the Active Directory Migration Tool (ADMT) to migrate accounts and Migration Wizard to migrate mailboxes, as shown in the following figure. Merging two forests that are running Exchange 2000 or Exchange 2003

 When merging a forest that is running Exchange 5.5 with a forest that is running Exchange 2003, follow the guidelines for an external migration from Exchange 5.5 to Exchange 2003, as shown in the following figure.

Merging an Exchange 5.5 forest with an Exchange 2003 forest

For more information about merging forests, see "Planning to Move from Exchange 5.5 to Exchange 2003" and "Planning to Deploy Exchange in a Multiple Forest Environment."

Selecting an Active Directory Administration Model

Based on your administrative requirements, security requirements, and technical capabilities, you can design a centralized administrative model, a distributed administrative model, or a combination of the two. By deciding on whether your model will be centralized or distributed, you are essentially determining whether you will create one or more administrative groups. About Administrative Groups

Administrative groups provide a way to group objects together (such as servers, policies, routing groups, and public folder hierarchies) and define the scope of permissions for the group. For example, if your organization has two sets of administrators that manage two sets of Exchange servers, you can create two administrative groups that contain these two sets of servers. To establish permissions, you can add the appropriate Windows users and groups to the security settings on the two administrative groups. Then, Active Directory propagates these settings to all the configuration objects within the administrative group. To assign Exchange permissions to the administrative groups, you can use the Exchange Administration Delegation Wizard. This wizard simplifies assigning permissions and creating and maintaining access control lists (ACLs).

Administrative Model Details

Centralized  One Exchange Administrative Group

 Centralized server management

 Centralized policy management

 Though limited to one Administrative Group you can have many routing groups.

Distributed  Allows business units to manage their Exchange infrastructure autonomously.

 Use at least one Administrative Group for each autonomous unit.

 If strict security between business units is needed use multiple forests instead of multiple administrative groups in the same forest.

 Support costs can be significant in this model.

Combined  Uses elements of both centralized and distributed.

 Provides a way for organizations to have centralized email policies but local administration.

 Can be particularly useful in branch office scenarios.

Centralized Administrative Model A centralized Exchange administrative model is characterized by a single Exchange administrative group (the default administrative group), centralized server management, and centralized policy management. Recall that in Exchange 2003 the administrative model is completely independent of the physical infrastructure, so your Exchange administrative model can be centralized even if your company consists of several branch offices. Only one administrative group can exist, but there can be many routing groups. If your administrative model is highly centralized and does not require any strict security boundaries between business units, you can follow the single forest model.

Distributed Administrative Model If logical business divisions require autonomy in terms of Exchange server administration, you may need a distributed model. In this model, individual business units or regions have complete control over management of the Exchange organization, although a central group can manage standards and guidelines. In a distributed model, you create at least one administrative group for each region or division. This model is similar to the site model in earlier versions of Exchange and is often used by organizations that have branch offices operating independently. You must also consider whether separating business units by using administrative groups is sufficient, or whether you need to create strict security boundaries between them. If the latter is the case, the only way to create strict security boundaries is to place business units in separate forests.

Note:

Support costs can be very high for branch offices. For this reason, you should weigh these support costs against the cost of upgrading network connections and centralizing servers. Combined Administrative Model A combined model can separate the administrative responsibilities for different geographical locations into specialized administrative groups, but can assign a centralized administrative group that defines organization responsibilities. In this example, administrators of a centralized organization policies group are those who control system and recipient policies used across the organization. Regional groups define daily administrative tasks that administrators perform at different geographical locations. Each of these groups contains other objects, such as public folders and servers, which the local groups manage.

Important:

If your Exchange organization is mixed, which means it contains Exchange 2000 or Exchange 2003 and Exchange 5.5 servers, Exchange displays one administrative group and one routing group for each Exchange 5.5 site by default.

Administrative Roles and Permissions

The flexibility of assigning roles and permissions to administrators in Windows Server 2003 and Exchange means a full range of possibilities for managing recipients, servers, and policies. Generally, it is recommended that you consider how the following capabilities of Active Directory and Exchange 2003 affect the way you organize your administrative roles:

 A single administrator can perform tasks for both Windows Server 2003 and Exchange.  You can organize and administer users based on security considerations, permissions, location, domains, forest, or other requirements.  You can specify user and group access by object class; for example, you can grant administrators permission to view the status of the mailbox store but not the size of a user's mailbox.

Recipient Management and Server Management

With the introduction of Active Directory, you can separate the administration of servers from the administration of recipients. Recipients are defined as objects in Active Directory and include users, groups, and contacts. You create mailboxes, new users, distribution groups, and perform other related tasks in Active Directory Users and Computers because these objects are contained in and managed by Active Directory. However, you configure servers, connectors, public folders, address lists, protocols, and policies in Exchange System Manager.

Identify who performs administrative tasks, such as user account management and daily operation of Exchange. Because Exchange and Windows use Active Directory, some of these tasks are an extension of Windows Server administration. If one person manages all Windows users, consider having this person also manage Exchange recipients, because these tasks are closely related. If different people perform administrative tasks for different groups of users or servers, you might consider using multiple administrative groups to make it easier to assign permissions to a set of Exchange objects for special circumstances.

Administration and Routing

Identify who manages administration and routing in your Exchange system. When you first install Exchange, it runs in mixed mode so that servers running earlier versions of Exchange can coexist within the Exchange organization. Exchange organizations that no longer coexist with earlier versions of Exchange can switch to native mode. The administrative model for organizations in native mode separates routing and administration: you can organize servers in administrative groups to manage permissions and apply system policies, and you can assign servers to routing groups that span administrative groups to most efficiently manage message traffic. For more information about administrative groups and routing groups, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=47579).

Data Management

Identify who manages mailbox stores and public folder stores. Depending on how you organize your system, your public folder hierarchy may be split by regions or divisions within your organization. You can use permissions to define who administers the public folder hierarchy in your organization. Backup and restore accountability can rest with Exchange administrators or with another group. For more information about managing information and backing up resources, see the Exchange Server 2003 High Availability Guide (http://go.microsoft.com/fwlink/?LinkId=47571).

Interoperability with Exchange 5.5

Mailbox management includes creating, modifying, and deleting mailboxes, e-mail addresses, and related properties. In Exchange 2000 and Exchange 2003, mailbox management is integrated with Active Directory recipient management.

Planning Your Deployment Path

This topic will help you plan your deployment path for Exchange 2003. It is primarily geared toward organizations that have no e-mail infrastructure or who have older versions of Exchange. If you are coming from a non-Microsoft e-mail system such as Lotus Notes or Novell GroupWise, see the Exchange Server 2003 Interoperability and Migration Guide (http://go.microsoft.com/fwlink/?LinkId=47572).

The most appropriate path for deploying Microsoft® Exchange Server 2003 depends on an organization's current e-mail infrastructure. For example upgrading from an existing Exchange 2000 organization is a relatively simple process. However, migrating from an Exchange 5.5 organization to Exchange 2003 entails some additional planning because you need to migrate directory information to the Microsoft Active Directory® directory service and messaging system data to Exchange 2003.

In general, smaller companies may be less concerned about the time it takes to deploy Exchange 2003. However, in larger companies where it is not feasible to upgrade all locations at one time, deployment may take from a few weeks to years.

The Goal: Running Exchange 2003 in Native Mode

An Exchange 2003 organization can operate in two modes: native mode and mixed mode. Native mode offers full Exchange 2003 functionality, but mixed mode offers interoperability with Exchange 5.5. When you install Exchange 2003, your Exchange organization is in mixed mode by default. This default setting ensures future interoperability with Exchange 5.5.

Native mode in Exchange 2003 is essentially the same as native mode in Exchange 2000. The presence of Exchange 5.5 servers is what determines whether you can run in native mode. Thus, if your organization contains a mixture of both Exchange 2000 and Exchange 2003 servers but no Exchange 5.5 servers, you can switch the Exchange organization to native mode. For more information about the benefits of switching to native mode see "Understanding Mixed and Native Modes."

Planning for the Switch to Native Mode

Your goal should be to minimize the period of coexistence between Exchange 5.5 servers and Exchange 2003 servers so you can take full advantage of Exchange 2003 features. Remember that after you switch an Exchange 2003 organization from mixed mode to native mode, the organization is no longer interoperable with Exchange 5.5 systems. Exchange organizations operating in native mode can contain Exchange 2003 and Microsoft Exchange 2000 servers. You can switch an Exchange organization to native mode only when all of the Exchange servers in it are running Exchange 2003 or Exchange 2000.

Review the requirements in "Understanding Mixed and Native Modes"in the section titled "Are you a candidate for switching to native mode?" Determine when in the project plan all of the requirements will be met, and plan to switch your Exchange organization to native mode at that time.

Important:

After you switch from mixed mode to native mode, the change cannot be reversed, and the organization is no longer interoperable with Exchange 5.5 systems. For more information about how to switch to native mode, see "How to Switch to Native Mode."

Choose an Installation Path

Every Exchange organization is different, but most should fall under one of the following scenarios. Each scenario has different considerations to think about as you plan your deployment. Some are simple and others are more complex. Select the scenario that best describes your Exchange organization.

Scenario Topic

You have no e-mail servers. Planning a New Exchange 2003 Organization

You only have Exchange 2000 servers. Planning an Upgrade from Exchange 2000

You only have Exchange 5.5 servers Planning to Move from Exchange 5.5 to Exchange 2003

You have Exchange 2000 and Exchange 5.5 Planning to Move from Mixed Mode Exchange 5.5 and Exchange 2000 to Exchange coexisting in mixed mode. 2003

You will be deploying Exchange in multiple forests Planning to Deploy Exchange in a Multiple Forest Environment

You have non-Exchange mail systems. "Understanding Interoperability and Migration" in Exchange Server 2003 Interoperability and Migration Guide

Understanding Mixed and Native Modes

Exchange Server 2003 is always installed in mixed mode which allows it to coexist with Exchange 5.5. In mixed mode, some Exchange 2003 features are not available. In order to enable these features, Exchange must be run in what is called native mode. However, once you move to native mode you cannot switch back to mixed mode. In other words, once you are in native mode you can no longer have Exchange 5.5 servers coexist in the same organization.

Because some Exchange 2003 features are available only when you run in native mode, it is recommended that you switch from mixed mode to native mode as soon as feasible.

Note:

There is no direct relationship between the mode of the Microsoft Windows® domain and the mode of an Exchange organization. The similarity exists only in terms of naming and restrictions on earlier versions.

This topic will discuss the advantages of native mode and help you decide if you are ready to move to native mode.

Features available in mixed mode vs. native mode

Available in Available in mixed Exchange 5.5, Exchange 2003 or Available in pure Exchange 2000, and Exchange 2000 native Exchange 2003 organization Feature Exchange 2003 organization? mode? that is in native mode?

Move mailboxes between Yes Yes Yes servers in the same administrative group

Move mailboxes between No Yes Yes servers in different administrative groups

Create an administrative No Yes Yes group that spans multiple routing groups Use query-based distribution No Yes Yes groups

InetOrgPerson object can be No No Yes mail-enabled or mailbox- enabled

Running in Mixed Mode

For Exchange 5.5, Exchange 2000, and Exchange 2003 to coexist and replicate directory information, the Exchange 2000 and Exchange 2003 configuration must remain in a state that Exchange 5.5 can recognize. Running your Exchange organization in mixed mode allows for interoperability among these versions of Exchange. ADC is also critical to ensure coexistence between the Exchange 5.5 directory and Active Directory.

Note:

Because of the limitations of mixed-mode operation, you should not operate in mixed mode if your organization uses strictly Exchange 2000 and Exchange 2003 servers and if you are sure you will not install an Exchange 5.5 server into your organization.

Mixed mode is designed only for interoperability between Exchange 2003 servers and Exchange 5.5 servers, and you should plan to switch to native mode as soon as it is feasible. Operating your Exchange organization in mixed mode has the following limitations and issues:

 Exchange 5.5 sites map directly to administrative groups and vice versa.  You can only move mailboxes between servers that are in the same administrative group.  You cannot move Exchange 2003 servers between routing groups  Routing group membership must consist only of servers installed in the administrative group that is defined with the routing group.

Note:

When an Exchange 2003 organization is in mixed mode and Exchange 5.5 sites are mapped one-to-one with administrative groups, you can subdivide the routing structure for the Exchange 2003 servers in the collection by using routing groups. Because in mixed mode a particular routing group can belong to only one administrative group, a server cannot belong to a routing group that is held under a different administrative group. Exchange 5.5 servers do not make these routing group distinctions and continue to use the site boundary for routing purposes.

Advantages of Running in Native Mode

Running an Exchange organization in native mode gives you the full flexibility of Exchange 2003 when you manage your messaging system.

Running Exchange 2003 in native mode has the following advantages:

 Distribution groups can be created dynamically. In Native mode you can create query-based distribution groups. A query-based distribution group provides the same functionality as a standard distribution group. However, instead of specifying static user memberships, with a query-based distribution group you can use an LDAP query to build membership in the distribution group dynamically. For more information about query-based distribution groups, see "Managing Recipients and Recipient Policies in Exchange Server 2003" in the Exchange Server 2003 Administration Guide.  Native mode saves bandwidth Your routing bridgehead server pairs use 8BITMIME data transfers instead of converting down to 7- bit. This equates to a considerable bandwidth saving over routing group connectors.  Administrative groups can be renamed.  Consolidate administrative groups and define routing groups and administrative groups with greater flexibility.  Routing groups can consist of servers from multiple administrative groups.  You can move Exchange 2003 servers between routing groups.  Move mailboxes between servers in different administrative groups.  You no longer have to maintain ADC and Site Replication Service.  Simple Mail Transfer Protocol (SMTP) is the default routing protocol.  Support for InetOrgPerson The InetOrgPerson object class is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization. Exchange 2003 supports InetOrgPerson to make migrations from other LDAP directories to Active Directory more efficient. You can create an InetOrgPerson only if you are running a Windows Server 2003 domain controller. InetOrgPerson can be mail-enabled or mailbox-enabled only when the organization is a pure Exchange 2003 organization running in native mode.  The Exchange store in Exchange 2003 ignores and removes zombie access control entries (ACEs) from the previous Exchange 5.5 servers in your organization automatically. These zombie access control entries are security identifiers from previous Exchange 5.5 servers that have been removed from your organization.

What mode are you in?

If you are not sure which mode you are currently running in, see "How to Determine if You Are Running Exchange in Mixed or Native Mode."

Are you a candidate for switching to Native Mode?

You can change your Exchange 2003 organization to native mode if:

 You no longer have Exchange 5.5 servers in your organization.  You have no plans to add Exchange 5.5 servers to your organization in the future, for example, as a result of a merger or the acquisition of a company with Exchange 5.5 servers.  Your company will never require interoperability between your Exchange 2003 or Exchange 2000 servers and Exchange 5.5. (You can use connectors to provide connectivity to older versions of Exchange; however, these servers exist outside the Exchange organization.)  Your organization does not use any connectors or gateway applications that run only on Exchange 5.5.

After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Make sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future before you switch to native mode.

Preparing to Switch to Native Mode

Before you switch to native mode you must remove any Exchange 5.5 servers in your organization and remove the Site Replication Service (SRS).

Note:

If you did not install Exchange 2003 into an Exchange 5.5 organization, you do not need to perform these two steps. See "How to Switch to Native Mode."

Remove Exchange 5.5 Servers

Before you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your organization. See "How to Remove Exchange 5.5 Servers from Your Exchange 2003 Organization."

Remove Site Replication Service

Site Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directory in Exchange 5.5. By default, SRS is installed on the first Exchange server you installed in an Exchange 5.5 organization. However you can move SRS if the initial server installed needs to be removed from the organization such as in the case of a hardware failure. SRS is necessary because without SRS Exchange 5.5 configuration information can only be shared with Exchange 5.5 servers and Exchange 5.5 directories—not with Active Directory. SRS mimics an Exchange 5.5 directory so that other Exchange 5.5 servers can replicate information to Active Directory through SRS. Using the configuration connection agreement created by Exchange Setup, Active Directory Connector replicates the configuration information in SRS into Active Directory.

SRS runs only in a mixed-mode Exchange administrative group. SRS also performs additional functions, such as detecting and reacting to directory replication topology changes. You cannot switch from mixed mode to native mode until you have removed all instances of SRS.

SRS is enabled automatically in two situations:

 On the first Exchange 2003 server you install in an Exchange 5.5 organization.  When you upgrade to Exchange 2000 from an Exchange 5.5 server that is the directory replication bridgehead server for an organization.

See "How to Remove Exchange SRS."

Switching to Native Mode

When you are sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future and you have removed any Exchange 5.5 servers and the SRS service, you can switch to native mode. See "How to Switch to Native Mode."

For More Information For more information, see "How to Switch to Native Mode."

How to Switch to Native Mode

Because Exchange 2003 is structured to take advantage of Active Directory functionality, there are some limitations when Exchange 2003 coexists in the same organization with Exchange 5.5. When Exchange 2003 servers coexist with Exchange 5.5, your organization must run in mixed mode.

Running in mixed mode limits the functionality of Exchange 2003. Therefore, after migrating from Exchange 5.5 to Exchange 2003, it is recommended that you switch from mixed mode to native mode.

Before You Begin

Before you switch to Native mode consider the following:

 After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Before you switch to Native Mode be certain that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future.  You must remove all Exchange 5.5 servers from the organization before you can switch to native mode. See How to Remove Exchange 5.5 Servers from Your Exchange 2003 Organization.  You must remove the Site Replication Service before you can switch to native mode. See How to Remove Exchange SRS.

Procedure

To switch to native mode 1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2. In the console tree, right-click the organization that you want to switch to native mode, and then click Properties.

3. In Properties, under Change operation mode, click Change Mode.

Note:

In the Properties dialog box, the Change Mode button is unavailable if any Exchange 5.5 servers are present or SRS exists in the organization. 4. In the warning dialog box, click Yes if you are sure that you want to permanently switch to native mode. Click Apply to accept your new Exchange mode.

5. To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all of the Exchange servers in your organization. You do not need to restart all of the Microsoft Exchange Information Store services simultaneously, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to your local Windows domain controller. See How to Restart the Microsoft Exchange Information Store Service.

6. To determine whether the changes have been replicated to your local domain controller, see How to Determine if You Are Running Exchange in Mixed or Native Mode.

For More Information

For more information, see Planning to Move from Exchange 5.5 to Exchange 2003.

How to Remove Exchange 5.5 Servers from Your Exchange 2003 Organization

Once you have moved all of the mailbox and public folder data from an Exchange 5.5 server to an Exchange 2003 server you can remove the Exchange 5.5 server from the organization.

Before You Begin  The first Exchange server installed in a site contains site folders. These folders consist of the Offline Address Book (OAB) folder, the Schedule+ Free Busy Information folder, and the Organizational Forms folder, if one exists. Before you remove that server, see Microsoft Knowledge Base article 152959, "XADM: How to Remove the First Exchange Server in a Site."  If this is the last Exchange 5.5 server, see "How to Remove the Last Exchange 5.5 Server from Your Exchange 2003 Organization" in the Planning an Exchange Server 2003 Messaging System.  Verify that there are no mail connectors on the server. If there are, open a connector on another server in the site, and then verify mail flow. Next, remove the connectors on the server to be deleted. Retest message flow. For more information about removing your Exchange 5.5 connectors, see the Exchange 5.5 Help.  Ensure that the account to which you are logged on has Exchange Full Administrator permissions, as well as Exchange 5.5 service account administrator permissions for the site. Procedure To remove Exchange 5.5 from an Exchange 2003 organization 1. From the Exchange Server 5.5 CD, run Setup.exe.

2. On the Microsoft Exchange Server Setup page, click Add/Remove.

3. Clear the checkbox for Microsoft Exchange Server and click Continue.

4. Use the Exchange 5.5 Administrator program to connect to another server within the same site. Make sure you are logged on using the Exchange service account or an account with equivalent permissions. To perform this step, you may need to reinstall the Administrator console from the Exchange 5.5 CD. Do not reinstall Exchange 5.5. Only install the Administrator console.

5. Select the server you want to delete. On the Edit menu, click Delete.

6. Verify that directory replication is complete and Active Directory Connector (ADC) cleanup has taken place. See "How to Verify Directory Replication and ADC Cleanup" in the Planning an Exchange Server 2003 Messaging System.

For More Information

For more information, see "Planning to Move from Exchange 5.5 to Exchange 2003" in the Planning an Exchange Server 2003 Messaging System.

How to Verify Directory Replication and ADC Cleanup

This topic explains how to verify that directory replication is complete and Active Directory Connector (ADC) cleanup has taken place. Procedure To verify directory replication and ADC cleanup 1. Open Exchange Administrator on the Exchange 5.5 server.

2. Expand the site in which you want to verify directory replication and ADC cleanup.

3. Check for objects in the Recipients container by performing the following steps:

a. Click the Recipients container. b. Click View, and then click Public Folders. 4. Check for hidden objects in the Recipients container by performing the following steps:

a. Click the Recipients container. b. Click View, and then click Hidden Recipients. c. Click View, and then click Public Folders. 5. Repeat step 4 for each Recipients container. You should see system folders but no public folders.

How to Remove the Last Exchange 5.5 Server from Your Exchange 2003 Organization

Before you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your organization. This topic guides you through the process of removing the last Exchange 5.5 server from your organization.

Procedure To remove the last Exchange 5.5 server 1. In Exchange System Manager, in the console tree, expand Administrative Groups, expand the administrative group you want, expand Folders, and then click Public Folders. 2. Right-click Public Folders, and then click View System Folders. 3. Under System Folders, click to expand Offline Address Book.The offline address book should be in the following format: EX:/O=ORG/OU=Site. 4. Right-click the offline address book, click Properties, and then click the Replication tab. Verify that Replicate content to these Public Stores has an Exchange 2003 computer listed. If a replica does not exist on an Exchange 2003 computer, click the Add button to add a replica to an Exchange 2003 computer. 5. Repeat Steps 3 and 4 for Schedule+ Free Busy Folder and Organization Forms, if the exist.

Note:

If Exchange 5.5 public folders are present on the computer running Exchange 5.5, you can use the PFMigrate tool that is available with the Exchange Deployment Tools to move your public folders to an Exchange 2003 server. 6. Move any connectors (for example site connectors or directory replication connectors) on this computer to an SRS server in your site.

7. Wait for public folder, Schedule+ Free Busy, and Organization Forms information to replicate before you begin the next steps.

8. From an Exchange 2003 or Exchange Server 5.5 computer, start the Exchange Server 5.5 administrator program. When you receive the prompt for a server to connect to, type the name of the Exchange 2003 SRS server for that administrative group.

Note:

You cannot delete an Exchange 5.5 computer if you are connected to it with the Exchange administrator program. Make sure you are not connected to any Exchange 5.5 servers that you want to remove. 9. Under Configuration, click to expand the Servers node. Click the Exchange Server 5.5 computer that you want to remove from the administrative group, and then press Delete.

Note:

Make sure that the SRS service is running before you delete the server. 10. From the Active Directory Connector Tool MMC snap-in, right-click the Config_CA_Site_Server_Name object, and then click Replicate Now. The Exchange administrator program also removes the Exchange Server 5.5 computer from the SRS database. The Config_CA object "reads" this delete, and then replicates it to Active Directory.

For More Information

For more information, see How to Remove Exchange 5.5 Servers from Your Exchange 2003 Organization

How to Verify that Public Folders Have Been Removed in Exchange Server 5.5

Use this procedure to verify that public folders have been removed from Exchange 5.5. Procedure To verify that public folders have been removed from Exchange 5.5 1. On the Exchange 5.5 server, click Start, point to Programs, point to Microsoft Exchange, and then click Microsoft Exchange Administrator.

2. Click to expand the site, click to expand Servers, and then click to expand the server on which you want to verify that public folders have been removed.

3. Click Public Information Store.

4. Click File, and then click Properties.

5. Click the Age Limits tab. No public folder instances should be listed (although system folders may be listed). If the server is the last server in the site, there should be only site-specific folders listed.

How to Remove Exchange SRS

Site Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directory in Exchange 5.5. You cannot switch to native mode until you have removed all instances of SRS.

Procedure To remove Exchange SRS 1. From the Active Directory Connector Tool MMC snap-in, navigate to your recipient connection agreements. To remove any recipient connection agreements that exist in your Exchange organization, right-click the connection agreement, and then click Delete. You should also remove any public folder connection agreements.

2. Either from another Exchange 5.5 server, or directly from the Exchange 2003 server that is running SRS, open the Exchange 5.5 Administrator program. This is typically the first Exchange 2003 server installed in an Exchange 5.5 site. Click File, click Connect to Server, and then type the name of the Exchange 2003 server running SRS.

3. In the Exchange 5.5 Administrator program, expand the local site name (displayed in bold), expand Configuration, click Directory Replication Connectors, and then delete any directory replication connectors that exist.

Important:

Do not delete the ADNAutoDRC connector listed under Directory Replication Connectors. 4. Allow time for the changes that you made in Exchange Administrator to replicate to the configuration connection agreements (Config CAs) to Active Directory.

5. In Exchange System Manager, ensure that no Exchange 5.5 computers are displayed in any administrative groups.

6. In Exchange System Manager, expand Tools, and click Site Replication Services. From the details pane right-click each SRS, and then click Delete. When you do so, the SRS and corresponding Config CA for that SRS are deleted.

7. After all instances of SRS are deleted, use the Services MMC console to stop and disable the Site Replication Service and the Active Directory Connector (ADC) service.

For More Information

For more information, see "Planning to Move from Exchange 5.5 to Exchange 2003" in Planning an Exchange Server 2003 Messaging System.

How to Restart the Microsoft Exchange Information Store Service

The core data storage repository for Microsoft Exchange Server 2003 is the Microsoft Exchange Information Store service, which contains both mailbox store and public folder store data. The Microsoft Exchange Information Store service uses a database engine called Extensible Storage Engine (ESE), which is a transaction-based database technology. In some troubleshooting instances or when moving from mixed to native mode, you may need to restart the Microsoft Exchange Information Store service. Procedure To restart the Microsoft Exchange Information Store service 1. On the Start menu, click Run, type services.msc, and then click OK.

2. In the Results pane, find the Microsoft Exchange Information Store service.

3. Right-click the service, and then click Restart.

How to Determine if You Are Running Exchange in Mixed or Native Mode

Running in mixed mode allows you to coexist with previous versions of Exchange, but it limits the functionality of your Exchange 2003 servers. This procedure explains how to determine if you are running in mixed or native mode. Procedure To determine the operating mode of your Exchange organization 1. In Exchange System Manager, right-click the Exchange organization for which you want to determine the operating mode, and then click Properties.

2. On the General tab, under Operation mode, the operating mode of your organization is displayed.

Planning a New Exchange 2003 Organization

Deploying Microsoft® Exchange Server 2003 in an organization where no previous versions of Exchange are running is fairly straightforward. The main considerations are whether the organization is running Windows 2000 Server or Windows Server 2003 and whether Active Directory® directory service is implemented in a way that accommodates Exchange. Another major consideration is whether you need messaging systems other than Exchange to connect to or migrate from, such as Lotus Notes or Novell GroupWise. If so, you need to plan for installing and running connectors.

For more information about how to install a new Exchange 2003 organization, see the following resources:

 Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569)  Exchange Server 2003 Interoperability and Migration Guide (http://go.microsoft.com/fwlink/?linkid=47572)  Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231)

Planning an Upgrade from Exchange 2000

======

If your current Exchange environment consists of a pure Exchange 2000 organization in native mode, Active Directory is already implemented and supporting Exchange. Upgrading to Exchange 2003 is fairly straightforward in this case.

Exchange 2000 Components Not Supported in Exchange 2003

It is important to understand that not all components of Exchange 2000 are supported in Exchange 2003. If you currently use any of the components shown in the following table, you may need to keep an Exchange 2000 server in your organization.

You need to remove any unsupported components before attempting an upgrade because they are not supported in Exchange 2003.

Components that must be removed before upgrading an Exchange 2000 server to Exchange 2003 Component Resolution

Microsoft Mobile Information Server Exchange Event Source. Use Exchange Mobile Browse

Instant Messaging Server Retain an Exchange 2000 server to run this component.

Microsoft Exchange 2000 Chat Service Retain an Exchange 2000 server to run this component

Microsoft Exchange 2000 Conferencing Server Retain an Exchange 2000 server to run this component Use Microsoft Live Communication Server

Key Management Service Retain an Exchange 2000 server to run this component Use Windows Server 2003

Microsoft Exchange Connector for Lotus cc:Mail Retain an Exchange 2000 server to run this component

Microsoft Exchange MS Mail Connector Retain an Exchange 2000 server to run this component

You should also check third party services that depend on or interoperate with Exchange 2000 to ensure that they are supported with Exchange 2003.

Other services that could be affected include things like:

 Back up systems  Antivirus applications  Connectors (such as fax connectors). For More Information

For more information about how to upgrade from Exchange 2000, see the following resources:

 Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569)  Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231) Planning to Move from Exchange 5.5 to Exchange 2003

If your current organization is running Exchange 5.5, you have two options for moving to Exchange 2003, the standard path and the external migration path. These are explained in "Deployment Options" below.

You Cannot Install Exchange 2003 on the Same Server as Exchange 5.5

There is no option for performing an in-place upgrade from Exchange 5.5 to Exchange 2003. This means that you cannot upgrade an Exchange 5.5 server to Exchange 2003. To upgrade your organization from Exchange 5.5 to Exchange 2003, you will instead install an Exchange 2003 server on separate hardware and connect it to your existing Exchange 5.5 organization using Active Directory Connectors.

Requirements

You must have a stable Active Directory® directory service environment before you deploy Exchange 2003. You will use the Exchange version of Active Directory Connector (ADC) to maintain coexistence between organizations until you have moved all of your users and data to Active Directory and Exchange 2003.

You do not necessarily have to be completely finished with your Active Directory deployment before you deploy Exchange 2003. For example, you may not be ready to move all Microsoft Windows NT® accounts to Active Directory, but you may want to define an Active Directory domain that can host Exchange 2003 mailboxes. In this case, you can allow ADC to create placeholders in Active Directory for the Windows NT accounts. Exchange 2003 uses these placeholders to ensure e-mail functionality with Exchange 5.5 sites that are not deployed in an Active Directory domain. Then you can move the mailboxes for these accounts to Exchange 2003 servers that are deployed in an Active Directory domain. When you are ready to join the Windows NT accounts to Active Directory (either by upgrading the Windows NT domain or using Active Directory migration tools), you can merge the mailbox placeholder with the Windows account.

Deployment Options

Depending on your situation, you can select one of two paths to move from Exchange 5.5 to Exchange 2003:

 Standard path (recommended) Deploy Exchange 2003 in the Exchange 5.5 organization.  External migration path Migrate Exchange 5.5 data to a separate Exchange 2003 organization.

Regardless of your current environment, the recommended deployment path is the standard path, which involves installing Exchange 2003 into an existing Exchange 5.5 organization. By following this path, you can use the new Exchange Server Deployment Tools in Exchange 2003, which contain all of the recommended steps, diagnostic tools, and setup links that help you install Exchange 2003.

If you cannot install Exchange 2003 into your existing Exchange 5.5 organization, your other choice is to migrate Exchange 5.5 data to a separate Exchange 2003 organization.

Standard Path: Deploy Exchange 2003 in the Exchange 5.5 Organization (Recommended)

This method is recommended because you can take advantage of the Exchange Server Deployment Tools that lead you through the entire process. The Exchange Server Deployment Tools provide the recommended steps, diagnostic tools, and setup links to help you successfully install Exchange 2003.

This strategy is optimal for your organization if you do not plan to make major architectural or topological changes. You should already have Active Directory deployed within your organization, but it is not necessary to upgrade all of your Microsoft Windows NT Server version 4.0 domains or user accounts to Windows 2000 Server or Windows Server 2003. Each Exchange 5.5 site must contain at least one server running Exchange 5.5 with SP3. It is also recommended that your existing organization contain at least one Active Directory domain that is in native mode.

How the Standard Deployment Path Works

With this method, you run the Deployment Tools which take you step by step through the installation. This includes:

 Installing ADC  Using ADC Tools to set up connection agreements that synchronize Exchange 5.5 directory information with Active Directory.  Connecting new server hardware that is running Exchange 2003 to your existing Exchange 5.5 organization.  Moving mailboxes and replicate public folders from Exchange 5.5 to your new Exchange 2003 server. Resources for Standard Migration Path

The following resources contain complete information about using the standard migration path method to deploy Exchange 2003:

External Migration Path: Migrate Exchange 5.5 Data to a Separate Exchange 2003 Organization

An alternative to adding a new Exchange 2003 server to the Exchange 5.5 organization involves creating a separate Exchange 2003 organization and migrating directory information and mailboxes from the 5.5 organization to the new Exchange 2003 organization. This method requires that Active Directory be in place in the target organization. If accounts are in a separate forest from the mailboxes, you must establish a trust between the two forests to allow users to access their mailboxes.

You still use the Exchange Server Deployment Tools to go through the standard deployment steps, but during Exchange Setup, you choose not to join an existing Exchange 5.5 organization.

How the External Migration Path Works

With this method, you use the Deployment Tools to install a new Exchange 2003 organization and then choose one of the following migration methods to get your users and data from the 5.5 organization to the new organization.

Active Directory Migration Tool > Migration Wizard

This method is better suited for smaller organizations. It is a simpler solution than using ADC but does not support a long period of coexistence well. An example of a good candidate for this method is an organization that plans to migrate all of their users over a long weekend.

Using Active Directory Migration Tool (ADMT), followed by the Exchange Server Migration Wizard is a simple method of migration that does not require setting up an Active Directory connector. In this method you will use ADMT to create active user accounts in Active Directory. Once those accounts are created you will move the user's mailbox from Exchange 5.5 to Exchange 2003 and associate it with their new user object in Active Directory. This is a good option for small companies that do not have many mailboxes to migrate. See How to Migrate from Exchange 5.5 to Exchange 2003 Using the Active Directory Migration Tool > Migration Wizard External Migration Path

Active Directory Migration Tool (or upgrade of the accounts domain) > ADC > Migration Wizard

This method is more complicated to implement, but it is more robust. This method better suits larger organizations that anticipate an extended period of coexistence between the two organizations.

This method invovles ADC and is more complicated than the two step method mentioned earlier. It is best used in larger organizations because it allows users to send and receive e-mail messages during the migration process. In this method you will move user accounts to Active Directory, set up ADC, and finally use the Migration Wizard to move Exchange data from the Exchange 5.5 organization to the Exchange 2003 organization. See How to Migrate from Exchange 5.5 to Exchange 2003 Using the Active Directory Migration Tool (or Windows Domain Upgrade) > ADC > Migration Wizard external migration path.

Resources for External Migration Path

The following resources contain information about using the external migration path method to deploy Exchange 2003:

 Exchange Server 2003 Deployment Guide available in the Exchange Server 2003 Technical Library (http://go.microsoft.com/fwlink/?linkid=47569).  Exchange Server Deployment Tools, located on the Exchange Server 2003 compact disc and available for download from the Exchange Server 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?LinkId=21231).  Migrating Mailboxes from Microsoft Exchange Server Version 5.5 to Microsoft Exchange 2000 Server ( http://go.microsoft.com/fwlink/?LinkId=18351) . Although this article is geared toward Exchange 2000, the concepts also apply to Exchange 2003. How to Migrate from Exchange 5.5 to Exchange 2003 Using the Active Directory Migration Tool > Migration Wizard External Migration Path

======

This topic explains one of two options for migrating from Exchange 5.5 to Exchange 2003 using an external migration path. Using an external migration path is not the recommended way to migrate from Exchange 5.5, but it may be necessary in some situations.

Before You Begin

Consider the following before attempting this procedure:

 If possible, you should migrate from Exchange 5.5 to Exchange 2003 using the recommended migration path. See Planning to Move from Exchange 5.5 to Exchange 2003.  This method is best used by small organizations. It is not intended for use in a situation where an Exchange 5.5 organization will coexist with a separate Exchange 2003 organization. Procedure To Migrate from Exchange 5.5 to Exchange 2003 using the Active Directory Migration Tool > Migration Wizard External Migration Path 1. Run ADMT to create active user accounts in Active Directory.

You should select the option for migrating security identifiers (SIDs) to ensure that ADMT adds the source account's SID to the new target account's SID history (SIDHistory) attribute. (In the next step, Migration Wizard uses the SID to match mailboxes to accounts.)

Important:

To migrate SIDs, the target Windows domain must be in native mode. The SIDHistory attribute exists in the domain schema only if the Windows domain is in native mode. However, to migrate SIDs, the target Exchange 2003 domain must be in native mode.

2. Use Migration Wizard to migrate mailboxes.

If you migrated SIDs when you ran ADMT, Migration Wizard uses the SID to match mailboxes to the new accounts and then converts the accounts to mailbox-enabled user accounts. If you did not migrate the SIDs in the first step, Migration Wizard cannot match a

Note:

As an alternative to using ADMT, you can follow the standard process for upgrading from Windows NT Server version 4.0 to Windows Server 2003. Following this process preserves the SID. mailbox to an account and instead creates a disabled user account to associate with the mailbox.

How to Migrate from Exchange 5.5 to Exchange 2003 Using the Active Directory Migration Tool (or Windows Domain Upgrade) > ADC > Migration Wizard external migration path

======

Before You Begin

Consider the following before you begin:

 If possible, you should always migrate from Exchange 5.5 to Exchange 2003 using the recommended migration path. See Planning to Move from Exchange 5.5 to Exchange 2003.  This method is best used by larger organizations. It is intended for use in a situation where an Exchange 5.5 organization will need to coexist with a separate Exchange 2003 organization for a period of time.  There are two available methods for migrating SIDs from the source account to the destination account: You can upgrade the Windows NT domain to Windows Server 2003, which preserves the SID on each account. --OR-- You can use ADMT, providing you select the option to migrate the SID from the source account to the SIDHistory attribute of the target account. Before setting up ADC, you will need to decided which of these two methods to use.

Important:

To migrate SIDs, the target Windows domain must be in native mode. The SIDHistory attribute exists in the domain schema only if the Windows domain is in native mode.

 If the SID is preserved for each account in the new forest (either through an upgrade or by migrating the SID to the SIDHistory attribute), ADC can create mail-enabled accounts. After you install ADC, you can run Migration Wizard to move mailboxes.  If the process of creating accounts with Active Directory Migration Tool is expected to take a long time, as an alternative, you may want to set up ADC first to create contacts in Active Directory. Setting up ADC first allows Active Directory users to exchange e-mail messages with Exchange 5.5 users during lengthy periods of coexistence. As with the previous method, you then use Active Directory Migration Tool to retain the account permissions (for example, permissions to printers, file shares, and other mailboxes). Procedure To Migrate from Exchange 5.5 to Exchange 2003 using the Active Directory Migration Tool (or Windows Domain Upgrade) > ADC > Migration Wizard external migration path 1. Create new accounts in the target forest by one of two methods:

 A domain upgrade from Windows NT to Windows 2000 or Windows Server 2003 creates accounts with SIDs preserved.  ADMT migrates the Windows NT accounts associated with Exchange 5.5 mailboxes to Active Directory and then creates new Active Directory users. ADMT then populates the SIDHistory attribute for each new user. 2. Setup ADC.

ADC finds the new Active Directory users and assigns e-mail addresses, making the users mail-enabled.

3. Use the Migration Wizard to move Exchange data from the Exchange 5.5 organization to the Exchange 2003 organization.

Migration Wizard finds the Active Directory users by searching for the SID. Migration Wizard creates mailboxes (making the users mailbox-enabled) and then migrates the mailbox data.

For More Information

For more information, see the following resources:

 Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569)  Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231)

Planning to Move from Mixed Mode Exchange 5.5 and Exchange 2000 to Exchange 2003

If both Exchange 5.5 and Exchange 2000 already coexist, Active Directory® directory service is already implemented and supporting Exchange. Active Directory Connector is running to keep the Exchange 5.5 Directory and Active Directory synchronized.

In this case, you have the following options for deploying Exchange 2003:

 Upgrade one of the Exchange 2000 servers to Exchange 2003.  Deploy a new Exchange 2003 server Exchange 2000 Components Not Supported in Exchange 2003

It is important to understand that not all components of Exchange 2000 are supported in Exchange 2003. If you currently use any of the components in the following table, you may need to keep an Exchange 2000 server in your organization.

You need to remove any unsupported components before attempting an upgrade because they are not supported in Exchange 2003.

Components that must be removed before upgrading an Exchange 2000 server to Exchange 2003

Component Resolution

Microsoft Mobile Information Server Exchange Event Source. Use Exchange Mobile Browse

Instant Messaging Server Retain an Exchange 2000 server to run this component

Microsoft Exchange 2000 Chat Service Retain an Exchange 2000 server to run this component

Microsoft Exchange 2000 Conferencing Server Retain an Exchange 2000 server to run this component Use Microsoft Live Communication Server

Key Management Service Retain an Exchange 2000 server to run this component Use Windows Server 2003

Microsoft Exchange Connector for Lotus cc:Mail Retain an Exchange 2000 server to run this component

Microsoft Exchange MS Mail Connector Retain an Exchange 2000 server to run this component You should also check third-party services that depend on or interoperate with Exchange 2000 to ensure that they are supported with Exchange 2003.

Other services that could be affected include things like:

 Back up systems  Antivirus applications  Connectors (such as fax connectors) ADC Requirements

You must first upgrade all instances of ADC to the Exchange 2003 version of ADC. In addition, you should verify that your connection agreements are set up properly. To do this, use the ADC Tools supplied with Exchange 2003.

Important:

When you run the ADC Tools, they examine your directory configuration and make recommendations for connection agreements. To prevent directory replication problems, it is strongly recommended that you accept the recommendations provided. How it Works

After you upgrade all instances of ADC and run ADC Tools, you install the first Exchange 2003 server. You can either install a server on separate hardware or perform an inplace upgrade on one of your existing Microsoft Exchange 2000 servers.

For More Information

For more information about how to upgrade from Exchange 2000, see the following resources:

 Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569)  Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231)

Planning to Deploy Exchange in a Multiple Forest Environment

======

Planning Your Active Directory and Administrative Model discusses the following scenarios for deploying Exchange in a multiple forest environment:

 Dedicated Exchange forest (resource forest)  Multiple forests running Exchange (classic multiple forest)  Mergers and acquisitions

This topic focuses on configuration requirements for enabling messaging features in a classic multiple forest scenario. However, depending on your requirements, you can apply some or all of this information to the resource forest and mergers and acquisitions scenarios.

Available Features in a Multiple Forest Environment

Most mail features were initially designed to function only in a single forest. Therefore, to ensure that these features are available across forests, you must overcome many design constraints. Some of the more advanced features, such as delegating mailbox access and viewing calendars, are not available if users are in different forests.

Features in a multiple forest environment

Feature Available across forests?

Basic mail flow Yes. Trusts between forests are not required.

Common global address list Yes, with Microsoft Identity Integration Server MIIS 2003 (MIIS 2003). (GAL)

Free and busy data Yes, with the Inter-Organization Replication tool. In Microsoft Office Outlook®, a meeting organizer can synchronization add an attendee from another forest to a meeting request, and the organizer can check the attendee's availability on the Scheduling tab. Public folder synchronization Yes, with the Inter-Organization Replication tool.

Meeting request forwarding Yes, if you configured GAL Synchronization and set up SMTP authentication.

Distribution groups Yes. A distribution group from another forest is represented as a contact. You can send mail to a distribution group in another forest (however, you cannot query the membership of the group).

Secure/Multipurpose Internet Yes, with manual configuration. By default, user certificates are not synchronized between forests. You Mail Extensions (S/MIME) must configure userCertificate to enable S/MIME. Key Management Service in Exchange 2000 and Exchange 5.5 are not supported in a multi-forest environment.

Delivery/read receipts Yes, if Global Settings are configured correctly. (There are a few options for doing this; see "Configuring Mail Flow Between Forests" later in this topic.)

Shared SMTP namespace Yes, if each organization has a unique SMTP domain namespace in addition to the shared namespace. Add across forests a recipient policy that specifies the unique SMTP proxy address to each forest. (If Exchange 5.5 is running in the forest, ADC replicates the second proxy address to the Exchange 5.5 directory as long as two-way connection agreements are set up.)

Public folder permissions No. When you use the Inter-Organization Replication tool to replicate a public folder, the administrator for each forest must set the permissions on the folders.

Rules No. Rules are not preserved during a cross-forest move.

Mailbox delegation No. Because a user or group from another forest is represented as a contact, you cannot delegate mailbox access to someone in another forest. Contacts cannot be designated in a mailbox's access rights. Also, mailbox delegate permissions are not preserved when you move mailboxes from one forest to another.

Calendar viewing No. Although you can synchronize free and busy information across forests and use it to schedule meetings, you cannot use the Open Other User's Folder feature in Outlook to view the calendar details for a user in another forest.

Group membership viewing No. Because a group from another forest is represented as a contact, you cannot view the group's members. Group membership is not expanded until the e-mail message is sent to the source forest.

Connectors to foreign Yes. If one forest is connected to a foreign messaging system, and you are using MIIS 2003, you can messaging systems replicate the foreign messaging system contacts to other forests.

Send as No. Users must be located in the same forest.

Front-end server to multiple No. A front-end server cannot proxy requests to a back-end server in a different forest. This limitation forests applies whether you are using a front-end server for Outlook Web Access or Outlook Mobile Access.

Planning a Multiple Forest Deployment

When installing Exchange in a multiple forest environment, your minimum requirement is to provide basic mail functionality by enabling mail flow and creating a common GAL. Depending on your requirements, you must also set up extended mail features, such as free and busy data and public folder synchronization.

With some additional deployment steps, you can configure your environment to provide as many messaging features as possible across the forests. After you have installed or upgraded Exchange in all of the forests, you can finish your deployment with the following steps:

1. To allow users to search a common GAL in order to send mail, use the GAL Synchronization feature in MIIS 2003. 2. Configure mail flow between the forests. Network connectivity is the only absolute requirement for mail flow between forests. No trusts are required, but you must set up SMTP connectors between the forests. It is also strongly recommended that you enable authentication between the forests—this provides functionality such as resolving users' e-mail addresses to their GAL display names. 3. Configure extended mail features (for example, shared SMTP namespace and global settings). 4. Configure the Inter-Organization Replication tool to synchronize free and busy data and replicate public folders. If users in different forests schedule meetings with one another, you must synchronize free and busy data across forests. Likewise, if you share public folders across forests, you must set up replicas in each forest. 5. Move mailboxes and accounts between forests as necessary.

The first two steps are required for basic messaging. A synchronized global GAL must be available to all forests, and a transport route must be in place to allow mail to flow between them. Depending on your requirements, the remaining steps are extended mail features that you may need to implement.

The following sections provide an overview of how to deploy these features.

Using GAL Synchronization in MIIS 2003

By default, a global address list (GAL) contains mail recipients from a single forest. If you have a multiple forest environment, you can use the GAL Synchronization feature in MIIS 2003 to ensure that the GAL in any given forest contains mail recipients from other forests. This feature creates mail-enabled contacts that represent recipients from other forests, thereby allowing users to view them in the GAL and send mail. For example, users in Forest A appear as contacts in Forest B and vice versa. Users in the target forest can then select the contact object that represents a recipient in another forest to send mail.

If each forest contains at least one Exchange 2003 server, you can use MIIS 2003 to synchronize forests that are running any combination of Exchange 5.5, Exchange 2000, and Exchange 2003. (GAL Synchronization does not work for pure Exchange 5.5 forests.) MIIS 2003 synchronizes the GALs, even if the source or target forest is in mixed mode and is running ADC. In the source forest, ADC synchronizes Exchange 5.5 objects with Active Directory. MIIS 2003 then uses the objects in Active Directory to create the metadirectory objects that it synchronizes with other forests. In the target forest, ADC replicates the contacts into the Exchange 5.5 directory.

If you are running ADC, some additional configuration is required; specifically, to ensure that users and contacts can synchronize between forests, you must configure ADC and MIIS 2003 GAL Synchronization to use a common organizational unit.

Note:

ADC is not designed for cross-forest synchronization. ADC synchronizes Exchange 5.5 objects and Active Directory for the purpose of migrating to Active Directory. To synchronize GALs across forests, use MIIS 2003. You can use MIIS 2003 even if the forests are in mixed mode and running ADC.

To enable GAL Synchronization, you create management agents that import mail-enabled users, contacts, and groups from designated Active Directory services into a centralized metadirectory. In the metadirectory, mail-enabled objects are represented as contacts. Groups are represented as contacts without any associated membership. The management agents then export these contacts to an organizational unit in the specified target forest.

The source forest is authoritative over the mail-enabled objects it supplies to MIIS 2003. If you make changes to the attributes of an object in a target forest, the changes do not propagate back to the source forest.

Consider the following when setting up GAL Synchronization:

 A separate management agent is required for each forest participating in the synchronization.  To ensure that management agents can export contacts to target forests, the server running MIIS 2003 must be able to connect to a domain controller in each of the participating forests. Management agents can manage multiple domains, but they must access domain controllers instead of global catalog servers, because global catalog servers do not have writable copies of all of the naming contexts.  When setting up a management agent, you must specify an account with the appropriate permissions.  If one of the forests contains a connector to a foreign messaging system, by default, that forest is authoritative for the contacts; however, this setting can be changed. For more information, see "Configuring Mail Flow Between Forests" later in this topic.  Users cannot send encrypted mail from one forest to a distribution list in another forest. In cases where forests are connected by an SMTP connector and synchronized with GAL Synchronization, a distribution list is represented as a contact in the target forest, and its membership cannot be expanded.

For complete information about MIIS 2003 GAL Synchronization, see the following resources:

 Microsoft Identity Integration Server 2003 Scenarios (http://go.microsoft.com/fwlink/?LinkId=21270)  Microsoft Identity Integration Server 2003 (MIIS 2003) documentation (http://go.microsoft.com/fwlink/?LinkId=21271)

Supported Topologies for GAL Synchronization

As described in MIIS 2003 GAL Synchronization documentation, the servers running MIIS 2003 and Exchange forests must be arranged in either a mesh or a hub-and-spoke configuration. A combination of the two configurations is also supported. However, you cannot connect the forests in a chain.

Important:

The MIIS 2003 GAL Synchronization feature does not function in a resource forest model (in which user accounts exist in a separate forest from their mailboxes). Although you can configure MIIS to provision objects between a resource forest and an account forest, you cannot use the GAL Synchronization feature in MIIS 2003 to do this. However, you can use GAL Synchronization to synchronize the resource forest and other Exchange forests. Hub-and-spoke topology

In a hub-and-spoke topology, a single server runs MIIS 2003 and reads all of the data about all of the forests, evaluates changes and conflicts, and propagates the changes to each forest. This topology is recommended because it is centrally administered and is the easiest topology to deploy.

Important:

The accounts configured for the server running MIIS 2003 must be able to write to all forests. For some organizations, this may pose a security issue.

Supported mesh topology

In a mesh topology, each forest contains a server running MIIS 2003. Each forest is responsible for setting up the connections from their server running MIIS 2003 to every other forest. This topology is complex and is not recommended without thorough pilot testing. The main reason for selecting this topology is that forests do not have to allow write access to their directories. However, read access is still required; the management agents are configured to read directory information from all of the other forests.

Configuring Mail Flow Between Forests

After setting up GAL synchronization, you must ensure that mail flows properly between organizations and the Internet. For basic mail flow, the only requirement is that a route can be resolved to each adjoining forest. Trusts between the forests are not required. Mail flow is determined by the network connectivity between forests and the way in which SMTP proxy addresses are configured. The ideal configuration is to have direct network connectivity between the forests with no firewalls. (If there are firewalls between the forests, you must open the appropriate ports.)

Note:

No link state information or routing topology information is shared between forests.

You must also set up SMTP connectors between the forests. Furthermore, it is recommended that you enable authentication across the forests. Enabling authentication has the following benefits:

 User name resolution (ResolveP2 registry key) between forests is automatic, which means that a user's e-mail address resolves to the user's name that is stored in Active Directory.  Additional calendaring features and mail features, such as mail forwarding, are available.

To prevent the forging of identities (spoofing), Exchange 2003 requires authentication to resolve a sender's name to its display name in the GAL. In a multiple forest environment, it is recommended that you configure authentication so that users who send mail from one forest to another are resolved to their display names in the GAL, rather than to their SMTP addresses.

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from another forest. After you enable authentication, any mail that is sent between the two forests by an authenticated SMTP connection resolves to the appropriate display name in the GAL. For more information, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569).

Configuring Extended Mail Features

Most companies have Internet connectivity and one or more published domain names. If each Exchange organization maintains a separate namespace, contacts that are synchronized between organizations need only one SMTP address for proper routing. However, you may have several Exchange organizations but only a single namespace that represents your company on the Internet (for example, contoso.com). In this case, to retain individual forest namespaces but still route mail properly to the individual forests, you must distinguish the forests from one another.

In addition, to enable or disable mail features such as out-of-office responses, automatic replies, and delivery reports, you may have to configure global settings.

Configuring a Shared SMTP Namespace

When GAL Synchronization creates contacts from mail recipients in a source forest, it uses SMTP addresses to create a TargetAddress property for each contact. Therefore, when users in a forest send mail to a contact, the mail is delivered to the contact's TargetAddress property, even if the user manually entered the primary reply address. To determine which TargetAddress GAL Synchronization should assign to a contact, it compares the recipient's ProxyAddresses property to the SMTP address for which the Exchange organization is responsible. Each organization must have a unique SMTP domain namespace so that contacts receive a unique TargetAddress. If your forests do not have unique namespaces, you can add a unique SMTP address to the appropriate recipient policies for each Exchange organization that contains users to be replicated across forests. After you do this, messages sent to a contact are routed directly to the source forest, where the target address resolves to the actual mailbox and the message is delivered.

You can also route contacts on a forest-by-forest basis. When setting up management agents for GAL synchronization, you can select whether mail sent to contacts that have been imported into a forest should route back through the source forest. If you have a connector to a foreign messaging system, by default, mail that is intended for a contact is routed to the source forest (the forest that manages the connector); however, the forest administrator can change this routing configuration.

Note:

If Exchange 5.5 is running in the forest, ADC replicates the second proxy address to the Exchange 5.5 directory, provided that two-way connection agreements are set up.

As an example of SMTP routing in a multiple forest environment, consider two forests that each have a default recipient policy with an SMTP proxy address of contoso.com. To set up unique namespaces, you would do the following in each Exchange organization:

 In Organization 1, add an SMTP proxy address of Org1.contoso.com to the default recipient policy.  In Organization 2, add an SMTP proxy address of Org2.contoso.com to the default recipient policy.

In both cases, when adding the proxy address, you would select the This organization is responsible for all mail delivery to this address check box. Also, you would leave the contoso.com proxy as the primary address so that, when a user sends mail, their reply address is [email protected] (rather than [email protected] or [email protected]).

Another example illustrates mail flow in a hub-and-spoke topology. In this example, multiple Exchange organizations are present, but all users can be addressed in a single domain space (for example, @example.com). In this case, all external mail addressed to @example.com flows into a central hub organization called OrgA. OrgA is configured with secondary SMTP proxy addresses that represent each spoke organization. One of these addresses is @OrgB.example.com. When mail addressed to [email protected] arrives at OrgA, the mail resolves to the contact, and the mail is redirected to OrgB. When the message leaves OrgA, the To line is changed to the TargetAddress propertyto allow for routing, but the Reply To address remains [email protected].

For the following reasons, moving recipients from one organization to another does not prevent users from replying to old e-mail messages:

 The message retains the legacyExchangeDN property so that recipients can reply to the mail.  GAL Synchronization creates a secondary X.500 proxy address for the user who was moved so that old messages can be properly routed to the user's new mailbox based on the legacyExchangeDN property.

For example, UserA sends mail to UserB, who is in the same organization. Later, UserA is moved to a different organization. The mail originally sent by UserA still specifies UserA's legacyExchangeDN property. GAL Synchronization creates a contact for UserA in the old organization and assigns an X.500 address with the old legacyExchangeDN property. This allows UserB to reply to the old mail, which, in turn, is properly routed to the TargetAddress property for UserA. If a mailbox is moved many times, the list of secondary proxy addresses can potentially grow large.

SMTP Relay Servers

If you want to use an SMTP relay server to route all mail from the Internet to the correct forest, it is recommended that you set up an SMTP relay server. On the SMTP relay server, create SMTP connectors to all of the other forests so that mail routes directly to each forest. This configuration allows you to add SMTP servers as needed for load balancing. You can also add SMTP connectors to route all outbound Internet mail through the new forest.

Configuring Global Settings

To enable or disable mail features such as out-of-office responses, automatic replies, and delivery reports, you must configure Internet Message Formats for the appropriate domains. Three methods for configuring Internet Message Formats are:

 Configure the Default domain (*) so that all domains have the same settings.  Add a separate Internet Message Format domain for each SMTP namespace (for example @OrgA.contoso.com), and then configure each domain differently.  Add an Internet Message Format domain that represents domains with a common suffix (for example @*.contoso.com) and then configure each entry differently.

Internet Message Formats are located in Exchange System Manager under Global Settings.

Sharing Free and Busy Data

In companies that have multiple Exchange organizations, a common requirement is the ability to coordinate meetings, appointments, and contact information with users in different Exchange organizations. Therefore, to replicate these free and busy system folders between forests, you can use the Inter-Organization Replication tool. If your company uses public folders, you can also use the Inter-Organization Replication tool to share public folder data across Exchange organizations.

Note:

You can download the Inter-Organization Replication tool from the Exchange Server 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?LinkId=21316).

The Inter-Organization Replication tool consists of two programs: the Exchange Server Replication Configuration tool (Exscfg.exe) and the Exchange Server Replication service (Exssrv.exe). Exscfg.exe creates a configuration file that Exssrv.exe uses to continuously update information from one server to another. The server that sends updates is the publisher, and the server that receives updates is the subscriber. All replication takes place over MAPI sessions that are established between servers in the organizations.

The Inter-Organization Replication tool publishes free and busy data for mailbox-enabled user objects and contact objects to other organizations, providing that equivalent contact objects exist in the target organization (as created by GAL Synchronization). The contacts are matched by their SMTP addresses. (When setting up the Inter-Organization Replication tool, use the Publish custom recipient free/busy data option.) You can then replicate all or a portion of the free and busy data from one organization to another. However, free and busy data replicates only in one direction. Therefore, to update free and busy data in both directions, you must configure two sessions.

You cannot use the Inter-Organization Replication tool to modify address books or directories. Any address book changes are not propagated to other organizations. These changes must be made independently.

Similar to free and busy data, you can replicate all or a portion of public folder data from one organization to another. However, unlike free and busy data, you can replicate public folders from publisher to subscriber or bi-directionally, resulting in fewer sessions. In addition, a single instance of the Inter-Organization Replication tool can support up to fifteen sessions—this means that a public folder server can subscribe to multiple publisher servers. You can specify individual folders or both folders and subfolders. Furthermore, you can configure the replication frequency, message and folder replication logs, and the amount of processing power you want dedicated to the replication process. Important:

The Inter-Organization Replication tool does not replicate permissions for public folders. When a public folder is replicated to another forest, the administrator for that forest must set permissions on the public folders.

Whether you should configure the Inter-Organization Replication tool in a mesh configuration or in a hub-and-spoke configuration depends largely on the number of organizations in your environment. A mesh configuration is feasible for up to four organizations. However, if you have more than four organizations, it may be easier to manage the Inter-Organization Replication tool in a hub-and-spoke configuration.

Note:

A ring topology is not recommended for inter-organizational replication. Because there is potential for high replication latency along the ring, a user could update information in a forest that has not yet received the replication update. As a result, the most recent update is overwritten by the replicated update. Another issue with a ring topology is, if one connection breaks, the loop is broken.

Detailed configuration information for the Inter-Organization Replication tool is provided when you download the tool. For more information about the Inter-Organization Replication tool, see the following Microsoft Knowledge Base articles:

 238573, "XADM: Installing, Configuring, and Using the InterOrg Replication Utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=238573)  238642, "XADM: Troubleshooting the InterOrg Replication Utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=238642)

Moving Mailboxes and Accounts Across Forests

To migrate accounts and mailboxes from one Exchange 2000 or Exchange 2003 organization to a separate Exchange 2000 or Exchange 2003 organization, it is recommended that you first use the Active Directory Migration Tool (ADMT), followed by the Exchange Migration Wizard.

First, run ADMT to create active user accounts in Active Directory. It is recommended that you select the option for migrating SIDs so that ADMT adds the source account's SID to the new target account's SID history attribute. (Migration Wizard uses the SID to match mailboxes to accounts in the next step.)

Note:

To migrate SIDs, the target Windows domain must be in native mode.

After you migrate the accounts, use Migration Wizard to migrate mailboxes. If you migrated SIDs when you ran ADMT, Migration Wizard uses the SIDs to match mailboxes to the new accounts and converts the accounts to mailbox-enabled user accounts. If you did not migrate the SIDs in the first step, Migration Wizard cannot match a mailbox to an account; instead, the wizard creates a disabled user account to associate with the mailbox.

There may be cases where you have to migrate mailboxes before you migrate accounts. In these cases, Migration Wizard creates disabled user accounts to hold mailboxes and then associates new mailboxes with external Windows NT accounts. Later, when you use ADMT to migrate accounts, new accounts are created in Active Directory. As a result, Active Directory contains two objects that relate to the same user. To merge these duplicate objects, use the Active Directory Account Cleanup Wizard (Adclean.exe). Adclean.exe is installed with Exchange and you can access it from Exchange System Manager (click Start, point to Programs, point to Microsoft Exchange, point to Deployment, and then click Active Directory Account Cleanup Wizard).

The following are limitations associated with moving mailboxes across forests. Plan for these situations, and notify users of the steps they must perform before and after the move:

 Outlook profiles cannot resolve users that have been moved across forests. After a user has been moved, the profile must be updated with the new server name to which the user has been moved. The Exchange Profile Update tool (Exprofre.exe) is a command-line tool that you run on client computers to automatically update users' Outlook profiles. Exprofre.exe modifies the default Outlook profile so that users can successfully log onto their mailboxes after the move. This tool is available from the Exchange Server 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?linkid=21316).  If you are using the Cached Exchange Mode feature in Outlook, ensure that, after you migrate accounts, the new profiles are associated with the correct .ost files on the users' computers. This action eliminates the need for re-synchronizing the .ost files. Also, before moving users, ensure that they have synchronized all of their offline files with the Exchange server.  Mailbox access control lists (ACLs) or delegate permissions are not preserved during a cross-forest move.  Published certificates are not migrated during the move. In addition, you cannot recover Key Management Service certificates after a move. To be recovered, the certificates require a domain name.  Rules are not preserved during a cross-forest move. For more information about using Exchange Migration Wizard, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?linkid=47569).

Planning for Public Folder Management ======Your network infrastructure, security requirements, and administrative model determine the decisions that you make regarding public folder administration. Public folder management encompasses not only public folders, but also system folders. One of these system folders is the free/busy folder, which controls whether you can see other users' free/busy information when setting up a meeting. Generally, it is recommended that you have a good understanding of your existing infrastructure and the issues that affect your administrative model. The following features of public folders help you control how public folders are managed and administered:

 Replication A public folder can be configured to have copies (replicas) on multiple servers. Replicas are useful for distributing the user load on servers, distributing public folders across geographical areas, and backing up public folder data. You can set up a replication schedule based on how often data in the public folder changes. You can set this schedule for all public folders or for a specific public folder.  Public folder referrals When a client computer must use an alternate server to access public folder content, Exchange uses the routing group configuration to refer the client computer to another server. This alternate server may reside in a different routing group. The public folder referral process lets the user access content wherever it exists, even when the specific server that contains the data is not known. This process also eliminates the need for a cost-based referral list because the cost information is determined based on the routing group connector costs.

Public Folder Replication A public folder can be configured to have replicas on multiple public folder servers. Replicas are useful for distributing the user load on servers, distributing public folders geographically, and providing redundancy for public folder data. All replicas of a public folder are equal, so there is no master replica.

During public folder replication, the public folder hierarchy is replicated to every server that has public folders in the Exchange organization, but the contents are replicated only to servers on which an administrator has set up replicas. Changes that were made to items in a replica are sent to all other replicas of the public folder throughout the organization. Changes that were made to the folder, the folder's properties, or the public folder hierarchy are replicated to all servers.

When more than one replica of a public folder exists, connections that users make are distributed across all replicas in an organization. If a replica of the folder is on the user's public folder server, the first connection attempted is to that replica. If a connection to the replica cannot be made because a server is unavailable or because a network connection cannot be made, a connection to a different server in the routing group is attempted. If routing connectors enable public folder referrals, connections to servers in other routing groups are attempted.

Planning Considerations This section provides specific planning considerations and recommendations for public folders.

Dedicated Public Folder Servers The public folder store relies on mail transport for delivery of replication messages. The public folder store does not replicate messages based on topology details. If the content of a public folder is modified and it has five replicas, then a single replication message is generated and addressed to all five other public folder stores. For this reason, your routing topology has a great effect on how efficiently public folders are replicated.

Generally, to separate public folder replication traffic from mail traffic, it is recommended that you deploy a dedicated public folder server for administrative groups that contain more than three servers. Deploying a dedicated public folder server reduces replication traffic and simplifies the administration of public folders. After you set up a dedicated public folder server, remove the public folder stores from the mailbox servers. The public folder server, in turn, does not have to host any mailboxes, but it does require a mailbox store to allow for mail-enabled public folders. Then configure users' mailbox stores to use the dedicated public folders server as the default public folder store.

Public Folder Placement If your organization consists of multiple remote locations, you have two options for public folder placement. You can put public folder replicas on local Exchange servers so that each location has a replica of public folders from other locations. Or, you can store all public folder information in a central server in the data center or hub so that you maintain a single, accurate source of data. The choice of options is based on the balance between accuracy and convenience, it and depends on user requirements and usage patterns.

If you plan to centralize your Exchange servers, you may decide not to install an Exchange public folder server in remote sites. However, you should be aware that, if the sites are connected by low-bandwidth, high-latency network connections, public folder access does not benefit from Cached Exchange Mode the way that mailbox access does. Unlike mailbox data, public folder data is not cached locally on the client computer (unless you add a public folder to your offline "Favorites," which are kept synchronized with the server's data). Therefore, requests for public folder data are directed over the remote connection to an Exchange server in the data center. Therefore, access to public folders is subject to the latency that is part of your network connections.

When no local Exchange public folder server exists and access to a server is available over a low-bandwidth, high-latency connection, it is recommended that users access public folders by using Outlook Web Access 2003. Compared to Outlook, Outlook Web Access usually provides faster access to public folders when there is no local Exchange public folder server.

Note:

If you use Cached Exchange Mode, public folder data is not cached locally for Outlook 2003 users. Requests for public folder data are directed over the remote connection to an Exchange server, so these requests are also subject to the latency in the connection. In most cases, the need for instantaneous access to public folder information is not a requirement. However, this need is a factor you should consider when testing your Exchange infrastructure and then use it to determine whether the degree of latency is acceptable for your organization.

System Folder Placement By default, each public folder store contains system folders invisible in Exchange System Manager. (To view system folders, right-click the Public Folders container under Folders, and then click View System Folders.) Among the system folders are the following folders:

 Schedule+ free/busy folder  Offline address book folder Schedule+ Free/Busy Folders The Schedule+ free/busy folder contains information that Outlook users use to view the availability of others when scheduling meetings. Each administrative group has one free/busy folder. If your administrative model requires multiple administrative groups, you can configure the Schedule+ free/busy folder to maintain replicas of free/busy folders from any of the other administrative groups. Replication occurs just as it does for public folders. Because each administrative group has one free/busy folder and an administrative group can span multiple routing groups, you may need to add a folder replica in each routing group. Adding this folder makes sure that free/busy information is always local. Be sure to verify that the routing group connectors allow public folder referrals.

Access to free/busy information is one of your most important considerations. First, consider network connectivity and bandwidth issues. Then, balance these issues with how users schedule meetings and determine the level of delay acceptable to your business. For free/busy information, if users do not have access to a local copy of free/busy folder data, they may experience a delay in receiving other users' free/busy information when scheduling meetings. If it is very important that users in a specific location always have access to up-to-date scheduling information, you should host free/busy folders in a centralized location, even if it results in delays for users who access the information over low bandwidth connections. If the need for up-to-date information is not as critical as fast access to free/busy information, you can host free/busy folders on local Exchange servers.

If you decide to host free/busy information on local Exchange servers, you need to consider whether to put copies of free/busy folders from other locations on the local server. If users in different locations rarely schedule meetings with each other, you do not necessarily have to keep local replicas of free/busy folders from other locations.

Note:

As with public folder data, if you use Cached Exchange Mode, free/busy data is not cached locally for Outlook 2003 users, so free/busy requests are subject to any latency in the remote connection.

Offline Address Book Folders The offline address book folder contains subfolders that store offline address lists. You should select an appropriate server to generate and update offline address lists. For increased server performance, select a server that is not busy performing other tasks.

If you use Cached Exchange Mode, you should consider the effect on the server when users download offline address lists. This effect could be significant, not only the first time that users download offline address lists, but daily. You may want to consider setting up one or two servers to handle offline address books.

Configuring Referrals Like Exchange 2000, public folder referrals in Exchange 2003 are transitive. This means that if public folder referrals are allowed between routing groups A and B, and between routing groups B and C, public folder referrals are automatically allowed between routing groups A and C. In Exchange 2000, if you wanted to control traffic to public folders, you had to create separate routing groups to contain the public folder servers. This is because the ability to allow or not allow public folder referrals was available only at the routing group connector level. In Exchange 2003, however, you can configure referrals at the server level instead of the connector level. For each Exchange 2003 server, you can select a list of other servers to which referrals are allowed. Therefore, you no longer need to create separate routing groups for the sole purpose of controlling public folder referrals.

In a topology characterized by fast network connections, referral traffic may not be an issue. By default, a server can make referrals to any other server and, as long as the connections are fast and reliable, no traffic issues result. However, if you have Exchange servers with public folder replicas in remote sites with high-latency connections, you may want to refine the public folder referral model by identifying specific servers that can accept referrals.

Requirements for Accessing Public Folders in Exchange System Manager The following requirements need to be addressed before you can successfully access public folders in Exchange System Manager (ESM).

 The default Web site should be bound to the first IP address, if there is more than one IP bound to the network adapter.  The /Exadmin and /public virtual directories must exist in the default Web site. If these two directories do not exist in the Web site that is bound to the first IP address, you will receive a series of errors when you access public folders in Exchange System Manager. When you access the public folders through ESM, the actual information is called through the /Exadmin virtual directory in the Exchange HTTP virtual directory. In a stand-alone Exchange server, it will appear under the Default Web Site.  For the default Web site, Windows Integrated authentication and HTTP Keep-Alive should be enabled. Planning for Site Consolidation

Site consolidation involves moving Microsoft® Exchange servers from remote sites into a larger central site and allowing users in remote offices to access their mailboxes and public folders over the network.

Site consolidation provides the following benefits:  The Exchange topology is simplified.  You can administer Exchange centrally and reduce administrative costs.  You can make better use of hardware because there are fewer mailbox servers as well as fewer auxiliary servers (such as public folder servers, free and busy servers, connectors, bridgehead servers, and so on). A centralized datacenter can also increase scalability and availability.  Consolidating sites can help your organization reach the goal of running Exchange in native mode by reducing the number of Exchange 5.5 servers in the organization.  With fewer mailbox servers, there are fewer targets for security issues.

Note:

There are limitations associated with site consolidation. When planning for site consolidation you should familiarize yourself with the issues in Important Considerations for Site Consolidation in Mixed Mode and Site Consolidation in Mixed Mode before you proceed with site consolidation.

Before Exchange 2003 SP1, consolidating sites by moving Exchange data across administrative groups required that your Exchange organization be in native mode. However, in Exchange 2003 SP1, your organization can be in mixed mode. If you are currently running Exchange 5.5, you may decide not to upgrade all of the Exchange 5.5 servers in all sites to Exchange 2000 or Exchange 2003. Instead, you can use the site consolidation tools provided with the SP1 version of the Exchange Server Deployment Tools to guide you through the process of moving mailboxes, distribution lists, custom recipients, and public folders to the central site and retiring Exchange 5.5 servers.

Note:

If Exchange 5.5 is no longer running on any servers but your Exchange organization is still in mixed mode, or if it is relatively easy to remove the Exchange 5.5 servers from the remote site, it is recommended that you switch to native mode before you begin consolidating sites. This strategy minimizes effort and avoids the issues associated with moving Exchange data across sites and administrative groups.

For more information about the site consolidation process for mixed mode Exchange organizations, see Site Consolidation in Mixed Mode. An example site consolidation project can be found at Example: Exchange Server Site Consolidation - Proseware, Inc..

Important Considerations for Site Consolidation in Mixed Mode

Before you consider consolidating remote Microsoft® Exchange sites, you should be familiar with the following recommendations and prerequisites for consolidating sites, as well as the issues that can occur both during and after site consolidation:

 Upgrade client computers to Microsoft Office Outlook® 2003 Before you consolidate sites, upgrade client computers in the remote site to Outlook 2003 and turn on Cached Exchange Mode. Cached Exchange Mode is an important component of site consolidation because remote users can work from their local cache with or without a network connection. Upgrading Outlook on client computers and turning on Cached Exchange Mode creates a local copy of a user's mailbox. By creating the local copy before you move mailboxes, you avoid the heavy download traffic that results from waiting until after you move mailboxes out of the local site. This strategy is particularly useful in cases where the network bandwidth between the remote site and the central site is limited. Although client computers with earlier versions of Outlook and other e-mail applications are supported, these client computers cannot take advantage of Cached Exchange Mode. Also, to help minimize support issues, you should plan to incorporate Outlook 2003 end- user training and preparation into the upgrade process.  Upgrade ADC to Exchange 2003 SP1 Use the Exchange 2003 SP1 version of Active Directory Connector (ADC), which contains new functionality that cleans up objects and distribution lists after site consolidation. When you move mailboxes across sites, ADC updates user objects and all of the distribution groups to which the users belong; as a result, changes are replicated between directories and users can continue to receive mail.  Consolidate Microsoft Windows® domains if possible To avoid problems with setting delegates, publishing Key Management Service certificates, and updating groups through Outlook, it is recommended that you consolidate the remote Windows domains and the Exchange mailboxes simultaneously. The Microsoft Active Directory® directory service requires that Outlook use a global catalog server that is located in the same domain as the object that Outlook is attempting to update. In the example of delegating mailbox access, if a user whose user object is located in the remote domain logs onto Outlook in the central domain, the user cannot set delegates. This is because Outlook is directed to the central domain, but the user objects are located in the remote domain. The global catalog server in the central domain contains a read-only copy of directory objects residing in other domains. If you cannot consolidate Exchange and Windows domains simultaneously, you can configure the following registry key on the Outlook client to use a global catalog server in the central domain where the directory objects are located:  Location:  HKEY_CURRENT_USER\Software\Microsoft\Exchange \Exchange Provider

 Name:  DS Server

 Type:  REG_SZ (string)

 Value: 

 Apply the Directory Service/Information Store (DS/IS) consistency adjuster hotfix and use the adjuster to retain access to Exchange 5.5 public folders If you move users and groups to the central site before you move Exchange 5.5 public folders, the public folder access control lists (ACLs) will be incorrect and users will not be able to access public folders. There are two options for avoiding this problem:  Option 1: After you move users and groups you can run the DS/IS consistency adjuster to update the public folder ACLs with the new user and group information.  Option 2: You can replicate public folders to the central site first, and then move users and groups. Also, make sure that public folder referrals are enabled across the connectors.

Note:

Before you begin consolidating Exchange 5.5 sites, apply the hotfix for the Exchange 5.5 DS/IS consistency adjuster (available at http://go.microsoft.com/fwlink/?linkid=3052&kbid=836489) to all of your Exchange 5.5 public folder servers. This hotfix ensures that, after a cross-site move, public folder ACLs are updated properly so users and groups have continued access to public folders.

 Plan for a full offline address book download Before you move multiple mailboxes across sites, you should determine whether you have enough bandwidth to support a full download of the offline address book for all Outlook client computers at all remote sites. For more information about why a full download of the offline address book occurs, see "Offline Address Book Download" later in this topic.  Update Outlook profiles after moving mailboxes After you move mailboxes across administrative groups, you must update Outlook profiles so that users can log onto the relocated mailboxes. The Exchange Profile Update tool (Exprofre.exe) is a command- line tool that you run on client computers to update users' Outlook profiles automatically. Exprofre.exe modifies the default Outlook profile so users can successfully log onto their mailboxes after the move. This tool is available from the Exchange Server 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?linkid=21316).

Offline Address Book Download

Outlook client computers that use Cached Exchange Mode require an offline address book to resolve e-mail addresses. The offline address book is stored on a public folder server. A full download of the offline address book occurs in the following situations:

 When you consolidate a site, all users at that site who use Cached Exchange Mode and whose mailboxes have moved will receive a full download of the offline address book. This download occurs the first time these users start Outlook after the mailbox move.  When a significant number of directory changes occur (for example, when you move large numbers of mailboxes across sites or when you make changes to the Exchange topology), all users at all sites who use Cached Exchange Mode receive a full download of the offline address book.

For more information about the impact of full offline address book downloads and the situations in which they occur, see Microsoft Knowledge Base article 839826 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839826).

Note:

Depending on the address book size and the available bandwidth and latency of connections to remote sites, full offline address book downloads can be a limiting factor for your organization.

This substantial download could cause performance issues for both your network and for Outlook. When determining the duration of the offline address book download, consider the bandwidth of network connections to all remote sites, the amount of data that must be transferred, and the latency of the network connection. You can estimate the amount of data to be transferred by multiplying the size of the offline address book by the number of users in the remote site.

Note: Example: If the offline address book is 20 MB and there are twenty-five Outlook users using Cached Exchange Mode, the estimated amount of data that needs to be replicated is 500 MB: (20 MB offline address book × 25 users = 500 MB).

Network latency is the amount of time it takes for data to transfer from one point to another in the network. Latency is a factor in determining how quickly the network connection becomes saturated. With long latency, the rate of data transfer is slower, which means it takes longer for the network connection to become saturated. Conversely, a shorter latency means that data flows more quickly, thereby increasing the likelihood that the connection will become saturated if many clients are downloading the offline address book simultaneously.

Before you move multiple mailboxes across sites, you should determine whether you have enough bandwidth to support a full download of the offline address book for all Outlook users at the remote site. You should also assess the impact of the download on your network by factoring in the amount of data to be moved and the network latency.

Free and Busy Functionality

When your organization is in mixed mode, and you use the Move Mailbox Wizard to move mailboxes across sites, the Move Mailbox Wizard updates the corresponding user objects with the new legacyExchangeDN attribute. Because the wizard updates the legacyExchangeDN attribute, you do not need to move free and busy system folders. Users' free and busy data is republished using the new legacyExchangeDN attribute after the user logs onto the new mailbox.

Note:

Free and busy data is not transferred to the new server immediately after you move mailboxes across sites. Instead, the data is posted to the new server fifteen minutes after the user logs onto the mailbox or performs a calendar action (such as creating or accepting a meeting request).

Known Limitations with the Site Consolidation Process

This section describes known limitations for site consolidation. The site consolidation process is affected by a variety of factors, such as the order in which you perform steps, the time it takes for directory information to replicate, and the time it takes for Exchange data to replicate between sites. In addition, other mail features can be affected by moving mailboxes and users between sites. You should familiarize yourself with all of the known issues listed here before you begin planning for site consolidation.

 Network traffic will increase when moving mailboxes When moving mailboxes across sites, you should plan for additional network traffic between the sites. The additional traffic is equal to the combined sizes of the mailboxes you plan to move.  Directory replication traffic will increase When moving mailboxes from Exchange 5.5 sites to a central Exchange site, you can expect increased directory replication traffic while ADC updates users and distribution groups and removes old objects in the remote site. The duration of this process depends on the size of your environment, the replication speed among your Exchange 5.5 sites, and the replication speed between Exchange 5.5 and Active Directory. By default, directory cleanup runs every twelve hours. In small environments, directory cleanup may complete during the next automatic replication session; however, large environments may require more than one session.

Important:

To expedite directory cleanup, you can initiate replication in Active Directory Connector Manager and the Exchange 5.5 administrator program.

 Public folder replication traffic will increase When you use the Exchange Public Folder Migration tool (pfMigrate) to move public folders to the central site, you can expect increased traffic while the public folder hierarchy is updated and public folder content replicates across sites. The pfMigrate tool and the DS/IS consistency adjuster cause increased replication traffic.  Cached offline folder files that are in ANSI format are not automatically re-created in Unicode format after you move Microsoft Exchange Server 5.5 mailboxes Users’ cached offline folder (.ost) files and offline Address Book (.oab) files remain in ANSI format after you move Exchange Server 5.5 mailboxes to a computer that is running Exchange Server 2003 or Microsoft Exchange 2000 Server. A cached offline folder (.ost) file in ANSI format has a 2 GB size limit, and because this file is in ANSI format, the offline Address Book file also uses ANSI format. Additionally, the resolution offered in Knowledge Base article 841207 requires a full download of the offline address book to all of the affected client computers. This download can significantly increase network traffic. For more information about and a resolution for cached offline folder files being created in ANSI format instead of in Unicode format in Exchange 2003 or in Exchange 2000, see Knowledge Base article 841207 "An Outlook 2003 cached offline folder file is created in ANSI format instead of in Unicode format in Exchange 2003 or in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841207). For more information about using Unicode with Outlook 2003, see Configuring Unicode Options for Outlook 2003 (http://go.microsoft.com/fwlink/?LinkId=33526).  Delegates may lose access To retain delegate access in Outlook, move managers and their delegates from the remote Exchange 5.5 site to the central site together. If it is not possible to move them together, move the manager before the delegate or re-grant access rights to the delegate after the move.  Journal recipients need to be re-designated A journal recipient is a user who is configured to receive all archived messages for a mailbox store. Before you move the journal recipient across sites, assign the journal recipient designation to a different user. After the move, you can re-designate the user as the journal recipient.  Inbox rules may not function If a user's mailbox does not reside on an Exchange 2003 SP1 server, any Inbox rules based on other users who have moved across sites will not function because the legacyExchangeDN attribute for the users who have moved is changed. However, the user can re-create the rules. If the user's mailbox resides on an Exchange 2003 SP1 server, rules will continue to function. This issue does not affect users whose mailboxes have moved; it only affects users who have rules based on users who have moved. After all users' mailboxes are hosted on Exchange 2003 SP1 servers, rules will function again.  User names may be briefly absent from the Exchange 5.5 GAL In Exchange 5.5, user names that have moved across sites may disappear from the global address list (GAL) for a short period of time until directory replication is complete. During this time, the original Exchange 5.5 object in the remote site is hidden while the new Exchange 5.5 object is replicated to the new site. The Exchange 2003 GAL is unaffected.  Some users may receive non-delivery reports after migration After you move mailboxes from Exchange 5.5 to the central site, if Exchange 5.5 users who have not been moved reply to mail from Exchange 5.5 users who have been moved, they will receive a non-delivery report (NDR). This situation will continue until Exchange 5.5 directory replication is complete. To avoid this situation, you can force replication by selecting Replicate now in ADC Manager. Another option is to redirect Exchange 5.5 mail through an Exchange 2000 or Exchange 2003 bridgehead server because these servers are able to forward mail to the new mailbox.

Note:

To eliminate NDRs, remove site connectors between Exchange 5.5 sites and create connectors to the central site so that all mail is routed through the central site or through an Exchange 2003 server.

 An authorized user must perform a calendar action to repost free and busy data for resource mailboxes Free and busy data is not transferred to the new server when you move mailboxes across sites. For users, free and busy data is posted to the new servers fifteen minutes after the user logs onto the mailbox or performs a calendar action (such as creating or accepting a meeting request). However, for resource mailboxes (such as meeting rooms), someone with access to the resource mailbox must open the mailbox and perform a calendar action to repost the free and busy information.  Key Management Service requires export of certificates Key Management Service continues to function after a cross-site move if you are using X.509 v3 certificates, but not if you are using v1 certificates. With v1 certificates, users who were moved across sites can decrypt old mail, but they cannot sign or encrypt new mail. If you are using Key Management Service, before you move users across sites, export your certificates, even if the same Key Management Service server provides service to the central site. After the move, import the certificates to the central site's Key Management Service server. Run the Exchange Profile Update tool (Exprofre.exe) after the move.  Exchange Conferencing Server requires a switch to native mode If you are running Exchange Conferencing Server, you should first switch to Exchange native move and then consolidate sites. Following this path avoids problems with the legacyExchangeDN attributes and ensures continued functionality of Exchange Conferencing Server.

Site Consolidation in Mixed Mode

This topic describes the general process for site consolidation of your Exchange Server environment for Exchange organizations in mixed mode. For important information related to this process, see Important Considerations for Site Consolidation in Mixed Mode.

If Exchange 5.5 is running in the sites you want to consolidate, you must use the Exchange 2003 SP1 site consolidation tools to ensure that mailboxes, distribution lists, recipients, and public folders are moved properly and with the least amount of disruption in service. The goal is to ensure that mail flows properly after users and Exchange data are moved to the central site.

Before you consolidate content from remote sites, perform the following actions:

 Verify that you have enough server resources in the central site to handle the Exchange services.  Upgrade all mailbox servers and public folder servers in the central site to Exchange 2003 SP1.  Apply the hotfix for the Exchange 5.5 DS/IS consistency adjuster to all of your Exchange 5.5 public folder servers (available at http://go.microsoft.com/fwlink/?linkid=3052&kbid=836489). This hotfix ensures that after a cross-site move, public folder access control lists (ACLs) are updated properly move so users and groups have continued access to public folders. Important:

Apply the Exchange 5.5 DS/IS consistency adjuster hotfix before you begin the site consolidation process. The site consolidation tools require this hotfix.

 Upgrade all Active Directory Connector (ADC) servers to Exchange 2003 SP1. Ensure that all connection agreements to all sites are two-way and that there are public folder connection agreements on the source and target sites.

Note:

It is highly recommended that you use ADC Tools to configure your connection agreements to ensure that the directories are properly updated and distribution list membership is properly cleaned up.

The overall process for consolidating sites in Exchange mixed mode is as follows:

1. Create a site consolidation plan. Plan and schedule a three-phase site consolidation effort for each site. Schedule time for replication during periods of low usage, such as during a weekend. Ensure that Exchange 2003 is deployed in the central site and that you have established coexistence with Exchange 5.5. Upgrade all Exchange 2003 target servers to Exchange 2003 SP1. If you want to use Outlook with Cached Exchange Mode, install Outlook 2003 in all sites and enable Cached Exchange Mode. 2. The latest version of the Exchange Server Deployment Tools contains site consolidation tools that guide you through the process of moving mailboxes, distribution lists, custom recipients, and public folders to the central site and retiring Exchange 5.5 servers. To prepare for site consolidation, use the tools as follows:  Upgrade all ADC servers to Exchange 2003 SP1.  Apply the DS/IS consistency adjuster hotfix to all public folder servers.  Add public folder replicas to the central site and allow time for public folders to replicate. 3. Use the Exchange Server Deployment Tools to move Exchange data to the central site:  Mailboxes Consolidate content in the remote site to the central site by moving mailboxes and using Exprofre.exe to update user profiles.  Custom recipients and distribution lists Use the Object Rehome tool to update custom recipients and distribution lists to reflect the central site, which, in effect, moves them to the central site. Ensure that the proper connection agreements are set up. 4. Follow the steps outlined in the Exchange Server Deployment Tools to remove the remote site:  Use PFMigrate to remove public folder replicas, and then follow the process for retiring Exchange 5.5 servers.  Use the Object Rehome tool to ensure that distribution lists and custom recipients were successfully removed from the remote site. 5. Repeat these steps for each site you plan to consolidate.

For complete instructions, see the following resources:

 Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231).  Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

Site Consolidation Tools

When consolidating sites, there may be many mailboxes, distribution lists, contacts, and public folders that must be moved across administrative groups. In addition, the legacy Exchange distinguished name (legacyExchangeDN) for an object changes after it is moved across administrative groups, which affects the services that depend on this attribute. The following Exchange 2003 SP1 features and tools address these concerns:

 Exchange Server Deployment Tools The latest version of the Exchange Server Deployment Tools guides you through the process of moving mailboxes, distribution lists, custom recipients, and public folders to the central site, and retiring Exchange 5.5 servers. The latest Exchange Server Deployment Tools are available at http://go.microsoft.com/fwlink/?LinkId=21231.  Move Mailbox Wizard in Exchange 2003 SP1 The Exchange 2003 SP1 version of the Move Mailbox Wizard gives you the option to move mailboxes across administrative groups. If your Exchange organization is in mixed mode, by default, Exchange 2003 displays one administrative group and one routing group for each Exchange 5.5 site. Prior to Exchange 2003 SP1, if your organization contained Exchange 5.5 servers, you could move only mailboxes within the same administrative group. This meant that you could not easily consolidate remote Exchange 5.5 sites into a central Exchange site. In Exchange 2003 SP1, you can move mailboxes across administrative groups by using either the Move Mailbox Wizard in Exchange System Manager or Active Directory Users and Computers.  Exchange Profile Update tool The Exchange Profile Update tool (Exprofre.exe) is a stand-alone executable that updates users' Outlook profiles automatically, thereby allowing users to log onto their relocated mailboxes after the mailboxes have been moved across administrative groups. To update the default Outlook profile to reflect the new information, you must run Exprofre.exe on each client computer. It is recommended that you use a logon script to run this tool.  Public Folder Migration tool It is recommended that you create replicas of Exchange 5.5 public folders on Exchange 2003 servers. By creating replicas, users will still be able to access public folders after users are moved from the remote site to the central site. The Public Folder Migration tool (PFMigrate) moves public folders from remote Exchange 5.5 servers to the central Exchange 2003 server. The latest version of PFMigrate contains a site consolidation command option (/sc) for moving public folders across administrative groups. PFMigrate is available as part of the Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231).  Object Rehome tool The Object Rehome tool moves distribution lists and contacts from remote Exchange 5.5 servers to the central Exchange 2003 server. The Object Rehome tool allows you to update the legacy distinguished name for distribution lists and custom recipients to reflect the central site during site consolidation. By updating these objects to reflect the central site, you ensure that these objects are not lost when you remove the remote site. The Object Rehome tool also updates the distribution list expansion server to the server that you specify. If you want to clear the expansion server from all distribution lists, you can leave the target expansion server option blank so that the distribution lists use any expansion server. The Object Rehome tool is available as part of the Exchange Server Deployment Tools (http://go.microsoft.com/fwlink/?LinkId=21231).

Example: Exchange Server Site Consolidation - Proseware, Inc.

This topic illustrates an example Exchange Server site consolidation project for Proseware, Inc., a fictitious company. Proseware, Inc. employs over 500 people in five offices nationwide. The corporate headquarters in Seattle is the largest office with over 200 employees. The company has four regional offices with high-bandwidth connections in Denver, Phoenix, Los Angeles, and Miami. Exchange services are distributed as follows:

 The corporate headquarters in Seattle has one Exchange 5.5 server that hosts public folders and mailboxes for 200 users.  Each regional office has one Exchange 5.5 server that hosts public folders and mailboxes for 50 to 100 users.

Each regional office has a dedicated IT administrator to manage the local servers. The majority of the servers, however, are located and administered by the Seattle IT organization. Proseware, Inc. plans to upgrade to Exchange 2003, and in the process, consolidate their Exchange sites. They have recently centralized their support and monitoring operations, and they would like to do the same with their Exchange administration. In addition, the user base continues to grow, mailbox data and public folder usage continue to increase, and the Exchange servers are reaching the end of their lifespan. To address these concerns, Proseware, Inc. plans to establish a datacenter in Seattle that will provide Exchange services to the sites. Proseware, Inc. will upgrade to Outlook 2003 and use Cached Exchange Mode. To maximize availability and scalability, the datacenter will take advantage of clustering and Volume Shadow Copy service backups in Microsoft Windows Server™ 2003. Although the general recommendation is to switch to Exchange native mode before consolidating sites, Proseware, Inc. decides not to follow this path because of the cost associated with upgrading all Exchange 5.5 servers to Exchange 2003. Instead, they will use the site consolidation tools provided with Exchange 2003 SP1 to move Exchange data to the central site and retire their Exchange 5.5 servers. The remainder of this topic describes the site consolidation process of Proseware, Inc. Creating a Site Consolidation Plan First, Proseware, Inc. studies the site consolidation tools, issues, and requirements. They determine whether they have enough server resources in the Seattle datacenter to support all of the Exchange services for all regional offices.

During their investigation into users' e-mail requirements, they find that, in the Denver regional office, engineers frequently use e-mail to exchange very large files. Because this site requires the ability to transfer large file over the WAN, moving the Exchange server out of the Denver site and into a central site is not feasible. Therefore, Proseware, Inc. decides to retain an Exchange server in the Denver office. They will upgrade the server from Exchange 5.5 to Exchange 2003.

After they determine which sites to consolidate, Proseware, Inc. creates a site consolidation plan. They determine the timing of the transition for each regional office. Because of the network latency that replication causes, they decide to schedule their public folder and mailbox moves for the weekends, when network activity is at its lowest.

Before they begin the site consolidation process, Proseware, Inc. deploys Exchange 2003 in the Seattle datacenter to ensure that Exchange is running in mixed mode. Specifically, they use the steps and tools in the Exchange Server Deployment Tools to deploy the first Exchange 2003 server and establish coexistence between Exchange 5.5 and Exchange 2003.

Because they want to use Cached Exchange Mode, Proseware, Inc. also upgrades all client computers in all four regional offices to Outlook 2003. They turn on Cached Exchange Mode to create a local copy of each user's mailbox. By creating the local copy before moving mailboxes, Proseware, Inc. avoids the heavy download traffic that would have occurred after moving mailboxes out of the local site. Finally, before they begin the actual site consolidation process, Proseware, Inc. runs through the process with test mailboxes. The test allows them to validate the process and gather data about network impact and replication duration.

Phase 1: Preparing for Site Consolidation Proseware, Inc. begins the site consolidation process for the Phoenix office, which is the first to be consolidated. They perform the following steps, as outlined in the Exchange Server Deployment Tools:

1. Proseware, Inc. ensures that all ADC servers are updated to the Exchange 2003 SP1 version of ADC. Then they use ADCTools to validate that all ADC connection agreements are correctly configured. 2. Proseware, Inc. updates all Exchange 5.5 public folder servers in all four regional offices with the DS/IS consistency adjuster hotfix. 3. On Friday evening, Proseware, Inc. uses PFMigrate to add public folder replicas to the Exchange 2003 server in Seattle. They allow replication to continue over the weekend.

Phase 2: Consolidating Sites in Exchange Mixed Mode After Proseware, Inc. confirms that public folder replication is complete, they continue consolidating the Phoenix site. Because moving mailboxes and using the Object Rehome tool can result in lengthy waiting periods, they decide to run this phase over the weekend. They use the Exchange Server Deployment Tools to perform the following steps:

1. Proseware, Inc. uses the Move Mailbox Wizard to move mailboxes from Phoenix to the central site. 2. Proseware, Inc. creates a logon script that will run Exprofre.exe when users log on Monday morning. This script will update users' Outlook profiles so that they reflect the new site. 3. Proseware, Inc. runs ADC Tools again to verify that the proper connection agreements are set up. They ensure that directory replication is complete. 4. They use the Object Rehome tool to update the custom recipients and distribution lists in Phoenix to reflect the Seattle site. 5. After the Object Rehome tool finishes, they run ADC Tools again to verify that the proper connection agreements are set up. They ensure that directory replication is complete. 6. On the Exchange 5.5 server in Phoenix, they run the DS/IS consistency adjuster to clean up public folder ACLs.

Phase 3: Removing the Remote Site After Phase 2 is complete, Proseware, Inc. ensures that all Exchange data is represented on the Exchange 2003 server in Seattle. Then they retire the Exchange server in Phoenix. They use the Exchange Server Deployment Tools to perform the following steps:

1. Proseware, Inc. runs PFMigrate to remove public folder replicas from the Phoenix site. 2. Proseware, Inc. uses ADC Tools to verify that the proper connection agreements are set up. They ensure that public folder replication is complete. 3. Proseware, Inc. uses the Object Rehome tool to generate a report to ensure that the distribution lists and custom recipients were successfully removed from the server in Phoenix. 4. Proseware, Inc. follows the steps for removing the Exchange 5.5 server from the Phoenix regional office. Proseware, Inc. repeats the same process for the Los Angeles and Miami regional offices. After they finish, Proseware, Inc. has an Exchange 2003 server in Seattle that hosts users in Phoenix, Los Angeles, and Miami, and they have an Exchange 2003 server in Denver that hosts those users locally. Finally, because they are no longer running Exchange 5.5, Proseware, Inc. switches to native mode. Planning Your Exchange Infrastructure

Before you begin planning your Exchange organization, it is important that you are aware of the topological boundaries and limitations, as well as the known limits for a single Exchange organization. The simpler the design the easier the topology is to maintain. As a general guideline, create as few administrative groups, routing groups, and domains as possible.

Some limits are built into Exchange. A single Exchange organization cannot exceed any of the following limits:

 1,000 Exchange servers  1,000 Administrative groups  1,000 Exchange connectors (including third-party connectors) per routing group. Note that connectors should be counted based on their number of directions. For example, a one-way connector counts as one, and a two-way connector counts as two.  100 domains

In addition to the above limits, it is recommended that you:

 Create no more than 150 routing groups  Limit the number of address lists visible to each user to 10 or fewer  Limit the number of security groups and distribution groups per user to 80 or fewer

While planning your Exchange deployment, it is important to consider the different design issues that apply to your situation. Large enterprises with complicated network environments, multiple autonomous business units, or other complexities will require more planning and attention to these matters than smaller organizations with relatively straightforward messaging needs. The topics described in the table below will help you understand different aspects of Exchange. Use this information to help plan your Exchange infrastructure. If your environment is complex, spending extra time planning and thinking through these issues will help prevent future problems.

Design Consideration Topic to review

Centralized vs. Distributed Messaging Systems. Which is right for you? Centralized vs. Distributed Messaging Systems

Routing Design. Efficient routing helps reduce network traffic and your Planning Your Exchange Server Routing Design bandwidth constraints effect your routing decisions.

Active Directory considerations and Domain Controller placement. You might Planning Exchange and Directory Server Placement have chosen to remove your Exchange servers from a branch office, but think twice before moving the domain controller.

Capacity Planning. How many servers do you need? There are tools you can use Exchange Server Sizing and Tuning to help determine the number of servers you will need. Exchange Server 2003 Performance and Scalability Guide http://go.microsoft.com/fwlink/?LinkId=47576

Front-End/Back-End configurations. If you have multiple servers and provide Exchange Server 2003 and Exchange 2000 Server Front- Internet e-mail access to your users, a Front-End Back-End configuration offers End and Back-End Topology many advantages. http://go.microsoft.com/fwlink/?LinkId=47567

Availability. If you want an e-mail system to run with minimal interruption you'll High Availability Guide for Exchange Server 2003 need to plan ahead. Decisions about hardware, service level agreements, http://go.microsoft.com/fwlink/?LinkId=47571 backup and restore strategies, and so forth are best made before you deploy your first server.

Client Access. Without clients, there is not a lot for your e-mail servers to do. Client Access Guide for Exchange Server 2003 Considering how your particular users will send and receive data will help you http://go.microsoft.com/fwlink/?LinkId=47568 make the right decisions as you roll out your Exchange organization.

Centralized vs. Distributed Messaging Systems

If your company is composed of offices all connected by high-bandwidth, reliable network connections, regardless of the distance between offices, you can implement a centralized messaging system. A centralized messaging system means that all of your Exchange servers are located and managed in a central data center and that you have a single routing group. When planning your messaging system, it is best to start with this model in mind because it is the most cost-effective and easily managed. If your company contains remote offices with low-bandwidth, high-latency, unreliable network connections, you can introduce routing groups to control how messaging traffic is routed from one location to another. However, remote locations and multiple routing groups do not prevent you from centralizing your administrative model. In addition, with the features in Microsoft Windows Server™ 2003, Exchange 2003, and Microsoft Office Outlook® 2003, you also have the opportunity to consolidate your server hardware by removing Exchange servers from remote sites. With these changes, users can log on remotely to Microsoft Windows® services and Exchange 2003 and experience fewer problems related to performance degradation or connectivity. This topic discusses the characteristics of centralized and distributed messaging systems and gives you some guidelines for planning each model. Characteristics of a Centralized Messaging System A centralized messaging system consists of a large data center that hosts all server resources, including the Active Directory® directory service global catalog servers, domain controllers, and Exchange servers. The data center supports all messaging system users, whether they connect locally or remotely. The following are characteristics of a centralized messaging system:

 Data is hosted and managed in a centralized location regardless of whether the users are connected remotely. This contrasts with the distributed model, where users have local access to mailboxes but server administration is more complex.  Software upgrades can be rolled out from a centralized location.  The data center incorporates power-insulating devices such as an uninterruptible power supply (UPS) and "hot site" or "cold site" contingencies. A hot site is a full-service commercial site that provides all of the equipment needed for a company to continue operations in the event of a disaster. A cold site is a service that provides space but that the company must furnish and set up. A hot site gets the company up and running faster, but a cold site is a less expensive option. Business requirements associated with reducing cost and security requirements are usually the driving forces behind centralizing systems. The requirements revolve around location centralization (reducing the number of sites that provide server resources), physical consolidation (replacing smaller servers with high-end servers), administrative consolidation, and data consolidation (centralizing storage solutions that provide backup and disaster recovery capabilities).

Important Considerations Consider a centralized design only if prerequisites in the following areas are already met or are included in the project plan:  Client upgrades If you plan to deploy Exchange 2003 but not Outlook 2003, offline Cached Exchange Mode is not available to users, and the experience is not improved. In fact, if network connections between client computers and the proposed data center site are slow and unreliable, you need to consider a distributed design.  Data center hardware costs Weigh the cost of installing high-end servers and clusters in the data center against the administrative cost savings of centralizing the servers. It is recommended that you cluster the back-end servers to build high availability and redundancy into the system, but this involves greater costs up front. However, these costs may be more than offset by reductions in operational costs, infrastructure costs, reduced downtime, and greater scalability.  Contingency planning When you centralize your server and data resources across the organization, you increase the possible single points of failure. You must formulate contingency plans in the event your data center is subjected to a catastrophic event.  Network outages Consider the impact that a network outage will have on users in remote locations. If the users have Outlook Cached Exchange Mode enabled, this consideration is less of an issue.  Operational and administrative cost reductions Centralizing server resources reduces operational costs because service capacity and growth are achieved with better use of resources. It also reduces infrastructure costs associated with storage and backup requirements.  Data storage With larger centralized data volumes, you must use more reliable storage systems to improve the integrity of your data. In addition, by reducing the complexity of your server infrastructure, you can more readily restore services and data when a failure occurs.  LAN and WAN connectivity If your current network does not provide the type of bandwidth and speed required for centralizing servers, you need to build a network upgrade into the project plan.  Security A centralized model gives you easier security management, thus, a greater degree of control. This control makes it easier for security staff to maintain up-to-date virus signatures and take timely action in response to security incidents. Another advantage of a centralized design is that it locates your servers in a data center that you can physically secure.

Characteristics of a Distributed Messaging System A branch office or distributed messaging deployment is one where numerous branch offices or smaller distributed sites have slow connections to a corporate hub or data center. The branches contain their own Exchange servers, domain controllers, and global catalog servers. A distributed messaging system is usually adopted when the network cannot handle traffic to a central hub for services, so the operating system and messaging servers are placed locally. User requirements may be another factor. If the requirements for user experience and availability cannot be met by connecting to a data center, you may have no choice but to place servers in the remote sites.

An Exchange branch office deployment has the following characteristics:

 The messaging system consists of a large number of locations (branches), each containing an Exchange server, domain controllers, and at least one global catalog server.  The branch office locations usually contain a small or varying number of users.  The network is usually structured as a hub-and-spoke topology.  The network connections between the branch office locations and the central hub or data center are typically low-bandwidth, high- latency, or unreliable. The main reasons behind deploying a distributed messaging system include the following:

 The company's users are dispersed across sites.  The company's network infrastructure cannot handle traffic to a central hub for services.  The user requirements dictate that a server be placed locally to provide optimal user experience and availability. Important Considerations Consider the following issues when making your decision about a distributed design:

 Software upgrades Rolling out important updates and patches can be much more challenging in a distributed messaging system.  Using RPC over HTTP If you want to use RPC over HTTP, all computers in your messaging environment that your users will need to use with RPC over HTTP communication must be running Windows Server 2003. This includes all global catalog servers and all Exchange servers that your Outlook 2003 users will access.  Operational and administrative costs Distributed messaging systems require more servers and result in higher operational and administrative costs.  Data storage With distributed servers, the service infrastructure is more complex, which makes it more difficult to restore services and data when a failure occurs.  Network connections For remote offices, it is recommended that the network connection to the hub site or data center be no less than 56 Kbps between servers. Between a hub and an office, however, a higher connection speed is recommended.  Security The physical security of servers in branch offices is a major consideration. In a branch office design, you must take precautions to ensure that servers are not located in open areas and that they are physically secured. Planning Your Exchange Server Routing Design

Your routing topology is the basis of your messaging system. You must plan your routing topology with network, bandwidth, and geographical considerations in mind. This topic explains how routing works in Microsoft® Exchange Server 2003 to create a routing topology that works with your existing systems and network and shows you how to design connectors for communicating with recipients outside your organization.

Routing describes how Exchange transfers messages from one server to another. When planning your routing topology, you need to understand how messages are transferred within Exchange and plan a topology for the most efficient transfer of messages. You also need to plan the locations of connectors to messaging systems outside your Exchange organization. Careful planning can reduce the volume of network traffic and optimize Exchange and Windows services.

When to Create a Routing Group

If any of the following factors apply, multiple routing groups may be necessary:

 Network connections don't provide the connectivity required.  Problems often afflict the underlying network.  There are multiple Exchange 5.5 sites.  Message transmission must be scheduled or controlled between different locations.  You need to set up administrative restrictions around message flow.

The topic Assessing Your Exchange Server 2003 Design Requirements describes the process of conducting a thorough assessment of your existing network infrastructure. Before you begin planning your routing design, use the information you gather about your existing network to answer the following questions:

 What is the current network topology?  What are the connections between locations, including available bandwidth and latency?  What other applications use bandwidth, and what applications are planned for the future?  How many users are at each location?  Where are the users located, and what are their usage patterns? With which groups do they communicate?  What type of business does your company conduct? Consider tools that are already using bandwidth (for example, point-of-sale systems).  Where are the data centers?  Where are your Internet access points?  Do you need access to public folders across locations? Do you have applications or public folder usage across different locations?  Do you need to share free/busy information across locations? (Remember that free/busy information is handled in the same way as public folder referrals.)  What is the current Active Directory design, and where are global catalog servers and domain controllers placed? How are the Windows sites designed (in other words, do they correlate to routing groups)? Important Considerations

Connectors between routing groups are ways to funnel mail; in fact, too many connectors can have a negative impact on message flow. For this reason, try to avoid creating too many routing groups; it is recommended that you not exceed 150 routing groups. However, in situations where you have multiple connections to a possible destination, you can define connectors between routing groups to control message flow. Within a routing group, communication between servers is point-to-point, so you cannot determine paths and costs to ensure the least expensive route between two servers is chosen. However, by creating routing groups, you can assign costs to various paths to ensure the most efficient route is used.

In addition to planning routing groups internal to your organization, you also need to plan the locations of connectors to messaging systems outside your Exchange organization.

Planning Exchange and Directory Server Placement

Because Exchange uses Active Directory, it is crucial that you consider your Windows Server network topology as you plan your Exchange deployment. In general, for best performance, you should make sure you have at least one global catalog server in each Windows site where Exchange is installed. Although Windows Server 2003 allows users to log on even without a local global catalog server, Exchange still requires a local global catalog server. In addition, using multiple domain controllers within domains distributes the lookup traffic and provides redundancy if a domain controller fails. For more information about planning Windows sites, domains, and domain controllers, see the Windows Server documentation (http://go.microsoft.com/fwlink/?LinkId=34153).

Active Directory Server Placement

The following list summarizes the recommendations for placement of Active Directory domain controllers and global catalog servers to support your Exchange organization:

 Ensure that DNS is correctly configured at the hub site and all branches. Ensure that name resolution and DNS functionality are both operating correctly.  Ensure that the server assigned the infrastructure master role is not a global catalog server.  In branch offices that service more than 10 users, one global catalog server must be installed in each location that contains Exchange servers. Deploying two global catalog servers for redundancy is ideal. If a physical site does not have two global catalog servers, you can configure existing domain controllers as global catalog servers.  Exchange requires WINS.

This topic provides information about where to place global catalog servers and domain controllers.

Domain Controllers

In most deployment scenarios, you should not run Exchange 2003 on computers that also function as Windows domain controllers. Instead, you should configure Exchange servers and Windows domain controllers as separate computers because if Exchange is running on a domain controller, it uses only that domain controller. If the domain controller fails, Exchange cannot fail over to another domain controller. Furthermore, if your servers running Exchange do not have to perform domain controller tasks in addition to serving Exchange client computers, the performance of those servers under heavy user loads improves.

To help ensure the safety of your Active Directory information, store the information on more than one domain controller. In the event that one of the servers experiences a problem, you should have at least two domain controllers to help secure your Active Directory information.

In addition, ensure that you have a solid backup plan for your domain controllers. In Exchange 5.5, by backing up the Dir.edb file, you were backing up a server's directory information. With Exchange 2000 and Exchange 2003, however, Exchange information is held in Active Directory, and domain controller backups are critical. Ensure your Windows infrastructure supports backup and reliability of this information.

For more information about backup and restore, see the Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570).

Global Catalog Servers

Global catalog servers are required for logon because they contain information about universal group membership. This membership grants or denies user access to resources. If a global catalog server cannot be contacted, a user's universal membership cannot be determined and log on access is denied.

Note:

Although Windows Server 2003 provides features that do not require a local global catalog server, you still need a local global catalog server for Exchange and Outlook to use. The global catalog server is critical for Exchange services (including log on, group membership, store services) and access to the global address list (GAL). Deploying global catalog servers locally to both servers and users makes address lookups more efficient. Contacting a global catalog server across a slow connection increases network traffic and impairs the user experience.

Consider the following when placing global catalog servers:

 All Exchange servers and users should have fast access to a global catalog server.  At least one global catalog server must be installed in each domain that contains Exchange servers.  There should generally be a 4:1 ratio of Exchange processors to global catalog server processors, assuming the processors are similar models and speeds. However, depending on your situation, higher global catalog server usage, a large Active Directory, or large distribution lists can necessitate more global catalog servers. Exchange Servers

Determining where to place Exchange servers depends on whether your messaging system is centralized or distributed. Use the information you have gathered about service level agreements, user requirements, and the versions of software that you will deploy in the organization to determine whether users need access to a local Exchange server.

Mailbox Servers For remote locations connected by slow or unreliable network connections, you need to determine how any interruptions in service affect the business and to what extent interruptions are acceptable. If access to updated Exchange data at all times is critical, you need to place Exchange servers in the remote locations. If, after weighing the costs of deploying additional servers against cost savings of a more centralized model, you decide that a certain level of service interruption is acceptable, you may be able to deploy all Exchange servers in a data center. Recall that in this case, if you want to take advantage of features such as Cached Exchange Mode and RPC over HTTP to improve the experience for remote users, you may need to also consider upgrading to Windows Server 2003 and Outlook 2003.

Public Folder Servers

As discussed previously, if your organization is made up of multiple remote locations, you can place public folder replicas on local Exchange servers so that each location has a replica of public folders from other locations. Or, you may want to consider storing all public folder information in a central server in the data center or hub so that you maintain a single, accurate source of data. This decision is based on the balance between accuracy and convenience and depends on user requirements and usage patterns.

Free/Busy Servers

One of your main considerations is access to free/busy information. Without a local copy of free/busy folder data, users may experience a delay in receiving other users' free/busy information when scheduling meetings. Consider how users in your organization schedule meetings. The requirements surrounding access to updated scheduling information can vary among companies. If it is critical that users always have access to up-to-date scheduling information, you need to host free/busy folders in a centralized location. If the need for up-to-date information is not as critical as the need for fast access, you can deploy local Exchange servers to host free/busy information, recognizing that delays in receiving updated free/busy information over the network may occur. You should determine what level of delay is acceptable to your business.

If you decide to host free/busy information on local Exchange servers, the other consideration is whether to place copies of other free/busy information from other locations on the local server. If users in different locations rarely schedule meetings with each other, you do not necessarily have to keep local replicas of free/busy information from other locations. However, if you decide to keep local copies of public folders from other locations, note that the replication schedule defined for a public folder determines when its changes are propagated. If replicas of free/busy information are maintained across multiple locations, it may take time for changes in one location to propagate to the other locations. Thus, a user might consult the local free/busy data while scheduling a meeting, but the free/busy data is out of date because schedule changes made in another location have not yet replicated.

Offline Address List Servers

Exchange 2003 uses Active Directory to provide offline address list services. The address list files that Exchange generates are stored in a public folder. Users working offsite can connect to Exchange and download these offline address lists remotely to retrieve information about other users in the organization.

When you generate an offline address list, address lists specified for the offline address list are converted to a single data file and stored in a system public folder. When users download the offline address list, this data file is used as the source of information.

You must choose an appropriate server to generate and update offline address lists. The more address lists contained in an offline address list, the harder the server chosen for the offline address list must work.

If you use Cached Exchange Mode, you should consider the impact on the server when users download offline address lists. This impact could be significant, not only the first time users download offline address lists, but on a daily basis. You may want to consider setting up one or two servers to handle offline address books.

Exchange Server Sizing and Tuning

To determine the number of Exchange servers you need to handle user load, use the following capacity planning tools:

 Microsoft Exchange Server Load Simulation Tool (LoadSim.exe)  Exchange Stress and Performance (ESP) tool  Jetstress 

Important:

Because some of these tools create accounts that have insecure passwords, these tools are intended for use in test environments, not in production environments.

Microsoft Exchange Server Load Simulation Tool

With Microsoft Exchange LoadSim, you can simulate the load of MAPI clients against Exchange. You simulate the load by running LoadSim tests on client computers. These tests send messaging requests to the Exchange server, causing a load on the server.

Use the output from these tests in the following ways:  To calculate the client computer response time for the server configuration under client load  To estimate the number of users per server  To identify bottlenecks on the server

For more information about the LoadSim tool or to download LoadSim, see Exchange 2003: Load Simulator 2003 (LoadSim) (http://go.microsoft.com/fwlink/?LinkId=27882).

Exchange Stress and Performance Tool

The Exchange Stress and Performance tool (ESP) is a highly scalable stress and performance tool for Exchange. It simulates large numbers of client sessions by concurrently accessing one or more protocol services. Scripts control the actions each simulated user takes. The scripts contain the logic for communicating with the server. Test modules (DLLs) then run these scripts. Test modules connect to a server through Internet protocols, calls to application programming interfaces (APIs), or through interfaces like OLE DB.

ESP is modular and extensible and currently provides modules for most Internet protocols, including the following:

 Web Distributed Authoring and Versioning (WebDAV)  Internet Message Access Protocol version 4rev1 (IMAP4)  Lightweight Directory Access Protocol (LDAP)  OLE DB  Post Office Protocol version 3 (POP3)  Simple Mail Transfer Protocol (SMTP)

For more information about the ESP tool or to download ESP, see the Microsoft Exchange 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?LinkId=21316).

Jetstress

Exchange 2003 is a disk-intensive application that requires a fast, reliable disk subsystem to function correctly. Jetstress (Jetstress.exe) is a tool in Exchange to help administrators verify the performance and stability of the disk subsystem prior to putting their Exchange server into production. For more information about Jetstress, see "Exchange Server 2003 Jetstress Tool" (http://go.microsoft.com/fwlink/?linkid=27883).

Optimizing Memory Usage

A server's virtual address space usage determines a mailbox server's overall performance and scalability. When virtual memory runs low, performance decreases dramatically. Although Exchange 2003 automatically optimizes usage for small- to medium-sized servers, additional tuning is necessary for servers with more than 1 GB of physical memory.

For more information about monitoring and optimizing memory usage on your servers, see Optimizing Memory Usage for Exchange Server 2003.

Optimizing Memory Usage for Exchange Server 2003

This topic contains information about monitoring and optimizing memory usage on your servers.

Monitoring Memory Usage

You can monitor the Event Viewer application log and Performance Logs and Alerts (Performance on the Administrative Tools submenu) for virtual memory problems. In the application log, a 9582 warning appears when the largest free block of virtual memory decreases to 32 MB. If you see this, you should restart the Exchange store process at the next opportunity. If the largest block decreases to 16 MB, a 9582 error appears again; this error means the server could fail, and you should restart the server at the earliest opportunity. Failure to act on these events could result in sporadic mail delivery and IMAIL conversion failures (12800 events).

In Performance Logs and Alerts, monitor the following counters:

 VM Largest Block Size counter in the MSExchangeIS object: A healthy server has more than 200,000,000 bytes (200 MB) as the largest free block. If the value is lower, you should carefully monitor the server.  Pool Pages Bytes in the Memory object: Amounts greater than 200 MB indicate a problem except when backups are running. During backups, each page in the cache manager is backed by a pool page.  Pool Nonpaged Bytes in the Memory object: Amounts greater than 100 MB indicate a problem.  Free System Page Table Entries in the Memory object: Amounts less than 3000 indicate a problem.  Working Set in the Process object: An upward trend indicates a potential memory leak. If a server shows signs of low virtual address space, you should adjust the following settings. If these settings are not optimized for Microsoft® Exchange, event 9665 appears in Event Viewer.

 If the server is running Microsoft Windows® 2000 Advanced Server or Windows Server™ 2003 and has 1 GB or more of physical memory, set the /3GB switch in the Boot.ini file as described below.  If the server is running Windows Server 2003 (any edition), configure the /USERVA switch and SystemPages registry key as described below. If the server is running Windows 2000, ensure that Windows 2000 SP3 or later is installed.  If the server has 1 GB or more of physical memory, set the HeapDeCommitFreeBlockThreshold registry parameter as described below.  Tune the store database cache size if necessary as described below.

Event 9665

Exchange performs an optimal memory configuration check when the store process starts. If the memory settings are not optimal, you see event 9665 in Event Viewer. This message appears in the following instances:

 The server is running Windows 2000 and the SystemPages value in the registry is set outside the range of 24000 to 31000.  The server has 1 GB of memory or more and does not have the /3GB switch.  The server is running Windows Server 2003, has 1 GB of memory or more and the /3GB switch is set, but the /USERVA setting is not present or not set to 3030.

If you see this event, check the SystemPages and HeapDeCommitFreeBlockThreshold settings in the registry, as well as the /3GB switch and the /USERVA setting in the Boot.ini file. The following sections contain recommendations for each of these settings.

Note:

If you want to turn off the logging of event 9665, you can create the registry key shown in the following table. Registry key to turn off memory configuration check Path HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\

Parameter Suppress Memory Configuration Notification

Type REG_DWORD

Setting 1

Note:

The memory configuration check does not occur on servers running Microsoft® Small Business Server.

Setting the /3GB Switch

By default, Windows 2000 Advanced Server and Windows Server 2003 allocate 2 GB of virtual address space to user mode processes such as Store.exe. If a server has 1 GB or more of physical memory, set the /3GB switch in the Boot.ini file to increase virtual address space.

You should only set the /3GB switch on servers that meet the following criteria:

 The server hosts Exchange 2003 mailboxes or public folders.  The server has 1 GB or more of physical memory.

It is not recommended that you set this switch on Exchange servers that do not contain public folder or mailbox stores.

For more information about the /3GB switch, see Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096).

Important:

The /3GB switch is designed for Windows 2000 Advanced Server and all editions of Windows Server 2003. Do not set the /3GB switch in Windows 2000 Standard Edition. Configuring /USERVA and SystemPages

If the server is running Windows 2000, you should set the SystemPages registry key to a value between 24000 and 31000. The SystemPages registry key is located in the following path:

Copy Code HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

If the server is running Windows Server 2003, set the SystemPages value to zero, and set the /USERVA=3030 parameter in the Boot.ini file. These settings let you enter more system page table entries on the server, which is critical for scale-up systems.

For additional information, see Knowledge Base article 810371, "XADM: Using the /Userva Switch on Windows 2003 Server-based computers that are running Exchange Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371).

Setting the HeapDeCommitFreeBlockThreshold Registry Key

The HeapDeCommitFreeBlockThreshold registry key controls the amount of free space required before the heap manager decommits (or frees up) memory. The default is zero, which means that the heap manager decommits each 4-KB page that becomes available. Over time, virtual address space can become fragmented. On servers that have 1 GB or more of physical memory, you can set the registry key to a higher value to reduce or eliminate fragmentation. Set the registry key as shown in the following table , and then restart the server. For more information about the HeapDeCommitFreeBlockThreshold registry key, see Knowledge Base article 315407, "XADM: The 'HeapDeCommitFreeBlockThreshold' Registry Key" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=315407).

Settings for the HeapDeCommitFreeBlockThreshold registry key

Path HKLM\SYSTEM\CurrentControlSet\Control\Session Manager

Parameter HeapDeCommitFreeBlockThreshold

Type REG_DWORD

Default Zero

Recommended setting* 262144

* This value is the number of blocks in decimal. The recommended value is 262144, which corresponds with a hexadecimal value of 0x00040000.

Adjusting the Store Database Cache Size

The store database cache (also referred to as the Extensible Storage Engine buffer) caches database transactions before they are committed to the database. By default, Exchange 2003 allocates 896 MB if the /3GB switch is set on the server and 576 MB if the /3GB option is not set. In the following instances, adjusting the maximum buffer size can increase performance:

 If the server is running Exchange 2003 and other server-side applications, reduce the buffer to limit the use of memory by Exchange.  On servers with more than 2 GB of memory, increase the size of the buffer (up to a maximum of 1200 MB).

Before you increase the maximum buffer size, use Performance Logs and Alerts to monitor the store instance of the Virtual Bytes counter (in the Process object) under normal load. The Virtual Bytes counter shows the current size (in bytes) of the virtual address space that the Store.exe process uses. The value should be below 2.8 GB if the /3GB switch is set and below 1.8 GB if the /3GB switch is not set. If the values are higher, do not increase the maximum buffer size. If the values are lower, you can increase the maximum buffer size up to 1,200 MB. For example, if the /3GB switch is set, and the virtual bytes count is 2.5 GB under heavy load, you can increase your maximum buffer size by approximately 300 MB.

Be aware that on servers experiencing address space fragmentation issues, increasing the buffer size may negatively affect server performance. A larger buffer means more virtual address space consumption; increasing the buffer may result in system instability.

To adjust the maximum buffer size, use Active Directory Service Interface (ADSI) Edit to modify the msExchESEParamCacheSizeMax value. For more information about how to modify the msExchESEParamCacheSizeMax value, see Knowledge Base article 266768, "XSTR: How to Modify the Store Database Maximum Cache Size" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768). After you set the value, wait for the Active Directory® directory service to replicate the value throughout the forest. Then restart the Microsoft Exchange Information Store service.

Important:

Be careful not to choose the msExchESEParamCacheSizeMin value.

The following table summarizes maximum buffer size default values and recommendations. The value is expressed as a page count and should be set to an exact multiple of 8192 for maximum efficiency.

Buffer size default values and recommendations

Default size on /3GB servers 229376 (896 MB) Default size on non /3GB servers 147456 (576 MB)

Recommended maximum 311296 (1.2 GB)

Very large address-space-constrained servers 196608 (768 MB)

Exchange Server 2003 Server Consolidation

As e-mail messaging continues to grow in both volume and business importance, organizations are looking for new options to manage future demand in a reliable and cost-effective way. One option is to build a messaging strategy based on advanced technologies available in Microsoft® Windows Server™ 2003 and Microsoft Exchange Server 2003. These topics discuss strategies for server consolidation using Exchange 2003.

For more information, see the following topics:

 Introduction to Exchange Server 2003 Server Consolidation  Improvements in Performance and Scalability in Exchange 2003  Improvements in Client/Server Communication in Outlook 2003 and Exchange Server 2003  Server Consolidation Strategies Using Exchange Server 2003  Moving Exchange Server 2003 to New Hardware  Deciding to Consolidate Exchange Messaging Systems  Server Consolidation Recommendations  Conclusion to Exchange Server 2003 Server Consolidation

Introduction to Exchange Server 2003 Server Consolidation

As e-mail messaging continues to grow in both volume and business importance, organizations are looking for new options to manage future demand in a reliable and cost-effective way.

One option is to build a messaging strategy based on advanced technologies available in Microsoft® Windows Server™ 2003 and Microsoft Exchange Server 2003. Enterprise-scale messaging servers are the key to reducing the overall number of servers, as well as the number of server sites in the organization, thus streamlining messaging infrastructure and lowering administrative overhead. Information Technology analysts suggest that server and site consolidation can help an organization to realize significant savings in operational costs.

In a recent study, META Group concludes that by accommodating more users per Exchange server, organizations can reduce operational costs by approximately $240,000 to $600,000 annually. For more information, see Exchange 5.5 Migration to Exchange 2003 Cost-Saving Scenarios.

For example, Microsoft upgraded to Exchange Server 2003, reducing 113 mailbox servers in 75 sites to 38 mailbox servers in seven geographical locations worldwide. The organization has approximately 85,000 users and manages approximately 3,500,000 internal e-mail messages and 2,500,000 Internet e-mail messages per day.

This example is not unique. Siemens is upgrading to Exchange 2003 and consolidating more than 150 Exchange organizations into a single organization. The window and door manufacturer, Pella, upgraded to Exchange 2003 and consolidated 16 Exchange servers to six Exchange servers. Timex upgraded to Exchange 2003 and consolidated its nine e-mail servers to only two e-mail servers.

Each of these examples demonstrates that organizations can benefit from site and server consolidation using Exchange 2003. If your organization includes multiple messaging systems, servers, or locations, you can benefit from a consolidation based on Exchange 2003.

Improvements in Performance and Scalability in Exchange 2003

Improving performance and scalability has always been an important design goal for the Exchange product development team. The first Exchange product, Microsoft® Exchange Server 4.0, was designed to replace MS Mail for PC Networks. MS Mail could host no more than 500 mailboxes per post office. Most organizations, however, required a more enterprise-ready messaging platform. The information store in Exchange Server 4.0 and Microsoft Exchange Server 5.0, in contrast, could hold up to 16 GB of data and more than 500 mailboxes. Storage capacity was further increased in Microsoft Exchange Server 5.5. Exchange Server 5.5 Enterprise Edition featured an unlimited Exchange information store. Now organizations could place any number of mailboxes on a single server, and Exchange databases could quickly grow to enormous sizes of several hundred GB. With its large database sizes, however, the messaging system was difficult to maintain. Although the number of mailboxes that could be contained within the Exchange store was theoretically unlimited, 1,000 mailboxes per server was the approximate practical limit. Increasing the practical number of mailboxes per server was a major design goal for Microsoft Exchange 2000 Server. Exchange 2000 Server featured support for multiple storage groups and could hold up to 20 mailbox and public folder databases. When mailboxes were distributed over a number of mailbox stores, servers could host 2,000 or more mailboxes. The individual databases nevertheless remained manageable. Exchange 2003 improves upon Exchange 2000 in the areas of performance, scalability, and security. Exchange 2003 continues to support multiple storage groups and messaging databases, features an additional Recovery Storage Group, and supports the Volume Shadow Copy service of Windows Server™ 2003. Exchange 2003 uses improved caching algorithms so that directory lookups can be completed more efficiently, resulting in a 60 percent reduction of Microsoft Active Directory® directory service queries compared with Exchange 2000. Virtual memory management is improved also, and the propagation of link state information between servers is optimized to reduce network traffic. Also noteworthy is the high level of virus and spam protection that you can achieve by using Exchange 2003. Upgrading to Exchange 2003 from previous versions of Exchange, especially Exchange Server 5.5, offers clear incentives.

Improvements in Client/Server Communication in Outlook 2003 and Exchange Server 2003

The more mailboxes an organization places on a single server, the more client connections the server must manage. Consequently, optimizing client/server communication is an important aspect of server consolidation. Microsoft® Office Outlook® 2003 is an ideal messaging client for Exchange 2003. This client contains numerous features that are specifically designed to reduce network bandwidth consumption and improve the e-mail experience of users over remote connections in an Exchange 2003 organization. The following are key improvements that you can make in client/server communication by using Outlook 2003. These improvements enable you to place a large number of mailboxes on a single server running Exchange 2003:

 MAPI compression and buffer packing When you use Outlook 2003 in an Exchange 2003 organization, mailbox content is compressed on the Exchange server before being sent to the Outlook 2003 client. In addition, the data is packaged in large, optimized buffer packets, thereby reducing the number of requests that must be transferred over the network between the Outlook client and the server running Exchange 2003. Both MAPI compression and buffer packing significantly lower the network bandwidth requirements for client/server communication and enable an Exchange server to manage an increased number of users with acceptable response times.  Exchange cached mode This feature enables Outlook 2003 to download all items from the server-based mailbox and keep them synchronized in a cache on the local client computer. After a full copy of the mailbox is downloaded, the client performs most e-mail related tasks from the local computer. Communication with the server is only required during offline folder synchronization, when downloading new items to the client computer, when uploading added or changed items to the server, or when sending messages. The following figure illustrates the Exchange cached mode principle.

Synchronizing server-based mailbox content in Exchange cached mode

Exchange cached mode can potentially reduce both the workload of servers and the consumption of network bandwidth. Exchange cached mode also improves the remote or branch office user's experience of Outlook 2003. Access to items stored in the local cache is always fast, no matter how slow or unreliable the network connection, and access to the items stored in the local cache does not depend on server availability. Because the client works with a local copy of the data, users do not need to restart Outlook 2003 to an offline profile when network interruptions occur or when the server is shut down temporarily for maintenance reasons. In Exchange cached mode, users can choose from the following download options.

 Download full items This is the default setting and the best option when you use Exchange cached mode over fast and reliable network connections. The client downloads all items to the client immediately.  Download headers first and then full items In this option, the client first performs a header download, so that users can immediately see a list of new items. Following the header download, the client performs a full download to bring all data to the client. This option might be a good choice if users want immediate access to new messages, but note that this mode requires an extra cycle of client/server communication compared with downloading full items.  Download headers only This is the best option when you use Exchange cached mode over slow and unreliable network links, such as dial-up connections. The client downloads the message headers only, so that users can see the size of e-mail messages and attachments, and then decide which items to download or delete directly on the server. The client downloads a message when users open it in Outlook 2003.

Note:

Because of its many advantages, it is recommended that you enable Exchange cached mode over local as well as remote network connections.

 Improved Outlook 2003 synchronization performance Outlook 2003 performance in Exchange cached mode is further improved by reducing the number of change notifications between client and server. The server informs the client about the number and size of messages to be downloaded, and when items are marked read or unread, are flagged, or are modified in other ways, only the header listing the change is sent back to the server. When full items are downloaded, MAPI compression ensures efficient data flow. It is important to understand that the synchronization in Outlook 2003 is incremental. That is, if a synchronization cycle is interrupted, the synchronization process resumes where the interruption occurred, instead of resuming the entire synchronization process. Items marked as corrupted or conflicting are moved to the Sync Items folder, allowing synchronization to continue. Users see a synchronization progress meter in the lower right corner of the Outlook 2003 client. The progress meter shows detailed synchronization information, such as the total amount of data left to synchronize, and whether the mailbox folders are up-to-date.  Outlook 2003 performance monitoring Outlook 2003 collects performance information and sends it to Exchange 2003 so that an Information Technology administrator can identify performance bottlenecks relating to poor bandwidth conditions or poor connectivity. The performance data is stored in the Exchange store, as well as reported in the event log and through performance counters. To monitor response times on a continuous basis and to create performance reports over any period of time, you can use either non-Microsoft tools or Microsoft tools, such as Exchange 2003 Management Pack (Exchange Management Pack.akm) for Microsoft Operations Manager. Analyzing the performance data on a centrally located server can help an Information Technology department identify when local and remote clients are experiencing connectivity issues.

Server Consolidation Strategies Using Exchange Server 2003

By using Microsoft® Exchange Server 2003, an organization can improve its level of service through increased system reliability. In addition, an organization can create a highly flexible infrastructure so that future growth can happen in a controlled way. Organizations that deploy Exchange 2003 can achieve these objectives by using the following general strategies:

 Consolidate multiple small servers on fewer large servers You can use Exchange 2003 to accommodate more users per server than by using any previous version of Exchange, while maintaining usable backup windows. Exchange 2003 runs on Windows Server™ 2003 clusters with up to eight nodes. Backup agents can use the new Volume Shadow Copy service available in Windows Server 2003 to greatly reduce the time required for Exchange 2003 backup operations. Exchange 2003 also features a Recovery Storage Group and a Mailbox Recovery Center. You can use the Recovery Storage Group to restore individual mailboxes from a database backup quickly and conveniently. The Mailbox Recovery Center, on the other hand, provides bulk reconnection of mailboxes to the appropriate users in Active Directory®, which supports disaster recovery scenarios.  Physically move servers from multiple geographic locations to one central location This approach is often referred to as site consolidation and entails placing all servers in a data center. Outlook® 2003 enables site consolidation in an Exchange 2003 organization. With over-the-wire MAPI compression and client-side caching in Exchange cached mode, Outlook 2003 is more resilient under unstable network conditions and requires less network bandwidth than any previous version of Outlook 2003. Site consolidation helps to lower administrative overhead, and makes it easier for information workers to access messaging resources when they work remotely.  Automate the maintenance of multiple servers using a reduced number of management interfaces This approach is sometimes referred to as virtual consolidation, which means managing multiple servers as one virtual server system. Individual servers may reside in a data center or in different geographic locations. Integration with Active Directory and new administration tools, such as Exchange 2003 Management Pack (Exchange Management Pack.akm) for Microsoft Operations Manager, are key catalysts for virtual consolidation in Exchange 2003 organizations. For example, Exchange Management Pack.akm, included in Exchange 2003, enables organizations to monitor the performance, availability, and security of all Exchange servers in the organization from a single Microsoft Operations Manager console or Web page. Moving Exchange Server 2003 to New Hardware

This section explains how to move an existing Exchange Server 2003 to a new computer and how to keep the same server name on the new hardware. Exchange Server 2003 can be running Enterprise or Standard edition.

You could be moving the Exchange server to newer hardware because the organization's e-mail needs are growing. For more information about moving an Exchange Server 2003 and keeping the same server name, see How to Move Exchange Server 2003 to New Hardware and Keep the Same Server Name.

Note:

If you are moving an existing Exchange Server 2003 to new hardware and want to have a different server name, perform a Move Mailbox operation to move the mailboxes and then rebuild the Exchange server. For More Information

For more information, see the following Microsoft Exchange TechCenter and Microsoft Knowledge Base articles:

 Moving Exchange Mailbox Databases Between Storage Groups in Exchange Server 2003.  Moving mailboxes in Exchange Server 2003  Move Mailbox improvements in Exchange 2003  How to move Exchange databases and logs in Exchange Server 2003 How to Move Exchange Server 2003 to New Hardware and Keep the Same Server Name

This section explains how to move a Microsoft Exchange Server 2003 (Enterprise or Standard edition) to a new computer, and explains how to keep the same server name on the new hardware.

To move Exchange 2003 to a new computer and keep the same server name, the new computer must have the same operating system installed as the original computer. To move Exchange 2003 to the new computer, follow the procedure below.

Before You Begin

If the Exchange 2003 computer is a domain controller, you must be aware of some important considerations. For additional information, see the following Microsoft Knowledge Base articles:

 298450, Deletion of Critical Objects in Active Directory in Windows 2000 and Windows Server 2003  257288, How to Recover from a Deleted Domain Controller Machine Account in Windows 2000 Procedure To move an Exchange 2003 to new hardware keeping the same server name

1. Make a full backup of all the Exchange 2003 storage groups and the Site Replication Service (SRS) database on the existing Exchange 2003 computer. 2. Take the existing Exchange 2003 computer offline. 3. Reset the computer account for the existing Exchange 2003 computer. To do so, follow these steps: a. Start Active Directory Users and Computers. b. Locate the computer account for the existing Exchange 2003 computer, right-click the computer account, and then click Reset Account. 4. Bring the new computer online, and then confirm that the new computer is running the same operating system that was installed on the existing Exchange 2003 computer.

Note:

Make sure the new computer has a unique computer name on the network. 5. Rename the new computer to the same name as the original computer, and then join this computer to the domain.

Note:

You must not delete the original computer account from the domain before you join the new computer to the domain. Additionally, do not delete the original Exchange server from Exchange System Manager. 6. Use an Exchange 2003 Full Administrator account to log on to the new computer. 7. Install any components that Exchange 2003 requires, such as the NNTP service, the SMTP service, and the World Wide Web service. 8. Configure drive letters on the new server to map to or match the configuration of the old server, for drives that contained Exchange data, with sufficient space to accommodate the restored data. 9. Run Exchange 2003 Setup with the following parameter: Setup /disasterrecovery Make sure that you click Action-Disaster Recovery for the Messaging and Collaboration services and for Exchange System Management Tools. 10. When the Setup program has completed, install the Exchange 2003 service pack that was installed on the existing server by using the /disasterrecovery switch. 11. Examine the registry to see if the following registry subkey exists: HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup If the HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup subkey does not exist, add a DWORD value and the following hexadecimal value, based on the service pack value: DWORD value name: ServicePackBuild Hexadecimal value: number The number for the hexadecimal value varies based on the service pack as follows:  The hexadecimal number for the original release version without a service pack installed is 1B20  The hexadecimal number for Service Pack 1 is 1C3A  The hexadecimal number for Service Pack 2 is 1DD6 12. Install any Exchange 2003 post-service pack hotfixes that were installed on the existing server. 13. In separate restoration jobs, restore the storage groups and the Site Replication Service (SRS) database from the Exchange 2003 server backup. 14. Mount all the stores after the restoration is complete. Make sure that clients can connect and that mail can flow.

Note If the IP address of the Exchange 2003 computer changes, make sure that you update Domain Name System (DNS) records. If you do not update DNS records, other servers may try to connect to the previous address.

For More Information

For more information about how to move Exchange 2000 to new hardware and to keep the same server name, see the Microsoft Knowledge Base article 297289, "How to move Exchange 2000 to new hardware and keep the same server name."

For information about resolving problems when you try to mount a store, see the Microsoft Knowledge Base article 299680, "Error 0x80040102 occurs when you try to mount a store."

Deciding to Consolidate Exchange Messaging Systems

The decision to consolidate messaging systems should be based on an assessment of an organization's existing infrastructure. This assessment should include a graphical representation of the environment that illustrates the various regions that are administered separately, as well as the servers within these regions that store mailboxes, run messaging connectors, manage incoming browser connections, or perform other tasks. The assessment should also include a basic network analysis because network reliability and available bandwidth significantly influence the consolidation strategy.

The following figure illustrates a recommended approach to identifying consolidation opportunities.

Determining server consolidation opportunities

You should address server consolidation strategy questions in the following order:

 Is it possible to implement a central administration model? The administration of Microsoft® Exchange Server 2003 is not bound to the physical network structure, so an organization can implement a centralized administration model for Exchange Server 2003—even across multiple geographical locations. A centralized administration model is better suited to server consolidation than is a decentralized model, because it is usually impossible to consolidate servers across regions that require independent administration. If you cannot implement a completely centralized administration, consider implementing a hybrid model in which a different Information Technology department is responsible for each individual geographical region in the organization. Each department is then centrally responsible for all those remote locations that belong to its assigned region. It might then be possible to consolidate servers into regional data centers.  Is it possible to consolidate remote locations into a data center? Remote locations that fall under the same administrative authority are good candidates for site consolidation if sufficient network bandwidth is available to support client/server communication with acceptable response times. As mentioned previously, Outlook® 2003 in Exchange cached mode can work over slow or unreliable network connections. However, you should conduct performance tests and pilot projects to determine whether the existing bandwidth is sufficient. An organization might have to upgrade network connections that cannot accommodate the workload, or refrain from eliminating mailbox servers in regional offices.

Note:

To estimate bandwidth requirements, consider the number of users that connect to Exchange 2003 over the network link, the client type used to access mailboxes (for example, Outlook 2003 in Exchange cached mode or Microsoft Office Outlook Web Access), and user habits (for example, e-mail users who communicate frequently compared with e-mail users who communicate infrequently). You must also take into consideration processes that do not relate to Exchange-based client/server communication; for example, file and printer sharing or Active Directory® replication.

 Is it possible to consolidate servers within each location? To identify servers that can be consolidated within a data center or geographical location, you must analyze the various tasks that the existing servers currently manage. Some server types are more eligible for an actual physical consolidation than others. For example, some servers might be responsible only for storing mailboxes (mailbox servers), while others might serve only the purpose of message transfer (bridgehead servers). You should consolidate mailbox servers, but it is not necessarily a good idea to consolidate bridgehead servers or Web servers onto mailbox servers in large organizations. Bridgehead servers and Web servers, due to their need for high network bandwidth, are more suited for server farms that are based on load-balancing technologies, such as Microsoft Application Center 2000.

Note:

Server consolidation is primarily a way to concentrate user data onto a small number of servers by using a sophisticated storage subsystem. Servers that hold mailboxes and public folders are most suited for server consolidation.

 Is it necessary to replace the existing server hardware in order to manage the expected workload? After you identify the servers that can be consolidated, calculate the final number of users that each of these servers must support. Based on these figures, estimate each server's approximate workload to determine its hardware requirements. Consider whether the existing server hardware can accommodate future demands. Reusing existing hardware might help to reduce costs, but do not upgrade existing Pentium Pro or Pentium II multi-processor computers to Windows Server™ 2003 and Exchange 2003. Intel discovered that an upgrade to Windows Server 2003 on servers that have two or more Pentium Pro or Pentium II processors might cause instability, data corruption, or other unpredictable results. Upgrading these platforms will force Windows Server 2003 into single-processor mode, which is a supported configuration. However, a single processor that is operating at 200 MHz is not a good choice for server consolidation. When you consolidate onto fewer servers, consider replacing existing server hardware and storage technology. The following table lists basic processor and memory configuration recommendations for mailbox servers. Processor and memory configurations for mailbox servers

Number of Users CPUs Memory

Fewer than 500 1 - 2 512 MB – 1 GB

500 – 1,000 2 - 4 1 GB – 2 GB

1,000 – 2,500 4 - 8 2 GB – 4 GB

2,500 or more 4 - 8 4 GB

Note: The figures in Table 1 are recommendations for an optimal configuration. It is possible to support a greater number of users and at the same time, use less hardware. Microsoft, for example, is currently operating a number of four-processor Exchange 2003 servers that have 4,500 mailboxes each. Server performance can be improved by using additional processors, but the four-processor configuration works.

The following factors influence your Exchange server hardware design:

 Connected users versus total users When you design server hardware, estimate how many users will connect to the server concurrently. For example, performance requirements might be lower if not all users connect at the same time; for example, when users work in shifts. However, the server background activity increases as the number of mailboxes increases, even when users have not logged on to the system. For example, database defragmentation activity increases on a server storing thousands of mailboxes. Always consider background activities when you design server hardware.  Location and use of message stores Exchange users can store their messages in server-based mailboxes or in personal folders (.pst files) on their local client computers or on a network drive. Users can reduce a server's storage and processing workload by setting their default delivery locations for messages to their personal folders. For example, when a user opens or saves an item in a personal folder, the Microsoft Exchange Information Store service on the server is not involved. However, when you decide whether to use personal folders in this way, consider the fact that storing all messages in personal folder stores on local client computers makes it impossible to back up messages centrally.

Note:

To require users to store messages in .pst files on their client computers, configure mailbox quotas for the mailbox stores. If a mailbox exceeds its size limits, the user must reduce the amount of data by downloading messages to the .pst file or deleting them. Otherwise, the user cannot continue to receive and send e-mail messages.

 User habits and messaging clients When you design server hardware, consider the number of messages users send and receive per day. Also consider the types of clients that they use. Outlook 2003 and Outlook Web Access 2003 place different workloads on a server. If your users primarily use Outlook Web Access 2003, assume additional processing requirements for Internet Information Services (IIS).  Public folder usage and replication Public folders can have a significant impact on server performance, depending on folder size, frequency of access, number of different views for each folder, number of replicas, replication schedule, and frequency of content changes. Place large public folder repositories on a dedicated Exchange server that does not store any user mailboxes. Exchange servers that store public folders are sometimes called public servers.  Connectors and gateways Connectors and gateways are messaging components that can substantially increase a server's workload. Message transfer involves server-to-server communication and might require message conversion. As mentioned previously, do not configure connectors or gateways on large mailbox servers. An organization can benefit from servers that are dedicated to message transfer. Another option is to migrate all messaging systems to Exchange 2003, thereby eliminating the need for messaging gateways.  Is the server hardware correctly designed according to service level agreements? You can use Exchange 2003 stress and performance tools on a test server to verify whether its hardware is designed to accommodate the number of mailboxes you want to place on the server. For example, you can use Load Simulator (LoadSim) (LoadSim.exe) to test how an Exchange 2003 server responds to a large number of Outlook 2003 clients. Another useful tool is Jetstress (JetStress.exe), which you can use to simulate disk input/output (I/O) load to verify the performance and stability of your disk subsystem. You can download these tools from the "Downloads for Exchange Server 2003" Web site. To determine how many mailboxes Exchange 2003 servers of a given class can support, you might also want to read the performance benchmark studies at the "Performance Benchmarks for Computers Running Exchange Server 2003" Web site. Another source of information on this topic is Troubleshooting Microsoft Exchange Server 2003 Performance. Server Consolidation Recommendations

When you identify server consolidation opportunities, it is a good idea to consider best practices that might apply to your specific situation. For example, it is highly recommended to use hardware from the Windows Server Catalog when you design servers running Microsoft® Exchange Server 2003. The Windows Server Catalog lists the hardware that Microsoft has certified for Windows Server™ 2003. The catalog is available at http://go.microsoft.com/fwlink/?linkid=17219. If you want to deploy multiple servers in a Windows cluster, ensure that your hardware is listed in the catalog's "Cluster Solutions" section.

Note:

Microsoft supports hardware for Windows Server 2003 clusters only if it has passed the Windows Hardware Quality Labs (WHQL) test for the Windows Server 2003 family.

When you plan a server consolidation, keep the following recommendations in mind:

 Design server hardware generously Design your server hardware according to current and future requirements to prepare for future growth. You might want to consider additional processors, 2 GB or more of memory, and a reliable storage subsystem that has a capacity of at least two or three times the estimated size of your messaging databases. Note that hardware technology evolves at a rapid pace. Within a relatively short period of time, upgrade options might not be available for your server platform, which can pose a serious problem if future demands require you to increase system performance; for example, in the event that you need additional processors.

Note:

To enable the Microsoft Exchange Information Store service to use up to 3 GB of virtual address space on a server that has more than 1 GB of physical memory, modify the Boot.ini file on your server and add the /3GB and /USERVA parameters to the startup line for the operating system. For more information about these parameters, see Microsoft Knowledge Base Article 316739, "How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB."

 Avoid single points of failure By using fewer servers, you have fewer points of potential failure; however, the impact of failures increases. You can implement redundancy to address potential points of failure. If one component fails, another component can take over. Performance might be degraded temporarily during an outage, but users can continue their work. You should provide redundancies for the following components:  General server components For processor, memory, motherboard, and other components, consider implementing a Windows Clustering solution if high availability is a critical requirement for your mailbox servers. Exchange 2003 supports clusters running Windows Clustering. If one out of a maximum of eight nodes fails, another node in the cluster assumes the processing until the original node is repaired.  Storage subsystem Windows clusters do not provide redundancies for the storage subsystem. For this reason, it is important to provide redundancies within the storage subsystem itself; for example, you can implement a redundant array of independent disks (RAID). RAID configurations can also lead to an increased server performance when multiple disks perform I/O operations concurrently. The following table lists typical RAID configurations for Exchange 2003. Typical RAID configurations for Exchange 2003

RAID Technology Description Used For Comments

RAID 0 An array of Possibly client RAID 0 achieves very high performance because all disks can read or write striped disks computers' disk drives data concurrently, but a significant disadvantage of this RAID configuration without parity. or servers. Used in is lack of fault tolerance and a high risk of disk failure. If only one disk in the conjunction with RAID array breaks, all data is lost and must be restored from backup. For this 1. reason, RAID 0 without RAID 1 is seldom used in server systems.

RAID 1 An array of Operating system, RAID 1 achieves very high performance and very high fault tolerance mirrored disks. paging file, and because all data is mirrored after it is written, and both disks contain the transaction logs. complete data. This configuration is a perfect choice for data that requires the highest reliability. Its most significant disadvantage is its high cost. RAID1 is the recommended technology for the transaction logs on mailbox and public folder servers.

RAID 0+1 A striped array of Exchange databases This configuration is a combination of the mirrored disks included in a RAID mirrored disks that require high I/O 0 drive. Each disk in the array is mirrored to guarantee a very high level of without parity. performance and very fault tolerance. This RAID configuration is becoming the configuration of high fault tolerance. choice for many organizations. For individual disk sizes larger than 18 GB, you should use RAID 0+1 instead of RAID 5. RAID 0+1 offers the highest performance and very high reliability.

RAID 5 An array of Exchange databases RAID 5 works similarly to RAID 0, but includes a mechanism to write a striped disks that that require mid-range checksum of the data on each stripe to one of the disks. If one disk in the have parity. performance and fault array fails, the system can reconstruct the data from the remaining hard tolerance. disks. Note that in a RAID 5 array, multiple small disks perform better than fewer large disks. For example, if you have three 27 GB disks, you can use only 54 GB of storage space. If you instead use nine 9 GB disks, you have 72 GB of storage space. However, the more disks you include in the array, the higher the chance that two disks will break at the same time. This requires you to re-create the RAID drive and restore the data from backup. It is safer to use fewer large disks instead of multiple small disks. As previously mentioned, RAID 0+1 is a recommended alternative to RAID 5 in cases where you have large disk capacities.

 Implement a powerful backup solution For servers that store a large amount of data, implement a high-performance backup solution that processes multiple backup operations concurrently. Current backup solutions can achieve data transfer rates of more than 100 GB per hour. If your backup solution is not as fast, consider performing concurrent operations to back up Exchange 2003 in a timely way. You can back up multiple storage groups at the same time in separate backup sessions. When you implement a backup solution for Exchange 2003, do not rely on the backup tool included in Windows Server 2003 because this basic tool is unable to use the Volume Shadow Copy service. Instead, evaluate non-Microsoft backup solutions that include an Exchange 2003 Volume Shadow Copy service requestor. The Volume Shadow Copy service uses requestors to create shadow copies of Exchange 2003 databases. Based on these shadow copies, the Volume Shadow Copy service in Windows Server 2003 can greatly reduce the time that it takes to back up and restore Exchange 2003. Non-Microsoft backup solutions that are based on the Volume Shadow Copy service infrastructure can also use the shadow copies to almost instantaneously restore one or more databases.

The following sequential steps are performed when you back up Exchange 2003 by using the Volume Shadow Copy service:

1. The backup program starts a manual or scheduled backup process. 2. The Volume Shadow Copy service requestor in the backup program sends a command to the Volume Shadow Copy service to take a shadow copy of the selected Exchange 2003 storage groups. 3. The Volume Shadow Copy service communicates with a Volume Shadow Copy writer component in Exchange 2003 to pause new transactions, to finish current transactions, and to flush all cached data to disk. 4. The Volume Shadow Copy service communicates with the appropriate storage provider to create a shadow copy of storage volumes that contain the Exchange 2003 storage groups. 5. The Volume Shadow Copy service informs Exchange 2003 to resume normal operations. 6. The backup program copies the shadow copies of the storage group databases and logs to the tape backup device. 7. When the tape copy is completed, the Volume Shadow Copy service requestor in the backup program communicates with the Volume Shadow Copy service to delete the shadow copy. Recommendations for Small Organizations

In the context of Exchange 2003, small organizations are defined as those that have fewer than 75 users, because organizations that have fewer than 75 users can obtain Exchange 2003 as part of Microsoft Windows Small Business Server 2003. Small Business Server 2003 is a complete network solution that you should evaluate if you are certain that your organization will not exceed the 75-user limit. Windows Small Business Server 2003 is available in two editions: Standard and Premium.

The Standard Edition includes the following components:

 Windows Server 2003 This operating system includes the Active Directory® directory service.  Microsoft Windows SharePoint™ Services Use this component to implement team communications and collaboration.  Exchange Server 2003 Use this component to implement the messaging and collaboration infrastructure.  Outlook® 2003 Use this component to manage e-mail, calendars, contacts, and other personal and team information.  Shared Fax Service Use this component to receive faxes through Windows SharePoint Services, e-mail messages, or printers, and to send faxes through shared telephone lines.  Routing and Remote Access service Use this component to implement dial-in and VPN connectivity.

In addition to the previous components, the Premium Edition includes the following:

 ISA Server 2000 Use this component to implement firewall technology to secure Internet connections.  SQL Server 2000 Use this component to implement relational databases that support line-of-business applications.  Microsoft Office FrontPage® 2003 Use this component to provide tools for Web site development or to create customized solutions for Windows SharePoint Services.

The following table lists recommended and maximum possible hardware configurations for Small Business Server 2003.

Recommended and maximum hardware configurations for Small Business Server 2003

Hardware Recommended Maximum

Processor X86-based 550 MHz or higher 2 X86-based 2.4 GHz processors or higher (hyper threading is supported)

Memory 384 MB 4 GB

Hard Disk 6 GB plus space for data storage 2 hard disks in a mirror set (RAID 1) that have 6 GB, plus space for data storage

Network 1 or 2 depending on topology 2 redundant (teaming) network adapters Adapters

Other  Bootable CD or DVD drive Same as for the recommended configuration

 Super VGA (SVGA) monitor, and a video adapter that has a 800 x 600 or higher resolution and a minimum of 256 colors

 Tape or other backup device

 Modem or fax device

 Uninterruptible power supply (UPS)

Note:

Small Business Server 2003 is the only platform that can run Exchange 2003, SQL Server™ 2000, and Windows SharePoint Services on the same computer. For more information about Small Business Server 2003, see the Microsoft Windows Small Business Server 2003 Web site.

Recommendations for Medium Organizations Organizations that have more than 75 users cannot deploy Small Business Server 2003. Instead, these organizations should run Exchange 2003 on a separate computer. Medium organizations might have up to 1,000 users in a central location, in which case a single Exchange 2003 server can host all mailboxes and public folders. A limited number of remote locations may exist that connect to the data center through virtual private network (VPN) connections over the Internet. Remote users may also use dial-up connections to the Internet to access their mailboxes through VPN connections or RPC over HTTP. The following figure illustrates a possible Exchange 2003 configuration for a medium organization that has 500 local and remote users.

An Exchange 2003 design for a medium organization

Consider the following recommendations when you develop a server consolidation strategy for a medium organization:

 Deploy two domain controllers running Windows Server 2003, both configured as DNS servers and global catalog servers in a single domain Exchange 2003 requires a dependable DNS and Active Directory infrastructure, so it is important to deploy at least two global catalog servers. If you shut down one of the global catalog servers, the second global catalog server can continue to provide directory services to the Exchange 2003 organization, and users can continue to access their mailboxes, and send and receive messages. Configure both global catalogs as DNS servers to provide sufficient redundancy in the DNS infrastructure. DNS is an extremely critical network service; without it, Active Directory and the Exchange 2003 organization cannot function. Messaging clients will query DNS to locate internal resources, such as domain controllers and mailbox servers. Exchange 2003, on the other hand, relies on DNS to retrieve Internet Protocol (IP) addresses of domain controllers for directory lookups and external Simple Mail Transfer Protocol (SMTP) hosts when it sends messages to the Internet. Running DNS servers on domain controllers enables you to integrate DNS zones with Active Directory. An advantage of Active Directory-integrated zones is that all DNS servers have writable copies, and changes to zone information are replicated between the DNS servers as part of Active Directory replication.

Note:

It is possible and supported to install Exchange 2003 directly on a domain controller. This might be an option for organizations that do not want to deploy two extra servers that run Windows Server 2003 and Active Directory. However, this configuration has performance limitations. When Exchange 2003 runs on a domain controller, it must always use the local domain controller for directory lookups and cannot perform load balancing between multiple domain controllers that might exist on the network. Deploy dedicated domain controllers in the forest of an Exchange 2003 organization, especially if additional servers that also require Active Directory access exist, for example, File, Print, or SQL servers.

 Deploy Exchange Server 2003 Standard Edition The Standard Edition of Exchange 2003 is designed to meet the messaging and collaboration needs of small and medium organizations. It costs approximately six times less than the base price of the Enterprise Edition. However, the Standard Edition does not support Windows cluster configurations, and supports only one mailbox database and one public folder database in a single storage group. The messaging databases are limited to 16 GB. If you find that the capabilities of the Standard Edition do not meet your service level requirements, you can deploy Exchange Server 2003 Enterprise Edition on Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Datacenter, or Windows Server 2003 Enterprise Edition. While the Enterprise Edition supports multiple databases per server without size restrictions and provides Windows Clustering support, keep in mind that its cost, combined with the cost of additional hardware might outweigh the benefits of server consolidation in a medium organization. For example, you might need to buy additional hardware to implement a two-node cluster in an active/passive configuration for the Exchange 2003 mailbox server. In any case, design the storage subsystem with a RAID configuration to provide sufficient fault tolerance for the Exchange store. By default, all messaging databases and their transaction log files are in the \Program Files\Exchsrvr\Mdbdata directory. Exchange 2003 uses transaction logs to preserve transactions committed in the memory cache, which ensures that committed transactions are not lost if the server shuts down unexpectedly. By separating the transaction logs from the databases and placing them on a separate physical disk, you can increase the fault tolerance of the Exchange store. If the database hard disk breaks, you can replace the disk, create new databases, and then replay the transaction logs, which are still available because they reside on another disk. Your users can continue working as if nothing happened. If the disk on which the transaction logs reside fails, the databases are still available. Only the most recent transactions might be lost, if they were not incorporated into the databases before the problem occurred. The following figure illustrates a recommended hard disk configuration for a non-clustered server running Exchange Server 2003 Standard Edition.

An Exchange 2003 configuration that has databases and transaction log files on separate disks

 Deploy a perimeter network to protect internal resources from the Internet You should separate the internal network from the Internet through an arrangement of dedicated, dissimilar firewalls. You should not use an Exchange 2003 server as a firewall. The outer firewall can be a packet-filtering router or a more sophisticated firewall system to provide controlled access to the resources on the perimeter network. If possible, enable network address translation on both the outer and inner firewall to hide actual IP addresses from potential attackers. On the inner firewall, consider deploying Microsoft Internet Security and Acceleration (ISA) Server 2000 because ISA Server and Exchange 2003 are designed to work closely together to provide a more secure messaging environment. If you deploy ISA Server 2000 with Feature Pack 1 on the inner firewall, you can protect the internal Exchange 2003 organization through Secure Sockets Layer (SSL) encryption, two-factor authentication, URL scanning, and SMTP filtering. At the same time, you can provide remote Internet users with VPN or RPC over HTTP connectivity and access to mailboxes through Post Office Protocol version 3 (POP3) or IMAP4 (Internet Message Access Protocol version 4rev1), Microsoft Outlook Web Access 2003, Microsoft Outlook Mobile Access, and Exchange ActiveSync. For more information about configuring ISA Server 2000 for Exchange Server 2003, see Using ISA Server 2000 with Exchange Server 2003. For information about using ISA Server 2004 with Exchange Server 2003, see Using ISA Server 2004 with Exchange Server 2003.

Note:

To achieve high security, use dissimilar firewall products on inner and outer firewalls, so that an attacker cannot use the same techniques on outer and inner firewall to penetrate the internal network. If you use ISA server on the inner firewall, use a non-Microsoft product on the outer firewall, or vice versa. Furthermore, do not run Exchange 2003 on a firewall because an Exchange server runs many services that an attacker might be able to exploit.

 Consider deploying an SMTP smart host on the perimeter network The Exchange 2003 environment in Figure 3 does not require an explicit messaging connector to send or receive messages over the Internet. If, through DNS, the Exchange server is able to resolve SMTP domain names into IP addresses of external SMTP hosts, the server can establish SMTP connections directly to send messages. You can configure ISA Server to accept incoming SMTP connections and forward accepted messages to Exchange 2003. However, many organizations prefer to deploy an additional SMTP smart host (or an arrangement of smart hosts) on the perimeter network to prevent any direct connections over the Internet to or from internal messaging systems. The SMTP smart host accepts messages from the Internet and relays them through the inner firewall to the Exchange server. In the opposite direction, the SMTP smart host accepts messages from Exchange 2003, queries DNS to find the destination SMTP host, and then sends the messages. You can configure the SMTP service in Exchange 2003 to forward all outbound messages to a smart host on the perimeter network. You can also use the standard SMTP service in Windows Server 2003 to implement a smart host. Note:

To increase the throughput and reliability of message transfer, consider deploying multiple SMTP smart hosts on the perimeter network. It is possible to register multiple mail exchanger (MX) resource records for an SMTP domain in DNS for load balancing and fault tolerance.

Recommendations for Large Organizations

The recommendations for medium organizations are also applicable to large organizations that have more than 1,000 users and possibly multiple server locations or even multiple messaging systems. For example, large organizations should ensure that multiple domain controllers and global catalog servers are available in each server location. However, you must consider several requirements that go beyond the needs of medium organizations. In locations that have many servers, you might deploy a multi-node cluster of Exchange mailbox servers in front of a Storage Area Network to support a very high number of users. You might also deploy dedicated bridgehead servers to optimize message transfer. The following figure shows an environment that has clustered mailbox servers and bridgehead servers in several locations.

A large Exchange 2003 organization that has three server locations

Consider the following recommendations when you develop a server consolidation strategy for a large organization:

 Deploy a redundant DNS and Active Directory infrastructure in all server locations As mentioned in the previous section, your environment requires a dependable DNS and Active Directory infrastructure that provides reliable services to the Exchange 2003 organization. Most critical is the location of domain controllers, global catalog servers, and the directory replication topology. The Active Directory forest of an Exchange 2003 organization should have more than one domain controller in each domain, multiple global catalog servers in each server location, and a well-structured site topology for efficient directory replication.  Deploy dedicated mailbox and bridgehead servers in locations that have a large number of users The sample environment illustrated in Figure 5 shows dedicated mailbox and bridgehead servers in locations A and B. Dedicated bridgehead servers between routing groups help to reduce processing requirements for message transfer on mailbox servers. Server location C does not have a bridgehead server because the mailbox server was deemed powerful enough to function as a bridgehead server, as well. For load balancing and increased fault tolerance, consider deploying multiple bridgehead servers. You may also make bridgehead servers responsible for distribution group expansion, which is a useful setting if you want to prevent groups that have thousands of members from expanding on mailbox servers. If you specify an expansion server for a distribution group, all other Exchange servers in the organization must forward messages addressed to this mail-enabled group to its expansion server first. The expansion server then populates each message header with group membership information before transferring the message to its destinations.  Keep the number of routing groups to a minimum Figure 5 shows a configuration of three routing groups that correspond to server locations. These routing groups are connected to each other through routing group connectors on bridgehead servers. However, if the network connections between the server locations are fast and reliable (for example, a VPN over fast Internet connection), you might be able to eliminate all bridgehead servers by placing all mailbox servers into a single routing group. Within a single routing group, message transfer is always direct from mailbox server to mailbox server. Routing group connectors or bridgehead servers are not required. The smaller the number of routing groups in an Exchange 2003 organization, the smaller the link state table that is used to replicate link state information between all Exchange 2003 servers. This means that less bandwidth is required to transfer link state information over the computer network. An Exchange 2003 organization can span up to 1,000 routing groups, but it is best to restrict the number of routing groups to fewer than 150.  Migrate the entire organization to Exchange Server 2003 Mixed environments that have multiple messaging systems require additional bridgehead servers and messaging connectors to connect the systems. The additional servers and connectors increase administrative overhead and network requirements. Consequently, if your organization uses Exchange Server 5.5 or non-Exchange messaging systems, you can streamline the messaging infrastructure by migrating all users to Exchange 2003. It might be possible to migrate users from different messaging systems to a single Exchange 2003 mailbox server.  Deploy front-end servers in locations that have multiple mailbox servers If you have multiple mailbox servers and want to provide users with access to mailboxes through Outlook Web Access 2003, POP3, or IMAP4 over the Internet, you might find it helpful to deploy a farm of dedicated front-end servers. A front-end server is a computer that receives incoming client connections and proxies them to an appropriate mailbox server. Front-end servers determine the location of each resource in the organization by using Active Directory. In a location that has multiple mailbox servers, front-end servers provide a single point of access to all messaging resources, regardless of the actual mailbox server where the resources reside. By deploying multiple front-end servers in a server farm, you can provide load balancing and eliminate single points-of-failure for incoming client connections. Front-end servers can help to reduce the workload of mailbox servers. SSL encryption can be enabled on the front-end servers, offloading these processing requirements from the mailbox servers. You can place the front-end servers in the perimeter network. However, when you use ISA Server 2000 with Feature Pack 1, it is better to place the ISA servers in the perimeter network instead, and move the Exchange front-end servers to the internal network. This simplifies your configuration and gives front-end servers full access to Active Directory domain controllers. Plus, you benefit from the security features of ISA Server when you provide access to Outlook Web Access 2003 over the Internet. For information about using ISA Server 2004 with Exchange Server 2003, see Using ISA Server 2004 with Exchange Server 2003.

Note:

Front-end servers should not hold any mailboxes or public folders. In server locations that have only one Exchange server holding mailboxes and public folders, you can configure ISA Server to proxy incoming client connections directly to the mailbox server. In this scenario, a front-end server is not necessary.

 Choose an active/passive configuration for Windows clusters running Exchange Server 2003 Windows clusters are most suited for very large mailbox servers that have a high availability requirement. A cluster is a group of servers connected to each other by means of a public and private network, as well as an external storage system. The physical servers can act as one or many virtual Exchange 2003 servers. A virtual server corresponds to a generic IP address and a network name, and owns a disk resource in the cluster. Any of the cluster nodes can then host the virtual servers, and users can access all of the resources in the cluster without having to know the actual name of the node that currently hosts the virtual server. When you configure a virtual Exchange 2003 server, place the mailbox and public folder stores on the shared disk system. Only the Enterprise Edition of Exchange 2003 supports the Windows Clustering. The following figure shows the main components of a multi-node cluster, which can support a very large number of users, for example, 9,000 users in Location B of the figure above. By grouping two or more computers together in a cluster, you minimize system downtime caused by software, network, or hardware failures because another node can automatically take over a virtual Exchange 2003 server if the node that is currently executing the virtual server fails. This process is called a failover.

A multi-node active/passive cluster for three Exchange 2003 mailbox servers

Failover can also be triggered manually. For example, you can intentionally fail over a virtual server to the passive node if the currently active node requires maintenance. Users are disconnected only for a brief period of time during the failover process. The hierarchy of service dependencies was flattened in Exchange 2003, so that virtual Exchange 2003 servers fail over significantly faster than virtual servers running a previous version of Exchange. Users might not notice the short downtime period if they are using Outlook 2003 in Exchange cached mode.

Note:

Simplified hardware and software maintenance is one of the main reasons why organizations deploy Windows clusters. You can move the virtual servers to alternate nodes and then perform hardware or software upgrades on the original node, which is now passive. To upgrade hardware or software in this way is called a rolling upgrade.

You can configure multiple virtual servers on one cluster. However, consider several limitations when you design a server cluster. For example, a server cluster can have only one public folder store associated with the MAPI-based public folder hierarchy. Several components, such as Connector for Lotus Notes or Novell GroupWise, are not cluster-aware at all. Furthermore, a physical Exchange 2003 server cannot manage more than four storage groups. If you specify that virtual Exchange 2003 servers have multiple storage groups, ensure that a node does not have to run more than one virtual server at a time. Otherwise, you might create a situation in which a particular node must host more than four storage groups. You can address this issue in an active/passive cluster configuration by ensuring that the failover happens only to the passive node. It is possible to configure preferred nodes for failover. You should leave at least one node free of a virtual server so that this passive node can take over a virtual server from a failing node without impacting performance. In an active/active configuration, one of the remaining nodes would have to assume the extra workload, in addition to its own virtual servers, when a cluster node fails or is failed over manually. It is important to note that Microsoft does not support active/active configurations in cluster configurations that have more than two nodes. For more information about clustering with Windows Server 2003 and Exchange 2003, see Using Clustering with Exchange 2003: An Example.

Note:

Windows Clustering does not provide load balancing or storage redundancies. Virtual Exchange 2003 servers can be moved over from a failed node to another node in the cluster, but it is impossible to run the same virtual server on multiple nodes at the same time, or to specify that multiple virtual servers use replicated copies of the same messaging databases. Each virtual server must have an individual set of databases. Consequently, you must either configure the disk subsystem by using RAID 5 or RAID 0+1, or deploy a high-availability Storage Area Network solution.

 Use a Storage Area Network to implement the storage system for multiple mailbox servers Because Exchange 2003 supports Windows clusters that have up to eight nodes, a powerful and reliable shared disk system is required to implement the storage subsystem for all the messaging databases. If the number of users in a server location justifies the investment, consider deploying a Storage Area Network. Server clusters are a perfect choice for front-end Storage Area Network-based data storages. Storage Area Networks rely on Internet SCSI (iSCSI), Fibre Channel switching, or Gigabit Ethernet technology, which connects the storage systems, on which data is stored and protected, to the computer systems running Windows Clustering and the virtual Exchange 2003 servers. Fibre Channel switching or Gigabit Ethernet technology is fast and reliable, and allows hardware vendors to create storage solutions of up to several terabytes (TB). Complete Storage Area Network packages include the hardware, as well as the necessary storage management software. In a reliable Storage Area Network environment, multiple paths exist to the stored data, and the data can be backed up and restored efficiently.

Note:

The storage industry is moving toward a seamless Storage Area Network provisioning model, where storage can be added at any time and reallocated to applications, such as Exchange 2003, as needed. Windows Server 2003 supports this model by providing support for emerging Storage Area Network industry standards like iSCSI, as well as established standards like Fibre Channel and Gigabit Ethernet.

 Configure mailbox servers that have four storage groups and a large number of mailbox stores Exchange 2003 supports up to four storage groups, each containing up to five messaging stores. Distribute the mailboxes across multiple mailbox stores to keep the size of individual databases manageable. Also, distribute the mailbox stores across multiple storage groups. Databases within a single storage group share a common set of transaction log files and must be backed up together. Separate storage groups use individual sets of transaction logs. They can be backed up in parallel and they support concurrent I/O operations, which improves performance. The Microsoft Exchange Information Store service operates by using multiple threads that can write transactions for separate transaction log files concurrently. For more information about designing storage groups and mailbox databases, see Planning an Exchange Server 2003 Messaging System. Conclusion to Exchange Server 2003 Server Consolidation

Microsoft® Exchange Server 2003 addresses the needs of small, medium, and large organizations, and server consolidation based on a deployment of Exchange 2003 can lead to significant cost savings in messaging operations. The decision to consolidate messaging servers should be based on an assessment of the current infrastructure. You must take an inventory of the existing server infrastructure, determine servers' capacity and workload, and document support and management processes. The assessment should also reveal the cost of managing and maintaining the existing infrastructure. Based on this information, you can identify server consolidation opportunities, business and technology priorities, and the required capacity for the consolidated environment. You are then prepared to make trade-offs between schedule, budget, priorities (including high availability), and infrastructure flexibility. The new environment's design should be based on research on appropriate options for managing and maintaining a consolidated infrastructure in terms of capacity, fault tolerance requirements, and future growth. By using a basic outline of the new environment, an organization can start developing actual deployment plans. This typically includes identifying the business impact of each of the consolidation alternatives, including an assessment of organizational roles and responsibilities, risks, budget, and desired results during and after the consolidation. Your planning process should include pilot projects that verify the network and infrastructure design, as well as hardware and software requirements. It should also acknowledge any technical limitations and risks. User and data migration plans should detail the procedures for moving users and data to the new environment, and include a detailed deployment schedule and contingency plan to address possible issues. When you implement the new consolidated production environment, do not forget to document the configuration of servers, as well as the post-consolidation management procedures. Before migrating users and data to the new environment, ensure that appropriate backups and contingency plans are in place. It is a good idea to perform the migration in small and manageable steps, adhering to a detailed schedule. You might view each step of the migration as a test of the consolidated environment. When the transition to the new environment is complete, evaluate the results of the consolidation project, including costs and maintenance procedures. A periodic re-evaluation of the consolidation can help to identify opportunities for optimization. Finally, remember that you cannot limit a comprehensive strategy to the process of consolidating an existing environment. Your strategy must also contain a set of standards and policies to maintain a consolidated environment. Exchange 2003 High Availability Guide

Messaging systems are mission-critical components for many companies. However, circumstances such as component failure, power outages, operator errors, and natural disasters can affect a messaging system's availability. To help prevent against such circumstances, it is crucial that companies plan and implement reliable strategies for maintaining high availability. As an added benefit, a highly available messaging system can save money by providing consistent messaging functionality to users.

Whether you are deploying a new Microsoft® Exchange Server 2003 installation or upgrading from a previous version of Exchange Server, this guide will help you plan and deploy a highly available Exchange Server 2003 messaging system. Many of the high availability recommendations in this guide are related directly to the planning recommendations in Planning an Exchange Server 2003 Messaging System. Before using this guide to implement your high availability strategy, you should first read Planning an Exchange Server 2003 Messaging System.

Introduction to the Exchange 2003 High Availability Guide

Note: Many of the high availability recommendations in this guide are related directly to the planning recommendations in Planning an Exchange Server 2003 Messaging System. Before using this guide to implement your high availability strategy, you should first read Planning an Exchange Server 2003 Messaging System. Who Should Read This Guide?

This guide is designed to benefit information technology (IT) professionals who are responsible for planning and designing Exchange messaging systems. These professionals include:

 System architects Those people who are responsible for designing the overall server infrastructure, developing server deployment strategies and policies, and contributing to networking connectivity design.  Information technology (IT) managers Those people who are the technical decision makers and who manage the IT staff responsible for the infrastructure, the desktop and server deployment, and server administration and operations across sites.  System administrators Those people who are responsible for planning and deploying technology for servers running Microsoft Windows Server™ 2003 or Microsoft Windows® 2000 Server and evaluating and recommending new technology solutions.  Messaging administrators Those people who are responsible for implementing and managing organizational messaging. What Technologies Does This Guide Cover?

The following is a list of technologies related to high availability. This guide provides general information about how these technologies relate to Exchange 2003 messaging systems. For specific information about each technology, refer to the corresponding URLs.

 Microsoft Windows Server 2003 For information about Windows Server 2003, see the Windows Server System Web site.

Note:

This guide is written for Exchange 2003 installations that are running Windows Server 2003. When deployed on Windows Server 2003, Exchange 2003 takes advantage of Windows Server 2003 features and reliability. If you are running Exchange 2003 on Windows 2000 Server with Service Pack 3 (SP3) (Windows 2000 with SP3 or later is required for Exchange 2003), make sure you are familiar with the differences between Windows Server 2003 and Windows 2000. For information about the enhanced functionality of Exchange 2003 running on Windows Server 2003, see Better Together: Windows Server 2003 and Exchange Server 2003.

 Microsoft Office Outlook® 2003 Cached Exchange Mode For information about Cached Exchange Mode, see the Exchange Server 2003 Client Access Guide.  Active Directory® directory service For information about Active Directory, see the topic "Active Directory" on the Windows Server 2003 TechCenter.  Windows Server 2003 clustering technologies For information about Windows Server 2003 clustering technologies, see the Windows Server 2003 Clustering Services Web site.  Redundant array of independent disks (RAID) For information about RAID, see "Achieving Fault Tolerance by Using RAID" in the Windows Server 2003 Deployment Kit.  Storage Area Network (SAN) For information about SANs, see Windows Servers in a Storage Area Network Environment.  Volume Shadow Copy service For general information about Volume Shadow Copy service, see the Volume Shadow Copy Service section of the File and Storage Services Web site. For information about how Volume Shadow Copy service relates to Exchange, see Microsoft Knowledge Base article 822896, "Exchange Server 2003 Data Back Up and Volume Shadow Copy Services." Terminology

Before reading this guide, familiarize yourself with the following terms.

Availability

Availability refers to a level of service provided by applications, services, or systems. Highly available systems have minimal downtime, whether planned or unplanned. Availability is often expressed as the percentage of time that a service or system is available, for example, 99.9 percent for a service that is unavailable for 8.75 hours per year.

Fault tolerance

Fault tolerance is the ability of a system to continue functioning when part of the system fails. Fault tolerance is achieved by designing the system with a high degree of redundancy. If any single component fails, the redundant component takes its place with no appreciable downtime.

Mean time between failures (MTBF) Mean time between failures (MTBF) is the average time interval, usually expressed in thousands or tens of thousands of hours (sometimes called power-on hours or POH), that elapse before a component fails and requires service.

Mean time to repair (MTTR)

Mean time to repair (MTTR) is the average time interval, usually expressed in hours, that it takes to repair a failed component.

Messaging Dial Tone

Messaging Dial Tone is a recovery strategy that provides users with temporary mailboxes so they can send and receive messages immediately after a disaster. This strategy quickly restores e-mail service in advance of recovering historical mailbox data. Typically, recovery will be completed by merging historical and temporary mailbox data.

Network Load Balancing (NLB)

Available in all editions of the Windows Server 2003 operating system, Network Load Balancing (NLB) load balances incoming Internet Protocol (IP) traffic across server computers that are included in a NLB cluster. NLB enhances both the scalability and performance of IP-based programs such as Web servers, streaming media servers, firewall servers, and Exchange Server 2003 front-end servers.

Network-attached storage

Network-attached storage refers to products that use a server-attached approach to data storage. In this approach, the storage hardware connects directly to the Ethernet network through Small Computer System Interface (SCSI) or Fibre Channel connections. A network-attached storage product is a specialized server that contains a file system and scalable storage. In this model, data storage is de-centralized. The network-attached storage appliance connects locally to department servers, and therefore, the data is accessible only by local servers. By removing storage access and its management from the department server, information contained on network-attached storage can be transferred more quickly because they are not competing for the same processor resources.

Planned downtime

Planned downtime is downtime that occurs when an administrator shuts down the system at a scheduled time. Because the downtime is scheduled, administrators can plan for it to occur at a time that least affects productivity.

Redundant array of independent disks (RAID)

Redundant array of independent disks (RAID) is a method used to standardize and categorize fault tolerant disk systems. RAID levels provide a various mixture of performance, reliability, and cost. Some servers provide three RAID levels: Level 0 (striping), Level 1 (mirroring), and Level 5 (RAID-5).

Reliability

Reliability is an attribute of any computer-related component (for example, software, hardware, or network components) that consistently performs according to its specifications. You measure reliability by calculating the probability of failure for a single solution component.

Scalability

Scalability refers to a measure of how well a computer, service, or application can improve to meet increasing performance demands. For server clusters, scalability is the ability to incrementally add one or more systems to an existing cluster when the overall load of the cluster exceeds its capabilities.

Server clustering

A server cluster is a group of independent computers that work together to provide a common set of services. The Cluster service is the clustering feature provided with Windows Server 2003. If a cluster node (a computer in a cluster) fails, other nodes in the cluster assume the functions of the failed node.

Service level agreement (SLA)

A service level agreement (SLA) is an agreement between a service provider and a customer that specifies, usually in measurable terms, what services the provider will furnish. More recently, IT departments in major enterprises have adopted the practice of writing an SLA so that services for their customers (users in other departments within the enterprise) can be measured, justified, and perhaps compared with those of outsourcing network providers.

Storage Area Network (SAN)

A storage area network (SAN) is a private, sometimes high-performance network (or sub-network) that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users. Typically, a SAN is part of the overall network of computing resources for an enterprise.

Unplanned downtime Unplanned downtime is downtime that occurs as a result of a failure (for example, a hardware failure or a system failure caused by improper server configuration). Because administrators do not know when unplanned downtime could occur, users are not notified of outages in advance (as they would be with planned downtime).

Windows Server 2003 clustering technologies

Server clustering and Network Load Balancing (NLB) are two Windows Server 2003 clustering technologies that provide different availability and scalability solutions. For more information, see "Server clustering" and "Network Load Balancing" earlier in this list.

For more information about Exchange terminology, see the Exchange Server 2003 Glossary

Understanding Availability

Business-critical applications such as corporate e-mail must often reside on systems and network structures that are designed for high availability. Understanding high availability concepts and practices can help you minimize downtime in your messaging environment. Moreover, using sound information technology (IT) practices and fault tolerant hardware solutions in your organization can increase both availability and scalability.

A highly available system reliably provides an acceptable level of service with minimal downtime. Downtime penalizes businesses, which can experience reduced productivity, lost sales, and reduced confidence from users, partners, and customers. By implementing recommended IT practices, you can increase the availability of key services, applications, and servers. These practices also help you minimize both planned downtime (such as maintenance tasks or service pack installations) and unplanned downtime (such as server failure).

High Availability Planning Process

To aid in this planning, it is recommended that you familiarize yourself with the Microsoft Operations Framework (MOF). MOF is a collection of best practices, principles, and models that provide you with operations guidance. Adopting MOF practices provides greater organization and contributes to regular communication among your IT department, end users, and other integral departments in your company. For specific information about MOF, see the MOF Web site.

In addition, the Solution Accelerator for Microsoft Systems Architecture (MSA) Enterprise Messaging provides referential and implementation guidance to enable a customer or solution provider to adequately plan, build, deploy, and operate a Microsoft® Exchange Server 2003 messaging system that is secure, available, reliable, manageable, and cost effective. For specific information about Solution Accelerator for MSA Enterprise Messaging, see the Solution Accelerator for MSA Enterprise Messaging Web site.

Trustworthy Computing and High Availability

Trustworthy Computing means helping to ensure a safe and reliable computing experience that is both expected and presumed. This goal is achieved by addressing the following set of issues that affect the level of trust placed in computing: security, privacy, reliability, and business integrity. The following table describes each of these issues in detail.

Trustworthy Computing goals

Trustworthy Computing goals Description

Security An organization can expect that systems are resilient to attack, and that the confidentiality, integrity, and availability of the system and its data are protected.

Privacy An organization is able to control their information and feel confident it is not only safe and used appropriately, but in a way that provides value to them.

Reliability An organization can depend on the software and hardware in their infrastructure to fulfill its intended functions.

Business integrity Software and hardware vendors work together efficiently and behave in a responsive and responsible manner.

Although all of the issues listed are critical to ensuring a trustworthy Exchange messaging system, this guide focuses on achieving reliability and availability goals. Both Microsoft Windows Server™ 2003 and Exchange 2003 include features that can help achieve these goals. For specific information about these reliability features, see "Selecting Editions of Exchange and Windows" in Operating System and Application Measures.

For information about how to achieve security and privacy goals in your Exchange 2003 organization, see the Exchange Server 2003 Security Hardening Guide.

To learn more about the Trustworthy Computing initiative at Microsoft, see the Microsoft Trustworthy Computing Web site.

Understanding Availability, Reliability, and Scalability

Although this guide focuses mainly on achieving availability, it is important that you also understand how reliability and scalability are key components to planning and implementing a highly available Exchange 2003 messaging system.

Defining Availability

In the IT community, the metric used to measure availability is the percentage of time that a system is capable of serving its intended function. As it relates to messaging systems, availability is the percentage of time that the messaging service is up and running. The following formula is used to calculate availability levels:

Percentage of availability = (total elapsed time - sum of downtime)/total elapsed time

Availability is typically measured in "nines." For example, a solution with an availability level of "three nines" is capable of supporting its intended function 99.9 percent of the time—equivalent to an annual downtime of 8.76 hours per year on a 24x7x365 (24 hours a day/seven days a week/365 days a year) basis. The following table lists common availability levels that many organizations attempt to achieve.

Availability percentages and yearly downtime

Availability percentage 24-hour day 8-hour day

90% 876 hours (36.5 days) 291.2 hours (12.13 days)

95% 438 hours (18.25 days) 145.6 hours (6.07 days)

99% 87.6 hours (3.65 days) 29.12 hours (1.21 days)

99.9% 8.76 hours 2.91 hours

99.99% 52.56 minutes 17.47 minutes

99.999% ("five nines") 5.256 minutes 1.747 minutes

99.9999% 31.536 seconds 10.483 seconds

Unfortunately, measuring availability is not as simple as selecting one of the availability percentages shown in the preceding table. You must first decide what metric you want to use to qualify downtime. For example, one organization may consider downtime to occur when one database is not mounted. Another organization may consider downtime to occur only when more than half of its users are affected by an outage.

In addition, availability requirements must be determined in the context of the service and the organization that used the service. For example, availability requirements for your servers that host non-critical public folder data can be set lower than for servers that contain mission-critical mailbox databases.

For information about the metrics you can use to measure availability, and for information about establishing availability requirements based on the context of the service and your organizational requirements, see Setting Availability Goals.

Defining Reliability

Reliability measures are generally used to calculate the probability of failure for a single solution component. One measure used to define a component or system's reliability is mean time between failures (MTBF). MTBF is the average time interval, usually expressed in thousands or tens of thousands of hours (sometimes called power-on hours or POH), that elapses before a component fails and requires service. MTBF is calculated by using the following equation:

MTBF = (total elapsed time - sum of downtime)/number of failures

A related measurement is mean time to repair (MTTR). MTTR is the average time interval (usually expressed in hours) that it takes to repair a failed component. The reliability of all solution components—for example, server hardware, operating system, application software, and networking—can affect a solution's availability.

A system is more reliable if it is fault tolerant. Fault tolerance is the ability of a system to continue functioning when part of the system fails. Fault tolerance is achieved by designing the system with a high degree of hardware redundancy. If any single component fails, the redundant component takes its place with no appreciable downtime. For more information about fault tolerant components, see Making Your Exchange 2003 Organization Fault Tolerant.

Defining Scalability

In Exchange deployments, scalability is the measure of how well a service or application can grow to meet increasing performance demands. When applied to Exchange clustering, scalability is the ability to incrementally add computers to an existing cluster when the overall load of the cluster exceeds the cluster's ability to provide adequate performance. To meet the increasing performance demands of your messaging infrastructure, there are two scalability strategies you can implement: scaling up or scaling out.

Scaling up Scaling up involves increasing system resources (such as processors, memory, disks, and network adapters) to your existing hardware or replacing existing hardware with greater system resources. Scaling up is appropriate when you want to improve client response time, such as in an Exchange front-end server Network Load Balancing (NLB) configuration. For example, if the current hardware is not providing adequate performance for your users, you can consider adding RAM or central processing units (CPUs) to the servers in your NLB cluster to meet the demand.

Windows Server 2003 supports single or multiple CPUs that conform to the symmetric multiprocessing (SMP) standard. Using SMP, the operating system can run threads on any available processor, which makes it possible for applications to use multiple processors when additional processing power is required to increase a system's capabilities.

Scaling out

Scaling out involves adding servers to meet demands. In a back-end server cluster, this means adding nodes to the cluster. In a front-end NLB scenario, it means adding computers to your set of Exchange 2003 front-end protocol servers. Scaling out is also appropriate when you want to improve client response time with your servers.

For information about scalability in regard to server clustering solutions, see "Performance and Scalability Considerations" in Planning Considerations for Clustering.

For detailed information about selecting hardware and tuning Exchange 2003 for performance and scalability, see the Exchange Server 2003 Performance and Scalability Guide.

Understanding Downtime

Downtime can significantly impact the availability of your messaging system. It is important that you familiarize yourself with the various causes of downtime and how they affect your messaging system.

Planned and Unplanned Downtime

Unplanned downtime is downtime that occurs as a result of a failure (for example, a hardware failure or a system failure caused by improper server configuration). Because administrators do not know when unplanned downtime could occur, users are not notified of outages in advance. In contrast, planned downtime is downtime that occurs when an administrator shuts down the system at a scheduled time. Because planned downtime is scheduled, administrators can plan for it to occur at a time that least affects productivity.

To remove or minimize planned downtime, you can implement server clustering. Even while performing maintenance on a primary node, server clustering provides continuous messaging availability for your organization (by means of temporarily failing over Exchange services to a standby computer in the Exchange cluster). For more information about clustering, see Planning for Exchange Clustering.

The following table lists common causes of downtime and specific examples for each cause.

Causes of downtime and examples of each cause

Causes of downtime Examples

Planned administrative downtime Upgrades for hardware components, firmware, drivers, operating system, and software applications.

Component failures Faulty server components, such as memory chips, fans, system boards, and power supplies. Faulty storage subsystem components, such as failed disk drives and disk controllers. Faulty network components, such as routers and network cabling.

Software defects or failures Drive stops responding, operating system stops responding or reboots, viruses, or file corruption.

Operator error or malicious users Accidental or intentional file deletion, unskilled operation, or experimentation.

System outages or maintenance Software or systems requiring reboot, or system board failure.

Local disaster Fires, storms, and other localized disasters.

Regional disaster Earthquakes, hurricanes, floods, and other regional disasters. Failure Types

An integral aspect to implementing a highly available messaging system is to ensure that no single point of failure can render a server or network unavailable. Before you deploy your Exchange 2003 messaging system, you must familiarize yourself with the following failure types that may occur and plan accordingly.

Note:

For detailed information about how to minimize the impact of the following failure types, see Making Your Exchange 2003 Organization Fault Tolerant.

Storage failures

Two common storage failures that can occur are hard disk failures and storage controller failures. There are several methods you can use to protect against individual storage failures. One method is to use redundant array of independent disks (RAID) to provide redundancy of the data on your storage subsystem. Another method is to use storage vendors who provide advanced storage solutions, such as Storage Area Network (SAN) solutions. These advanced storage solutions should include features that allow you to exchange damaged storage devices and individual storage controller components without losing access to the data. For more information about RAID and SAN technologies, see Planning a Reliable Back-End Storage Solution.

Network Failures

Common network failures include failed routers, switches, hubs, and cables. To help protect against such failures, there are various fault tolerant components you can use in your network infrastructure. Fault tolerant components also help provide highly available connectivity to network resources. As you consider methods for protecting your network, be sure to consider all network types (such as client access and management networks). For information about network hardware, see "Server-Class Network Hardware" in Component-Level Fault Tolerant Measures.

Component Failures

Common server component failures include failed network interface cards (NICs), memory (RAM), and processors. As a best practice, you should keep spare hardware available for each of the key server components (for example, NICs, RAM, and processors). In addition, many enterprise- level server platforms provide redundant hardware components, such as redundant power supplies and fans. Hardware vendors build computers with redundant, hot-swappable components, such as Peripheral Component Interconnect (PCI) cards and memory. These components allow you to replace damaged hardware without removing the computer from service.

For information about using redundant components and spare hardware components see Component-Level Fault Tolerant Measures.

Computer Failures

You must promptly address application failures or any other problem that affects a computer's performance. To minimize the impact of a computer failure, there are two solutions you can include in your disaster recovery plan: a standby server solution and a server clustering solution.

In a standby server solution, you keep one or more preconfigured computers readily available. If a primary server fails, this standby server would replace it. For information about using standby servers, see "Spare Components and Standby Servers" in Component-Level Fault Tolerant Measures.

With server clustering, your applications and services are available to your users even if one cluster node fails. This is possible either by failing over the application or service (transferring client requests from one node to another) or by having multiple instances of the same application available for client requests.

Note:

Server clustering can also help you maintain a high level of availability if one or more computers must be temporarily removed from service for routine maintenance or upgrades.

For information about Network Load Balancing (NLB) and server clustering, see "Fault Tolerant Infrastructure Measures" in System-Level Fault Tolerant Measures.

Site Failures

In extreme cases, an entire site can fail due to power loss, natural disaster, or other unusual occurrences. To protect against such failures, many businesses are deploying mission-critical solutions across geographically dispersed sites. These solutions often involve duplicating a messaging system's hardware, applications, and data to one or more geographically remote sites. If one site fails, the other sites continue to provide service (either through automatic failover or through disaster recovery procedures performed at the remote site), until the failed site is repaired. For more information, see "Using Multiple Physical Sites" in System-Level Fault Tolerant Measures.

Costs of Downtime

Calculating some of the costs you experience as a result of downtime is relatively easy. For example, you can easily calculate the replacement cost of damaged hardware. However, the resulting costs from losses in areas such as productivity and revenue are more difficult to calculate.

The following table lists the costs that are involved when calculating the impact of downtime.

Costs of downtime

Category Cost involved Productivity Number of employees affected by loss of messaging functionality and other IT assets Number of administrators needed to manage a site increases with frequency of downtime

Revenue Direct losses Compensatory payments Lost future revenues Billing losses Investment losses

Financial performance Revenue recognition Cash flow Lost discounts (A/P) Payment guarantees Credit rating Stock price

Damaged reputation Customers Suppliers Financial markets Banks Business partners

Other expenses Temporary employees Equipment rental Overtime costs Extra shipping costs Travel expenses

Impact of Downtime

Availability becomes increasingly important as businesses continue to increase their reliance on information technology. As a result, the availability of mission-critical information systems is often tied directly to business performance or revenue. Based on the role of your messaging service (for example, how critical the service is to your organization), downtime can produce negative consequences such as customer dissatisfaction, loss of productivity, or an inability to meet regulatory requirements.

However, not all downtime is equally costly; the greatest expense is caused by unplanned downtime. Outside of a messaging service's core service hours, the amount of downtime—and corresponding overall availability level—may have little to no impact on your business. If a system fails during core service hours, the result can have significant financial impact. Because unplanned downtime is rarely predictable and can occur at any time, you should evaluate the cost of unplanned downtime during core service hours.

Because downtime affects businesses differently, it is important that you select the proper response for your organization. The following table lists different impact levels (based on severity), including the impact each level has on your organization.

Downtime impact levels and corresponding effect on business

Impact level Description Business impact

Impact Minor impact on business results. Low: Minimal availability requirement. level 1

Impact Disrupts the normal business Low: Prevention of business loss improves return on investment and profitability. level 2 processes. Minimal loss of revenue, low recovery cost.

Impact Substantial revenue is lost; some is Medium: Prevention of business loss improves return on investment and level 3 recoverable. profitability.

Impact Significant impact on core business High: Prevention of lost revenue improves business results. Business risk level 4 activities. outweighs the cost of the solution. Affects medium-term results.

Impact Strong impact on core business High: Business risk outweighs the cost of the solution. level 5 activities. Affects medium-term results. Company's survival may be at risk.

Impact Very strong impact on core business Extreme: Management of the business risk is essential. Cost of the solution is level 6 activities. secondary. Immediate threat to the company's survival.

Understanding Technology, People, and Processes

For most organizations, achieving high availability is synonymous with minimizing the impact that failures (for example, network failures, storage failures, computer failures, and site failures) have on your mission-critical messaging services. However, achieving this goal involves much more than selecting the correct hardware. It also involves selecting the right technology, the right people, and the right processes. Deficiencies in any one of these areas can compromise availability.

 Technology The technology component of a highly available solution comprises many areas, such as server hardware, the operating system, device drivers, applications, and networking. As with the technology/people/process dependency chain, the contribution that technology as a whole can make toward achieving a highly available solution is only as strong as its weakest component.  People Proper training and skills certification ensure that the people who are managing your mission-critical systems and applications have the knowledge and experience required to do so. Strengthening this area requires more than technical knowledge— administrators must also be knowledgeable in process-related areas.  Processes Your organization must develop and enforce a well-defined set of processes that cover all phases of a solution's cycle. To achieve improvements in this area, examine industry best practices and modify them to address each solution's unique requirements.

Setting Availability Goals

When designing your Microsoft® Exchange Server 2003 messaging system, consider the level of availability that you want to achieve for your messaging service. One important aspect of specifying an availability percentage is deciding how you want to measure downtime. For example, one organization may consider downtime to occur when one database is not mounted. Another organization may consider downtime to occur only when more than half of its users are affected by an outage.

In addition to availability levels, you must also consider performance and scalability. By ensuring that your messaging system resources are sufficient to meet current and future demands, your messaging services will be more available to your users.

Availability goals allow you to accomplish the following tasks:

 Keep efforts focused where they are needed. Without clear goals, efforts can become uncoordinated, or resources can become so sparse that none of your organization's most important needs are met.  Limit costs. You can direct expenditures toward the areas where they make the most difference.  Recognize when tradeoffs must be made, and make them in appropriate ways.  Clarify areas where one set of goals might conflict with another, and avoid making plans that require a system to handle two conflicting goals simultaneously.  Provide a way for administrators and support staff to prioritize unexpected problems when they arise by referring to the availability goals for that component or service.

This section, together with the information provided in Understanding Availability, will help you set availability goals for your Exchange Server 2003 organization. Well-structured goals can increase system availability while reducing your support costs and failure recovery times.

Note:

To help set your availability and scalability goals, read this section in conjunction with Questions to Consider When Developing Availability and Scalability Goals.

Quantifying Availability and Scalability Requirements

When quantifying the level of availability you want to achieve, it is important that you compare the costs of your current information technology (IT) environment (including the actual costs of outages) and the costs of implementing high availability solutions. These solutions include training costs for your staff as well as facilities costs, such as costs for new hardware. After you calculate the costs, IT managers can use these numbers to make business decisions (not just technical decisions) about your high availability solution.

Setting high availability goals is the responsibility of many parties, and these goals must be appropriate to all stakeholders. You must evaluate the impact of setting high availability goals on messaging administrators, business users, and customers. For example, although executive management and end users may want 99.999 percent availability, messaging system administrators must make clear the cost of achieving such strict availability goals.

After deciding how you will measure availability in your organization, it is important that you routinely monitor your system to verify that you are meeting your availability requirements. For information about monitoring tools that can help you measure the availability of your services and systems, see Implementing Software Monitoring and Error-Detection Tools.

Determining Availability Requirements Understanding Availability explained how availability can be expressed numerically as the percentage of time that a service is available for use (for example, 99.9 percent service availability). Understanding Availability also discussed how, when determining your availability percentage, you must consider the context of the service and the organization that uses that service. For example, if a public folder store on a server that hosts non-critical public folders is unavailable, productivity may not be affected. However, if a mailbox store on a server that hosts a mission- critical mailbox or public folders is unavailable, productivity may be affected immediately.

In an organization that is operational 24x7x365 (24 hours a day/seven days a week/365 days a year), systems that are 99 percent reliable will be unavailable, on average, 87 hours (3.5 days) every year. Moreover, that downtime can occur at unpredictable times—possibly when it is least affordable. It is important to understand that an availability level of 99 percent could prove costly to your business.

Instead, the percentage of uptime you should strive for is some variation of 99.x percent—with an ultimate goal of five nines, or 99.999 percent. For a single server in your organization, three nines (99.9 percent) is an achievable level of availability. Achieving five nines (99.999 percent) is unrealistic for a single server because this level of availability allows for approximately five minutes of downtime per calendar year. However, by implementing fault tolerant clusters with automatic failover capabilities, four nines (99.99 percent) is achievable. It is even possible to achieve five nines if you also implement fault tolerant measures, such as server-class hardware, advanced storage solutions, and service redundancy.

For information about the steps required to achieve these availability levels, including the implementation of fault tolerant hardware and server clustering, see Making Your Exchange 2003 Organization Fault Tolerant.

Setting availability goals is a complex process. To help you in this task, consider the following information as you are setting your goals.

Note:

To further assist you in setting availability goals, answer the questions in Questions to Consider When Developing Availability and Scalability Goals.

Downtime and availability percentage considerations

Because you can schedule planned system outages to occur at a time that least impacts productivity, planned downtime is frequently treated differently than unplanned downtime. Whether you should factor planned downtime into the availability equation depends on your business needs. For unplanned outages that occur during scheduled business hours, a goal of three or four nines (99.9 percent or 99.99 percent) is less of an investment than full-time availability, which must include both planned and unplanned system outages. For more information about 8-hour versus 24-hour availability levels, see the "Availability percentages and yearly downtime" table in Understanding Availability, Reliability, and Scalability.

Even minimal scheduled downtime (for example, 2 hours a month or 24 hours a year) reduces availability to 99.73 percent. You can increase availability to 99.93 percent by reducing scheduled downtime to 30 minutes a month, or 6 hours a year. Moreover, if you use your primary messaging system server for only production purposes and to perform database backups, health checks, and other tasks on secondary servers that have copies of the same data, the chances of achieving 99.99 percent availability or higher increase.

Maintenance considerations

To determine the best high availability solution, you must understand when your users need the messaging system. For example, if there are times when the messaging system is not heavily used or is not used at all, you can perform maintenance operations (such as security patch updates or disk defragmentation processes) during these times at a reduced cost. However, if you have users in different time zones, be sure to consider their usage times when planning a maintenance schedule.

Recovery considerations

When setting high availability goals, you must determine if you want to recover your Exchange databases to the exact point of failure, if you want to recover quickly, or both. Your decision is a critical factor in determining your server redundancy solution. Specifically, you must determine if a solution that results in lost data is inconvenient, damaging, or catastrophic.

For more information about selecting a recovery solution, see the Exchange Server 2003 Disaster Recovery Planning Guide.

Determining Scalability Requirements

When planning for high availability, determining scalability requirements provides your organization with a certain amount of flexibility in the future. However, because scalability is based on future needs (for example, larger messaging volumes and increased disk space), it can be difficult to quantify. As a result, planning for scalability requires a certain amount of estimation and prediction. To help you determine the scalability requirements for your organization, consider the following information.

Hardware considerations

If your hardware budget is sufficient, you can purchase hardware at regular intervals to add to your existing deployment. (The amount of hardware you purchase depends on the exact increase in demand.) If you have budget limitations, you can purchase servers that can be enhanced later (for example by adding RAM or CPUs).

Growth considerations Researching your organization's past growth patterns can help determine how demand on your IT system may grow. However, as business technology becomes more complex, and reliance on that technology increases every year, you must consider other factors as well. If you anticipate growth, realize that some aspects of your organization may grow at different rates. For example, you may require more Web servers than print servers over a certain period of time. For some servers, scaling up (for example, additional CPU power) may be sufficient to handle an increase in network traffic. In other cases, the most practical scaling solution may be to scale out (for example, add more servers).

For more information about scalability, see "Defining Scalability" in Understanding Availability, Reliability, and Scalability.

For information about monitoring your messaging system for the purpose of analyzing long-term trends, see "Monitoring for Long-Term Trend Analysis" in Monitoring Strategies.

Testing considerations

Re-create your Exchange 2003 deployment as accurately as possible in a test environment, either manually or using tools such as Exchange Server Load Simulator 2003 (LoadSim), Exchange Stress and Performance (ESP), and Jetstress. These tools allow you to test the workload capacities of different areas in your Exchange organization. Observing your messaging system under such circumstances can help you formulate scaling priorities. To download these tools, see the Downloads for Exchange Server 2003 Web site. For information about pilot testing, see "Laboratory Testing and Pilot Deployments" in System-Level Fault Tolerant Measures.

Monitoring considerations

After you deploy Exchange 2003, use software monitoring tools to alert you when certain components are near or at capacity. Specifically, tools such as Performance Monitor (which monitors performance levels and system capacity) and programs such as Microsoft Operations Manager can help you decide when to implement a scaling solution. For more information about monitoring performance levels, see Implementing Software Monitoring and Error-Detection Tools.

Considering Cost Restraints

Business requirements, particularly cost constraints, determine whether it is cost-effective to upgrade the network infrastructure, server hardware, and software in your messaging environment. To maximize the financial resources of your hardware and software budget, you must first analyze the integrity, performance, and features within your existing messaging environment. Then, you must decide which upgrades are necessary to meet business and user requirements.

As you determine how much to invest in your high availability strategy, consider the following:

 Understand the value of high availability in each aspect of your business For example, in a high-traffic commerce Web site, each hour that a Web server's databases are unavailable may cost up to $100,000 in sales. However, for that same company, the cost impact of an unavailable messaging system may be much less. In this example, you should maintain a higher availability level for your Web servers (for example, 99.99 percent), and a lower availability level for your mailbox servers (for example, 99.9 percent).  Research the actual costs of downtime of your messaging services In general, the costs associated with messaging service downtime are usually much higher than you would initially expect. Researching these costs helps you determine if the costs of implementing and maintaining a high availability solution are less than the costs of downtime. For more information about the cost and impact of downtime, see "Costs of Downtime" and "Impact of Downtime" in Understanding Downtime.  Understand how your hardware and software directly impacts availability Your hardware and software choices directly affect the performance, design, and availability of your Exchange messaging system.  Understand that costs of downtime are non-linear For example, the consequences of a five-minute outage may far outweigh those of five one-minute outages.

If cost constraints prevent you from purchasing expensive hardware, you can maximize your available resources to achieve a high level of performance and availability. For example, to minimize the amount of time it takes to restore data, you can implement a backup strategy that requires more frequent backups. Costs related to this backup strategy are much less than those associated with backup strategies that include a Storage Area Network (SAN)-based Volume Shadow Copy service. For information about how you can minimize the amount of time it takes to recover Exchange data, see "Implementing Practices to Minimize Exchange Database Restore Times" in the Exchange Server 2003 Disaster Recovery Planning Guide.

Similarly, in cases where networking upgrade possibilities are limited, you can take advantage of messaging features such as RPC over HTTP and Exchange Cached Mode. These features help provide a better messaging experience for your users who have low-speed, unreliable network connections. For more information about the fault tolerant features in Exchange 2003, Microsoft Windows Server™ 2003, and Microsoft Office Outlook® 2003, see Operating System and Application Measures.

Important:

Although you can delay software and hardware upgrades in favor of other expenditures, it is important to recognize when your organization requires fault tolerant network, storage, and server components. For more information about fault tolerant measures and disaster recovery solutions, see Making Your Exchange 2003 Organization Fault Tolerant. Analyzing Risk

When planning a highly available Exchange 2003 environment, consider all available alternatives and measure the risk of failure for each alternative. Begin with your current organization and then implement design changes that increase reliability to varying degrees. Evaluate the costs of each alternative against its risk factors and the impact of downtime to your organization. For a worksheet that can help you evaluate your current environment, see "Checklist for Evaluating Your Environment" in Planning an Exchange Server 2003 Messaging System.

Often, achieving a certain level of availability can be relatively inexpensive, but to go from 98 percent availability to 99 percent, for example, or from 99.9 percent availability to 99.99 percent, can be costly. This is because bringing your organization to the next level of availability may entail a combination of new or costly hardware solutions, additional staff, and support staff for non-peak hours. As you determine how important it is to maintain productivity in your IT environment, consider whether those added days, hours, and minutes of availability are worth the cost.

Every operations center needs a risk management plan. As you assess risks in your Exchange 2003 organization, remember that network and server failures can result in considerable losses. After you evaluate risks versus costs, and after you design and deploy your messaging system, be sure to provide your IT staff with sound guidelines and plans of action in case a failure does occur.

For more information about designing a risk management plan for your Exchange 2003 organization, see the Microsoft Operations Framework (MOF) Web site. The MOF Web site provides complete information about creating and maintaining a flexible risk management plan, with emphasis on change management and physical environment management, in addition to staffing and team role recommendations.

Establishing a Service Level Agreement

After considering the impact of downtime on your organization and deciding on a level of uptime that you want to achieve in your messaging environment, you are ready to establish a service level agreement (SLA). SLA requirements determine how components such as storage, clustering, and backup and recovery factor into your organization.

When assessing SLAs, you should begin by identifying the hours of regular operation and the expectations regarding planned downtime. You should then determine your company's expectations regarding availability, performance, and recoverability, including message delivery time, percentage of server uptime, amount of storage required per user, and amount of time to recover an Exchange database.

In addition, you should identify the estimated cost of unplanned downtime so that you can design the proper amount of fault tolerance into your messaging system.

Features in Exchange 2003 and Windows Server 2003 may affect how you design your organization to meet SLAs. For example, the Volume Shadow Copy service and the Exchange recovery storage group feature may allow you to challenge the limits that were previously imposed by your SLAs. For information about how you can implement these features to significantly reduce the time it takes to restore Exchange databases, see "SAN-Based Snapshot Backups" in the Exchange Server 2003 Disaster Recovery Planning Guide.

The following table lists some of the categories and specific elements you may want to include in your SLAs.

Categories and elements in a typical enterprise-level SLA

SLA categories Examples of SLA elements

Hours of  Hours that the messaging service is available to users Operation  Hours reserved for planned downtime (maintenance)

 Amount of advance notice for network changes or other changes that may affect users

Service  Percentage of time Exchange services are running Availability  Percentage of time mailbox stores are mounted

 Percentage of time that domain controller services are running

System  Number of internal users that the messaging system concurrently supports Performance  Number of remotely connected users that the messaging system concurrently supports

 Number of messaging transactions that are supported per unit of time

 Acceptable level of performance, such as latency experienced by users

Disaster Recovery  Amount of time allowed for recovery of each failure type, such as individual database failure, mailbox server failure, domain controller failure, and site failure

 Amount of time it takes to provide a backup mail system so users can send and receive e-mail messages without accessing historical data (called Messaging Dial Tone)

 Amount of time it takes to recover data to the point of failure Help  Specific methods that users can use to contact the help desk Desk/Support  Help desk response time for various classes of problems

 Help desk procedures regarding issue escalation procedures

Other  Amount of storage required per user

 Number of users who require special features, such as remote access to the messaging system

Including a variety of performance measures in your SLAs helps ensure that you are meeting the specific performance requirements of your users. For example, if there is high-latency or low available bandwidth between clients and mailbox servers, users would view the performance level differently from system administrators. Specifically, users would consider the performance level to be poor, while system administrators would consider the performance to be acceptable. For this reason, it is important that you monitor disk I/O latency levels.

Note:

For each SLA element, you must also determine the specific performance benchmarks that you will use to measure performance in conjunction with availability objectives. In addition, you must determine how frequently you will provide statistics to IT management and other management.

Establishing Service Level Agreements with Your Vendors

Many businesses that place importance on high availability solutions use the services of third-party vendors to achieve their high availability goals. In these cases, achieving a highly available messaging system requires services from outside hardware and software vendors. Unresponsive vendors and poorly trained vendor staff can reduce the availability of the messaging system.

It is important that you negotiate an SLA with each of your major vendors. Establishing SLAs with your vendors helps guarantee that your messaging system performs to specifications, supports required growth, and is available to a given standard. The absence of an SLA can significantly increase the length of time the messaging system is unavailable.

Important:

Make sure that your staff is aware of the terms of each SLA. For example, many hardware vendor SLAs contain clauses that allow only support personnel from the vendor or certified staff members of your organization to open the server casing. Failure to comply can result in a violation of the SLA and potential nullification of any vendor warranties or liabilities.

In addition to establishing an SLA with your major vendors, you should also periodically test escalation procedures by conducting support- request drills. To confirm that you have the most recent contact information, make sure that you also test pagers and phone trees.

Identifying and Analyzing Barriers to Achieving High Availability

A barrier to high availability is defined as any issue that has the potential of limiting a messaging system's availability. Although it is impossible to protect your messaging environment from every barrier, it is important that you are familiar with the most common high availability barriers, including the risks associated with each.

Identifying Barriers

Barriers to achieving high availability include the following:

 Environmental issues Problems with the messaging system environment can reduce availability. Environmental issues include inadequate cabling, power outages, communication line failures, fires, and other disasters.  Hardware issues Problems with any hardware used by the messaging system can reduce availability. Hardware issues include power supply failures, inadequate processors, memory failures, inadequate disk space, disk failures, network card failures, and incompatible hardware.  Communication and connectivity issues Problems with the network can prevent users from connecting to the messaging system. Communication and connectivity issues include network cable failures, inadequate bandwidth, router or switch failure, Domain Name System (DNS) configuration errors, and authentication issues.  Software issues Software failures and upgrades can reduce availability. Software failure issues include downtime caused by memory leaks, database corruption, viruses, and denial of service attacks. Software upgrade issues include downtime caused by application software upgrades and service pack installations.  Service issues Services that you obtain from outside a business can exacerbate a failure and increase unavailability. Service issues include poorly trained staff, slow response time, and out-of-date contact information.  Process issues The lack of proper processes can cause unnecessary downtime and increase the length of downtime caused by a hardware or software failure. Process issues include inadequate or nonexistent operational processes, inadequate or nonexistent recovery plans, inadequate or nonexistent recovery drills, and deploying changes without testing.  Application design issues Poor application design can reduce the perceived availability of a messaging system.  Staffing issues Insufficient, untrained, or unqualified staff can cause unnecessary downtime and lengthen the time to restore availability. Staffing issues include insufficient training materials, inadequate training budget, insufficient time for training, and inadequate communication skills. Analyzing Barriers

After identifying high availability barriers, it is important that you estimate the impact of each barrier and consider which barriers are cost effective enough to overcome.

To determine an appropriate high availability solution, you must analyze how each barrier (and the corresponding risks) affects availability. Specifically, consider the following for each barrier:

 The estimated time the system will be unavailable if a failure occurs  The probability that the barrier will occur and cause downtime  The estimated cost to overcome the barrier compared to the estimated cost of downtime

To illustrate how you can analyze a barrier's effect on availability, consider a hardware-related risk—specifically, the risk associated with the failure of a hard disk that contains the database files and transaction log files for 25 percent of your users. In this example, you should:

1. Estimate the amount of time that messaging services will be unavailable to your users. The following are examples of two storage strategies that have different recovery time estimates:

Note:

The amount of time it takes to recover the failed disk depends on the experience and training of the IT personnel who are working to solve the issue.

 If the failed hard disk is part of a fault tolerant redundant array of independent disks (RAID) disk array, you do not need to restore the system from backup. For example, if the RAID array is made up of hot-swappable disks, you can replace the failed disk without shutting down the system. However, if the RAID array does not include hot-swappable disks, the amount of downtime equals the time it takes to shut down the necessary servers and then replace the failed disk. To minimize impact, you could perform these steps during non-business hours.  If the failed hard disk is not part of a RAID disk array, and if it has been backed up to tape or disk, you can replace the hardware, and then restore the Exchange database (or databases) to the primary server from backup. The amount of downtime equals the time it takes to replace the hardware restore from backup, and resubmit the transactions that occurred after the deletion (if these transactions are available). The amount of time depends on your backup media hardware and your Exchange 2003 server hardware. 2. Estimate the probability that this barrier will occur. In this example, the probability is affected by the reliability and age of the hardware. 3. Estimate the cost to overcome this barrier. The cost to prevent downtime depends on the solution you select. In addition, the cost to overcome this barrier may include additional IT personnel. To overcome this barrier, consider the following options:  If you decide that you want to implement RAID (either software RAID or hardware RAID), the cost to overcome the barrier is measured by the cost of the new hardware, as well as the expense of training and maintenance. Depending on the hardware class you select, these costs will vary extensively. The costs also depend on whether you decide to use a third- party vendor to manage the system, or if you will train your own personnel. This solution significantly minimizes downtime, but costs more to implement.  If you decide to replace the hardware and restore databases from backup, the cost to overcome the barrier is measured by the time it takes to restore the data from backup, plus the time it takes to resubmit the transactions that occurred after the disk failure. This solution results in more downtime, but costs less to implement. For information about calculating the cost of downtime, see "Costs of Downtime" in Understanding Downtime.

Note:

When evaluating the cost to overcome a barrier, remember that a solution for one barrier may also remove additional barriers. For example, keeping a redundant copy of your messaging databases on a secondary server can overcome many barriers.

Determining and Evaluating High Availability Solutions The high availability solutions discussed in this guide include recommendations regarding redundant components, redundant servers, and database backups and restorations. Each of these recommendations is integral to achieving a highly available messaging system.

The remaining sections discuss issues related to these solutions. After reading this guide, to help you deploy and maintain a highly available messaging system, see the documentation available at the Exchange Server TechCenter.

Making Your Exchange 2003 Organization Fault Tolerant

To design a reliable, highly available messaging system, you must maximize the fault tolerance of your messaging system. Fault tolerance refers to a system's ability to continue functioning when part of the system fails. An organization that has successfully implemented fault tolerance in their messaging system design can minimize the possibility of a failure, as well as the impact of a failure should one occur. To make your Microsoft® Exchange Server 2003 messaging system fault tolerant, you must implement hardware and software that meets the requirements of your service level agreements (SLAs). Although many fault tolerant server and network components can be expensive, the features of Microsoft Windows Server™ 2003 and Exchange Server 2003 can help you maximize fault tolerance, regardless of your hardware and software budget. A common misconception is that, to achieve the highest level of availability, you must implement server clustering. In actuality, a highly available messaging system depends on many factors, one of the more important being fault tolerance. Server clustering is only one method by which you can add fault tolerance to your messaging system. To achieve the highest level of availability, you should implement fault tolerant measures in conjunction with other availability methods, such as training information technology (IT) administrators on your availability processes.

Overview of a Fault Tolerant Messaging Infrastructure

To make your Exchange 2003 organization as fault tolerant as possible, you should minimize the single points of failure in your messaging infrastructure. You can do this by implementing fault tolerant measures at the following levels:

 Operating system and application measures Before implementing specific component-level and system-level fault tolerant measures, there are certain operating system and application measures to consider.  Component-level measures At the server level, you should use fault tolerant components such as power control, battery backup, Error Correction Code (ECC) memory, and redundant fans. At the network-level, you should implement fault tolerant networking components such as redundant switches, routing, and wiring.  System-level measures At the system level, you should deploy Exchange using fault tolerant measures such as redundant access to Active Directory® directory service, redundant client access to front-end services, redundant storage of Exchange data, a carefully planned backup strategy, and a carefully planned monitoring strategy.

Note:

It is not always necessary to implement redundant components in every level of your design. Specifically, you should consider the mean time between failures (MTBF) of each device in the critical path. In some cases, you may be able to reach your required availability levels even if there is no redundancy for some devices.

The following figure illustrates many of the system-level measures you can implement to maximize the fault tolerance of your Exchange organization.

Note:

The fault tolerant measures that you implement depend on the availability goals you want to reach. Some organizations may omit one or more of the fault tolerant measures shown in this figure, while other organizations may include additional measures. For example, an organization may decide to implement a storage design that includes a Storage Area Network (SAN) storage system, but decide against implementing server clustering.

Fault tolerant Exchange 2003 messaging infrastructure

Example of Fault Tolerant Exchange 2003 Topologies

This section provides examples of Exchange 2003 topologies, including estimated availability percentages. To maximize your understanding of the availability percentages presented in this section, read "Determining Availability Requirements" in Quantifying Availability and Scalability Requirements and Establishing a Service Level Agreement.

Although the topologies described in this section are simplified, they can help you understand how to implement fault tolerant measures in your messaging infrastructure.

Important:

The tiers and estimated availability levels in this section are arbitrary and are not intended to reflect any industry-wide standards.

Note:

Actual availability levels depend on many variables. Therefore, before you deploy your Exchange 2003 topology in a production environment, it is recommended that you test the deployment in both a laboratory test and a pilot deployment setting.

The topologies represented in this section range from a first-tier to a fifth-tier messaging system. All of the tiers are based on a first-tier topology, which includes the following components:

 Mid-level server-class hardware in all servers  Single-server advanced firewall solution  Single domain controller that is also configured as a global catalog server  Single server that is running Domain Name System (DNS)  Exchange 2003 and Windows Server 2003 correctly configured

First-tier messaging system

The following table includes a description of the five possible tiers, as well as the estimated availability levels of each.

Tier descriptions and estimated availability levels

Estimated availability Tier description level

First-tier messaging system For the description of a first-tier messaging system, see Figure 3.2 and the preceding 99% or higher bulleted list.

Second-tier messaging system A second-tier system meets the requirements of a first-tier system, but also 99.5% or higher includes multiple domain controllers, multiple DNS servers, a separate monitoring server, and an entry-level redundant array of independent disks (RAID) storage solution that is not on a SAN.

Third-tier messaging system A third-tier messaging system meets the requirements of the second-tier system, but 99.9% or higher also includes a mid-range RAID storage solution using a SAN, and Network Load Balancing (NLB) implemented on Exchange front-end servers.

Fourth-tier messaging system A fourth-tier message system meets the requirements of the third-tier system, but 99.99% or also includes a high-range RAID storage solution, a high-range SAN solution, back up and restore using Volume higher Shadow Copy service, and active/passive Microsoft Windows® Clustering (with multiple passive nodes), for all back- end Exchange servers.

Fifth-tier messaging system A fifth-tier messaging system meets the requirements of the fourth-tier system, but 99.999% or also includes complete site failover (in the event of a site failure) through the use of a multi-site design that includes a higher geographically dispersed clustering solution.

Operating System and Application Measures

Before you implement specific component-level and system-level fault tolerance measures, there are certain operating system and application measures to consider. Specifically, these measures include:

 Selecting Exchange and Windows editions  Selecting client applications that support client-side caching  Selecting and testing your server applications  Using the latest software and firmware

Selecting Editions of Exchange and Windows

To provide the highest level of fault tolerance for your organization, make sure that you select the correct editions of Exchange and Windows. Although all editions of Exchange 2003 and Windows Server 2003 have been designed with high availability features, selecting the correct editions of each is an important step in maximizing the fault tolerance of your messaging system.

Selecting an edition of Exchange

You can select from two editions of Exchange 2003: Exchange Server 2003 Standard Edition and Exchange Server 2003 Enterprise Edition. The following table lists the key differences between these Exchange 2003 editions.

Key differences between Exchange 2003 Standard Edition and Exchange 2003 Enterprise Edition

Exchange 2003 Standard Feature Edition Exchange 2003 Enterprise Edition

Storage group support 1 storage group 4 storage groups

Number of databases per 2 databases 5 databases storage group

Total database size 16 gigabytes (GB) Maximum 8 terabytes, limited only by hardware (see Note that follows)

Exchange Clustering Not supported Supported when running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition

X.400 connector Not included Included

Note:

For timely backup and restore processes, 8 terabytes of messaging storage is beyond most organizations' requirements to meet SLAs.

For more information about the differences between Exchange 2003 Standard Edition and Exchange 2003 Enterprise Edition, see the Exchange Server 2003 Edition Comparison Web site.

For information that compares the features in Exchange Server 2003, Exchange 2000 Server, and Exchange Server 5.5, see the Exchange Server 2003 Features Comparison Web site.

Selecting an edition of Windows

You can select from three editions of Windows Server 2003: Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. If you want to use Windows Server 2003, Datacenter Edition, you must select a vendor that supports your Windows Server 2003 deployment scenario. For information about the Windows Datacenter High Availability Program, see the Windows Datacenter High Availability Program Web site.

Note:

Although you can run Exchange 2003 on Microsoft Windows® 2000 Server with Service Pack 3(SP3), there are many advantages to using Windows Server 2003. For information about the advantages to running Exchange 2003 on Windows Server 2003, see Better Together: Windows Server 2003 and Exchange Server 2003.

For information about selecting an edition of Windows Server 2003, see the Introducing the Windows Server 2003 Operating Systems Web site.

For information about the high availability features of Windows Server 2003, see the Maximizing Availability on the Windows Server 2003 Platform Web site.

Selecting Client Applications that Support Client-Side Caching

When selecting a client application for your users, consider deploying Microsoft Office Outlook® 2003. Outlook 2003 supports client-side caching by using Cached Exchange Mode. When Outlook 2003 is used with Exchange 2003, you can configure Cached Exchange Mode to enable users to read e-mail messages or do other messaging tasks in low-bandwidth networks and in situations where network connectivity has been lost. Requests for information notifications from the Exchange server are eliminated on the user's Outlook client, allowing the user to work without interruption in low-bandwidth, high-latency networks. Moreover, Exchange 2003 and Outlook 2003 significantly improve client performance by reducing remote procedure calls (RPCs) and conversation between the Outlook client and the Exchange server. For more information about the performance advantages of using Outlook 2003 and Exchange 2003 together, see the Exchange Server 2003 Client Access Guide.

Selecting and Testing Server Applications

It is important that your server applications (for example, management scripts and antivirus software) are reliable. As a best practice, you should not run an application on a server until it has proven to be reliable in a test and pilot environment.

For information about laboratory testing and pilot deployments, see "Laboratory Testing and Pilot Deployments" in System-Level Fault Tolerant Measures.

For information about how to plan for unreliable applications, see "Operational Best Practices" in System-Level Fault Tolerant Measures.

Using the Latest Software and Firmware

Downtime for Windows and Exchange-based solutions can be the result of faulty device drivers, out-of-date software, or inadequate change control processes. To protect your Exchange 2003 organization against problems that hardware and software vendors have identified and corrected, keep your servers up-to-date with the latest software updates (such as hardware drivers) and firmware updates (such as basic input/output system [BIOS] updates). Most software application and hardware vendors have Web sites that provide software and firmware updates for their products. Regarding your operating system updates, it is recommended that you regularly download the latest Windows Server 2003 software updates. Some Windows Server 2003 updates fix known problems or provide security enhancements. To download the latest Windows Server 2003 software updates, see the Microsoft Windows Update Web site.

However, before you deploy software and firmware updates in your production environment, make sure that you:

 Test the reliability of the updated software and firmware.  Can back out of the updates if necessary.

Testing software and firmware updates in test environment

Before you install software and firmware updates on your production servers, you should deploy these updates in a test environment.

Backing out of software and firmware updates

You must also make sure that you can back out of any updates if problems occur. Depending on the type of update you install, there are different methods for backing out. For example, to back out of a driver update, you can use the Roll Back Driver feature in Windows Server 2003 Device Manager. For information about this feature, see the topic "To roll back to the previous version of a driver" in Windows Server 2003 Help.

In some cases, to back out of an update, you may have to restore the System State data, boot partition, and system partition backups from your server. For example, if you have a Windows backup set (which includes a backup of System State data, system partitions, and boot partitionsor a full computer backup set (which includes a backup of System State data and most of the data on your hard disks) prior to installing the updates, you can back out of some of these updates. You can also back out of some of these updates if you have images of your server's boot and system partitions prior to installing the updates.

For information about creating Windows backup sets and full computer backup sets, see the Exchange Server 2003 Disaster Recovery Operations Guide.

For information about how to keep these software and firmware updates readily available (for example, if you need to rebuild a server), see "Keeping Your Software and Firmware Updates Available" in the Exchange Server 2003 Disaster Recovery Planning Guide.

Component-Level Fault Tolerant Measures

This section provides component-level considerations and strategies for increasing the fault tolerance of your Exchange 2003 organization. Specifically, component-level refers to the individual server hardware, storage hardware, and networking hardware in your organization's infrastructure. An effective hardware strategy can improve the overall availability of a system. These strategies can range from adopting common sense practices to using expensive fault tolerant equipment.

The hardware in your Exchange 2003 organization includes server hardware and network hardware. When adopting a hardware strategy, consider the following:

 Make sure that your hardware is redundant.  Make sure that you implement server-class hardware.  Make sure that you select standardized hardware.  Make sure that you have spare hardware available.

The following sections discuss each of these considerations in detail. Overall, when selected and deployed correctly, your hardware can help meet the requirements of your SLAs.

For more information about fault tolerant hardware strategies and highly available system designs, see the Microsoft Solutions Framework Web site.

Redundant Hardware

Hardware redundancy refers to using one or more hardware components to perform identical tasks. To minimize single points of failure in your Exchange 2003 organization, it is important that you use redundant server, network, and storage hardware. By incorporating duplicate hardware configurations, one path of data I/O or a server's physical hardware components can fail without affecting the operations of a server.

The hardware you use to minimize single points of failure depends on which components you want to make redundant. Many hardware vendors offer products that build redundancy into their server or storage solution hardware. Some of these vendors also offer complete storage solutions, including advanced backup and restore hardware designed for use with Exchange 2003.

Server-Class Hardware

Server-class hardware is hardware that provides a higher degree of reliability than hardware designed for workstations. When selecting hardware for your Exchange 2003 servers, storage subsystems, and network, make sure that you select server-class components. Note:

Traditionally, servers that include server-class hardware also include special hardware or software monitoring features. However, if the hardware you purchase does not include monitoring features, make sure that you consider a monitoring solution as part of your design and deployment plan. For more information about how monitoring is important to maintaining a fault tolerant organization, see "Implementing a Monitoring Strategy" in System-Level Fault Tolerant Measures.

Server-Class Server Hardware

Server-class server hardware includes the following:

 Redundant power supplies If the primary power supply fails, redundant server and disk array uninterruptible power supply (UPS) units and battery backups provide a secondary power supply. Essentially, a UPS and battery backup provide protection against power surges and short power losses that can damage your servers and the data they contain.  Redundant fans If a cooling fan stops functioning, redundant fans ensure that there is sufficient cooling inside the server. Servers without redundant fans may automatically shut down if a fan fails.

Note:

If a server room exceeds a specific temperature, redundant fans may not be enough to keep the hardware operating correctly. For information about temperature and other safeguard considerations, see "Safeguarding the Physical Environment of Your Servers" in System-Level Fault Tolerant Measures.

 Redundant memory If a memory bank fails, redundant memory ensures that memory remains available. For example, copying the physical memory (known as memory mirroring) provides fault tolerance through memory replication. Memory-mirroring techniques include having two sets of RAM in one computer, each a mirror of the other, or mirroring the entire System State, which includes RAM, CPU, adapter, and bus states. Memory mirroring must be developed and implemented in conjunction with the original equipment manufacturer (OEM).  ECC memory If a double-bit error occurs, Error Correction Code (ECC) memory detects and corrects single-bit errors and takes the memory offline.  Redundant network interface cards If a network interface card (NIC) or a network connection fails, redundant NICs ensure that your servers will maintain network connectivity.  Power-on monitoring components When the server is initially turned on, the server detects startup failure conditions, such as abnormal temperature conditions or a failed fan.  Prefailure monitoring components While the server is running, prefailure conditions are monitored. If a component, such as a power supply, hard disk, fan, or memory, is beginning to fail, an administrator is notified before the failure actually occurs. For example, a failure detected by ECC memory is corrected by the ECC memory or routed to the redundant memory, preventing a server failure. An administrator is immediately notified to rectify the memory problem.  Power failure hardware monitoring components When a power failure occurs, system shutdown software ensures a shutdown if necessary in conjunction with a UPS.

Server -Class Storage Hardware

 A redundant storage subsystem provides protection against the failure of a single disk drive or controller. You should consider implementing the following redundant components:  Redundant hardware on your back-end servers for connecting to the external array  Redundant paths to the disk array  Redundant storage controllers  In addition, use RAID to implement redundancy of the logical unit numbers (LUNs). For more information about implementing fault tolerance for your back-end storage solution, see "Implementing a Reliable Back-End Storage Solution" in System-Level Fault Tolerant Measures.

Server-Class Network Hardware

Server-class network hardware includes the following:

 Redundant hubs, switches, network adapters, and wiring For information about how to implement this redundant hardware in your network, consult the vendors who provide these components.  Redundant routers Routers do not fail frequently. However, if they do, entire server organizations can shut down. Therefore, having redundant routing capability is critical. For information about how to protect against router failure, consult your router vendor. Note:

For the servers on which you must maintain the highest degree of availability, use fixed Internet Protocol (IP) addresses and do not use Dynamic Host Configuration Protocol (DHCP). This prevents an outage due to the failure of the DHCP server. This can improve address resolution by DNS servers that do not handle the dynamic address assignment provided by DHCP.

Standardized Hardware

To make sure that your hardware is fully compatibility with Windows operating systems, select hardware from the Windows Server Catalog.

When selecting your hardware from the Windows Server Catalog, adopt one standard for hardware and standardize it as much as possible. Specifically, select one type of computer and, for each computer you purchase, use the same components (for example, the same network cards, disk controllers, and graphics cards). The only parameters you should modify are the amount of memory, number of CPUs, and the hard disk configurations.

Standardizing hardware has the following advantages:

 When testing driver updates or application-software updates, only one test is needed before deploying to all your computers.  Fewer spare parts are required to maintain an adequate set of replacement hardware.  Support personnel require less training because it is easier for them to become familiar with a limited set of hardware components.

Spare Components and Standby Servers

When planning your hardware budget, consider including spare hardware components, spare servers, and even hot standby servers. (Hot refers to servers that are powered on and ready to replace a specific type of server in your organization.) Having these spare hardware components and servers accessible can significantly increase your ability to replace damaged hardware and recover from hardware failures.

Spare Components

Be sure to include spare components in your hardware budget, and keep these components on-site and readily available. One advantage to using standardized hardware is the reduced number of spare components that must be kept on-site. For example, if all your hard drives are the same type and from the same manufacturer, you do not need to stock as many spare drives.

The number of spare components you should have available correlates to the maximum downtime your organization can tolerate. Another concern is the market availability of replacement components. Some components, such as memory and CPUs, are fairly easy to locate and purchase at any time. Other components, such as hard drives, are often discontinued and may be difficult to locate after a short time. For these components, you should plan to buy spares when you buy the original hardware. Also, when considering solutions from hardware vendors, you should use service companies or vendors who promptly replace damaged components or complete servers.

Standby Servers

Consider the possibility of maintaining a standby server, possibly even a hot standby server to which data is replicated automatically. If the costs of downtime are high and clustering is not a viable option, you can use standby servers to decrease recovery times. Using standby servers can also be important if server failure results in high costs, such as lost profits from server downtime or penalties from an SLA violation.

A standby server can quickly replace a failed server or, in some cases, act as a source of spare parts. Also, if a server experiences a catastrophic failure that does not involve the hard drives, it may be possible to move the drives from the failed server to a functional server (possibly in combination with restoring data from backup media).

Note:

In a clustered environment, this data transfer is done automatically.

One advantage to using standby servers to recover from an outage is that the failed server is available for careful diagnosis. Diagnosing the cause of a failure is important in preventing repeated failures.

Standby servers should be certified and, similar to production servers, should be running 24-hours-a-day, 7-days-a-week.

System-Level Fault Tolerant Measures

This section provides system-level considerations and strategies for increasing the fault tolerance of your Exchange 2003 organization. Specifically, system-level refers to your Exchange 2003 infrastructure and the recommended best practices for implementing fault tolerance within that infrastructure.

The following figure illustrates a reliable Exchange 2003 infrastructure and lists the best practices for maintaining a high level of fault tolerance.

System-level fault tolerant measures

Fault Tolerant Infrastructure Measures

This section discusses methods for designing fault tolerance at each level in your Exchange 2003 infrastructure. Specifically, this section provides information about:

 Implementing firewalls and perimeter networks  Ensuring reliable access to Active Directory and Domain Name System (DNS)  Ensuring reliable access to Exchange front-end servers  Configuring Exchange protocol virtual servers  Implementing a reliable back-end storage solution  Implementing a server clustering solution  Implementing a monitoring strategy  Implementing a disaster recovery strategy

Implementing Firewalls and Perimeter Networks

It is recommended that your Exchange 2003 topology includes a perimeter network and front-end and back-end server architecture. The following figure illustrates this topology, including the additional security provided by an advanced reverse-proxy server (in this case, Internet Security and Acceleration (ISA) Server 2000 Feature Pack 1).

Note:

To increase the performance and scalability of your advanced reverse-proxy server, you can implement Windows Server 2003 Network Load Balancing (NLB) on the servers in your perimeter network. For information about NLB, see "Using Network Load Balancing on Your Front- End Servers" later in this topic.

Exchange 2003 topology using a perimeter network

Deploying ISA Server 2000 Feature Pack 1 in a perimeter network is just one way you can help secure your messaging system. Other methods include using transport-level security such as Internet Protocol security (IPSec) or Secure Sockets Layer (SSL).

Important:

Whether or not you decide to implement a topology that includes Exchange 2003 front-end servers, it is recommended that you not allow Internet users to access your back-end servers directly.

For complete information about designing a secure Exchange topology, see "Planning Your Infrastructure" in Planning an Exchange Server 2003 Messaging System.

For information about using ISA Server 2000 with Exchange 2003, see Using ISA Server 2000 with Exchange Server 2003.

Ensuring Reliable Access to Active Directory and Domain Name System

Exchange relies heavily on Active Directory and Domain Name System (DNS). To provide reliable and efficient access to Active Directory and DNS, make sure that your domain controllers, global catalog servers, and DNS servers are well protected from possible failures.

Domain Controllers

A domain controller is a server that hosts a domain database and performs authentication services that are required for clients to log on and access Exchange. (Users must be able to be authenticated by either Exchange or Windows.) Exchange 2003 relies on domain controllers for system and server configuration information. In Windows Server 2003, the domain database is part of the Active Directory database. In a Windows Server 2003 domain forest, Active Directory information is replicated between domain controllers that also host a copy of the forest configuration and schema containers.

A domain controller can assume numerous roles within an Active Directory infrastructure: a global catalog server, an operations master, or a simple domain controller.

Global Catalog Servers

A global catalog server is a domain controller that hosts the global catalog. A global catalog server is required for logon because it contains information about universal group membership. This membership grants or denies user access to resources. If a global catalog server cannot be contacted, a user's universal membership cannot be determined and logon access is denied.

Note:

Although Windows Server 2003 provides features that do not require a local global catalog server, you still need a local global catalog server for Exchange and Outlook. The global catalog server is critical for Exchange services (including logon, group membership, and Microsoft Exchange Information Store service) and access to the global address list (GAL). Deploying global catalog servers locally to both servers and users allows for more efficient address lookups. Contacting a global catalog server across a slow connection increases network traffic and impairs the user experience. At least one global catalog server must be installed in each domain that contains Exchange servers.

Domain Controller and Global Catalog Server Best Practices

Because domain controllers contain essential Active Directory information, make sure that the domain controllers in your organization are well protected from possible failures.

The following are best practices for deploying and configuring Active Directory domain controllers and global catalog servers:

 Unless it is a requirement for your organization, do not run Exchange 2003 on your domain controllers. For information about the implications of running Exchange on a domain controller, see "Running Exchange 2003 on a Domain Controller" later in this topic.  Place at least two domain controllers in each Active Directory site. If a domain controller is not available within a site, Exchange will look for another domain controller. This is especially important if the other domain controllers in your organization can be accessed only across a WAN. This circumstance could cause performance issues and possibly introduce a single point of failure.  Place at least two global catalog servers in each Active Directory site. If a global catalog server is not available within a site, Exchange will look for another global catalog server. This is especially important if the other global catalog servers in your organization can be accessed only across a WAN. This circumstance could cause performance issues and possibly introduce a single point of failure.

Note:

If your performance requirements do not demand the bandwidth of two domain controllers and two global catalog servers per domain, consider configuring all of your domain controllers as global catalog servers. In this scenario, every domain controller will be available to provide global catalog services to your Exchange 2003 organization.

 There should generally be a 4:1 ratio of Exchange processors to global catalog server processors, assuming the processors are similar models and speeds. However, higher global catalog server usage, a large Active Directory database, or large distribution lists can necessitate more global catalog servers.  In branch offices that service more than 10 users, one global catalog server must be installed in each location that contains Exchange servers. However, for redundancy purposes, deploying two global catalog servers is ideal. If a physical site does not have two global catalog servers, you can configure existing domain controllers as global catalog servers.  If your architecture includes multiple subnets per site, you can add additional availability by ensuring that you have at least one domain controller and one global catalog server per subnet. As a result, even if a router fails, you can still access the domain controller access.  Ensure that the server assigned to the infrastructure master role is not a global catalog server. For information about the infrastructure master role, see the topic "Global catalog and infrastructure master" in Windows 2000 Server Help.  Consider monitoring the LDAP latency on all Exchange 2003 domain controllers. For information about monitoring Exchange, see Implementing Software Monitoring and Error-Detection Tools.  Consider increasing the LDAP threads from 20 to 40, depending on your requirements. For information about tuning Exchange, see the Exchange Server 2003 Performance and Scalability Guide.  Ensure that you have a solid backup plan for your domain controllers.

Running Exchange 2003 on a Domain Controller

As a best practice, you should not run Exchange 2003 on servers that also function as Windows domain controllers. Instead, you should configure Exchange servers and Windows domain controllers separately.

However, if your organization requires that you run Exchange 2003 on a domain controller, consider the following limitations:

 If you run Exchange 2003 on a domain controller, it uses only that domain controller. As a result, if the domain controller fails, Exchange cannot fail over to another domain controller.  If your Exchange servers also perform domain controller tasks in addition to serving Exchange client computers, those servers may experience performance degradation during heavy user loads.  If you run Exchange 2003 on a domain controller, your Active Directory and Exchange administrators may experience an overlap of security and disaster recovery responsibilities.  Exchange 2003 servers that are also domain controllers cannot be part of a Windows cluster. Specifically, Exchange 2003 does not support clustered Exchange 2003 servers that coexist with Active Directory servers. For example, because Exchange administrators who can log on to the local server have physical console access to the domain controller, they can potentially elevate their permissions in Active Directory.  If your server is the only domain controller in your messaging system, it must also be a global catalog server.  If you run Exchange 2003 on a domain controller, avoid using the /3GB switch. If you use this switch, the Exchange cache may monopolize system memory. Additionally, because the number of user connections should be low, the /3GB switch should not be required.  Because all services run under LocalSystem, there is a greater risk of exposure if there is a security bug. For example, if Exchange 2003 is running on a domain controller, an Active Directory bug that allows an attacker to access Active Directory would also allow access to Exchange.  A domain controller that is running Exchange 2003 takes a considerable amount of time to restart or shut down. (approximately 10 minutes or longer). This is because services related to Active Directory (for example, Lsass.exe) shut down before Exchange services, thereby causing Exchange services to fail repeatedly while searching for Active Directory services. One solution to this problem is to change the time-out for a failed service. A second solution is to manually stop the Exchange services before you shut down the server.

Domain Name System and Windows Internet Name Service Availability

Similar to domain controller and global catalog server services, Domain Name System (DNS) services are critical to the availability of your Exchange 2003 organization. On a Windows Server 2003 network, users locate resources by using DNS and Windows Internet Name Service (WINS). The failure of a DNS server can prevent users from locating your messaging system.

To ensure that your Exchange 2003 topology includes reliable access to DNS, consider the following:

 Ensure that a secondary DNS server exists on the network. If the primary DNS server fails, this secondary server should be able to direct users to the correct servers.  Integrate Windows Server 2003 DNS zones into Active Directory. In this scenario, each domain controller becomes a potential DNS server.  Configure each client computer with at least two DNS addresses.  Ideally, both DNS servers should be in the same site as the client. If the DNS servers are not in the same site as the client, the primary DNS server should be the server that is in the same site as the client.  Ensure that name resolution and DNS functionality are both operating correctly. For more information, see Microsoft Knowledge Base article 322856, "HOW TO: Configure DNS for Use with Exchange Server."  Before deploying Exchange, ensure that DNS is correctly configured at the hub site and at all branches.  Exchange requires WINS. Although it is possible to run Exchange 2003 without enabling WINS, it is not recommended. There are availability benefits that result from using WINS to resolve NetBIOS names. (For example, in some configurations, using WINS removes the potential risk of duplicate NetBIOS names causing a name resolution failure.) For more information, see Microsoft Knowledge Base article 837391, "Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality."

For information about deploying DNS and WINS, see "Deploying DNS" and "Deploying WINS" in the Microsoft Windows Server 2003 Deployment Kit.

Ensuring Reliable Access to Exchange Front-End Servers

If your organization has more than one Exchange server, it is recommended that you use Exchange front-end and back-end server architecture. Front-end and back-end architecture provides several client access performance and availability benefits.

Internet clients access their mailboxes through front-end servers. However, in default Exchange 2003 configurations, MAPI clients cannot use front-end servers; instead, these clients access their mailboxes through back-end servers directly.

Note:

You can configure Exchange 2003 RPC over HTTP to allow your MAPI clients to access their mailboxes through front-end servers. For information about using RPC over HTTP, see Exchange Server 2003 RPC over HTTP Deployment Scenarios.

When front-end servers use HTTP, POP3, and IMAP4, performance is increased because the front-end servers offload some load processing duties from the back-end servers.

If you plan to support MAPI, HTTP, POP3, or IMAP4, you can use Exchange front-end and back-end server architecture to take advantage of the following benefits:

 Front-end servers balance processing tasks among servers. For example, front-end servers perform authentication, encryption, and decryption processes. This improves the performance of your Exchange back-end servers.  Your messaging system security is improved. For more information, see "Security Measures" later in this topic.  To incorporate redundancy and load balancing in your messaging system, you can use Network Load Balancing (NLB) on your Exchange front-end servers.

For information about planning an Exchange 2003 front-end and back-end architecture, see "Planning Your Infrastructure" in Planning an Exchange Server 2003 Messaging System.

For information about deploying front-end and back-end servers, see Using Microsoft Exchange 2000 Front-End Servers. Although that document focuses on Exchange 2000, the content is applicable to Exchange 2003.

To build fault tolerance into your messaging system, consider implementing Exchange front-end servers that use NLB. You should also configure redundant virtual servers on your front-end servers.

Using Network Load Balancing on Your Front-End Servers

Network Load Balancing (NLB) is a Windows Server 2003 service that provides load balancing support for IP-based applications and services that require high scalability and performance. When implemented on your Exchange 2003 front-end servers, NLB can address bottlenecks caused by front-end services.

The following figure illustrates a basic front-end and back-end architecture that includes NLB.

Basic front-end and back-end architecture including Network Load Balancing

An NLB cluster dynamically distributes IP traffic to two or more Exchange front-end servers, transparently distributes client requests among the front-end servers, and allows clients to access their mailboxes using a single server namespace.

NLB clusters are computers that, through their numbers, enhance the scalability and performance of the following:

 Web servers  Computers running ISA Server (for proxy and firewall servers)  Other applications that receive TCP/IP and User Datagram Protocol (UDP) traffic

NLB cluster nodes usually have identical hardware and software configurations. This helps ensure that your users receive consistent front-end service performance, regardless of the NLB cluster node that provides the service. The nodes in an NLB cluster are all active.

Important:

NLB clustering does not provide failover support as does the Windows Cluster service. For more information, see the next section, "Network Load Balancing and Scalability." For more information about NLB, see "Designing Network Load Balancing" and "Deploying Network Load Balancing" in the Microsoft Windows Server 2003 Deployment Kit.

Network Load Balancing and Scalability

With NLB, as the demand increases on your Exchange 2003 front-end servers, you can either scale up or scale out. In general, if your primary goal is to provide faster service to your Exchange users, scaling up (for example, adding additional processors and additional memory) is a good solution. However, if you want to implement some measure of fault tolerance to your front-end services, scaling out (adding additional servers) is the best solution. With NLB, you can scale out to 32 servers if necessary. Scaling out increases fault tolerance because, if you have more servers in your NLB cluster, a server failure affects fewer users.

Important:

You must closely monitor the servers in your NLB cluster. When one server in an NLB cluster fails, client requests that were configured to be sent to the failed server are not automatically distributed to the other servers in the cluster. Therefore, when one server in your NLB cluster fails, it should immediately be taken out of the cluster to ensure that required services are provided to your users.

Configuring Exchange Protocol Virtual Servers

When configuring your Exchange 2003 messaging system, use Exchange System Manager to create a protocol virtual server for each protocol that you want to support on a specific front-end server.

To maximize availability and performance of your front-end servers, consider the following recommendations when configuring protocol virtual servers:

 When configuring NLB for your Exchange 2003 front-end servers, you should make sure that all protocol virtual servers on your NLB front-end servers are configured with identical settings.

Important:

If the protocol virtual servers in your NLB cluster are not identical, your e-mail clients may experience different behavior, depending on the server to which they are routed.

 If you are not using NLB on your front-end servers, do not create additional protocol virtual servers on each of your front-end servers. (For example, do not create two identical HTTP protocol virtual servers on the same front-end server.) Additional virtual servers can significantly affect performance and should be created only when default virtual servers cannot be configured adequately.

For more information about configuring Exchange protocol virtual servers, see the Exchange Server 2003 Administration Guide.

For information about tuning Exchange 2003 front-end servers, see the Exchange Server 2003 Performance and Scalability Guide.

Implementing a Reliable Back-End Storage Solution

A reliable storage strategy is paramount to achieving a fault tolerant messaging system. To implement and configure a reliable storage solution, you should be familiar with the following:

 Exchange 2003 database technology  Best practices for configuring and maintaining Exchange data  Advanced storage technologies such as RAID and Storage Area Networks (SANs)  For detailed information about planning and implementing a reliable back-end storage solution, see Planning a Reliable Back-End Storage Solution.

Implementing a Server Clustering Solution

By allowing the failover of resources, server clustering provides fault tolerance for your Exchange 2003 organization. Specifically, server clusters that use the Cluster service maintain data integrity and provide failover support and high availability for mission-critical applications and services on your back-end servers, including databases, messaging systems, and file and print services.

The following figure illustrates an example of a four-node cluster where three nodes are active and one is passive.

Example of a four-node 3 active/1 passive cluster

In server clusters, nodes share access to data. Nodes can be either active or passive, and the configuration of each node depends on the operating mode (active or passive) and how you configure failover. A server that is designated to handle failover must be sized to handle the workload of the failed node.

Note:

In Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, server clusters can contain up to eight nodes. Each node is attached to one or more cluster storage devices, which allow different servers to share the same data. Because nodes in a server cluster share access to data, the type and method of storage in the server cluster is important.

For information about planning Exchange server clusters, see Planning for Exchange Clustering.

Benefits of Clustering

Server clustering provides two main benefits in your organization: failover and scalability.

Failover

Failover is one of the most significant benefits of server clustering. If one server in a cluster stops functioning, the workload of the failed server fails over to another server in the cluster. Failover ensures continuous availability of applications and data. Windows Clustering technologies help guard against three specific failure types:

 Application and service failures. These failures affect application software and essential services.  System and hardware failures. These failures affect hardware components such as CPUs, drives, memory, network adapters, and power supplies.  Site failures in multi-site organizations. These failures can be caused by natural disasters, power outages, or connectivity outages. To protect against this type of failure, you must implement an advanced geoclustering solution. For more information, see "Using Multiple Physical Sites" later in this topic.

By helping to guard against these failure types, server clustering provides the following two benefits for your messaging environment:

 High availability The ability to provide end users with dependable access services while reducing unscheduled outages.  High reliability The ability to reduce the frequency of system failure. Scalability

Scalability is another benefit of server clustering. Because you can add nodes to your clusters, Windows server clusters are extremely scalable.

Limitations of Clustering

Rather than providing fault tolerance at the data level, server clustering provides fault tolerance at the application level. When implementing a server clustering solution, you must also implement solid data protection and recovery solutions to protect against viruses, corruption, and other threats to data. Clustering technologies cannot protect against failures caused by viruses, software corruption, or human error.

Clustering vs. Fault Tolerant Hardware

Both clustering and fault tolerant hardware protect your system from component failures (such as CPU, memory, fan, or PCI bus failures). Although you can use clustering and fault tolerant hardware together as an end-to-end solution, be aware that the two methods provide high availability in different ways:

 Clustering can provide protection from an application or operating system failure. However, a stand-alone (non-clustered) server using fault tolerant hardware (or a server that uses hot-swappable hardware, which allows a device to be added while the server is running) cannot provide protection from these failure types.  Clustering enables you to perform upgrades or installations on one of the cluster nodes, while maintaining full Exchange service availability for users. With stand-alone (non-clustered) servers, you must often stop Exchange services to perform these upgrades or installations. For specific information about how you can maintain Exchange service availability when performing upgrades or installations, see "Taking Exchange Virtual Servers or Exchange Resources Offline" in the Exchange Server 2003 Administration Guide.

Implementing a Monitoring Strategy

Continuous monitoring of your network, applications, data, and hardware is essential for high availability. Software-monitoring tools and techniques enable you to determine the health of your system and identify potential issues before an error occurs.

To maximize availability, you must consistently manage, monitor, and troubleshoot your servers and applications. If a problem occurs, you must be able to react quickly so you can recover data and make it available as soon as possible. To help you monitor your Exchange 2003 organization, you could use the Exchange 2003 Management Pack for Microsoft Operations Manager.

For complete information about Exchange 2003 Management Pack, Microsoft Operations Manager, and other monitoring tools, see Implementing Software Monitoring and Error-Detection Tools.

Implementing a Disaster Recovery Solution

To increase fault tolerance in your organization, you need to develop and implement a well-planned backup and recovery strategy. If you are prepared, you should be able to recover from most failures.

Additional System-Level Best Practices

After considering measures to increase fault tolerance in your Exchange 2003 infrastructure, consider the following additional system-level best practices:

 Safeguarding the physical environment of your servers Take precautions to ensure that the physical environment is protected.  Security measures Implement permissions practices, security patching, physical computer security, antivirus protection, and anti- spam solutions.  Message routing Use fault tolerant network hardware and correctly configure your routing groups and connectors.  Use multiple physical sites Protect data from site failures by mirroring data to one or more remote sites or implementing geoclustering to allow failover in the event of a site failure.  Operational procedures Maintain and monitor servers, use standardized procedures, and test your disaster recovery procedures.  Laboratory testing and pilot deployments Before deploying your messaging system in a production environment, test performance and scalability in laboratory and pilot environments.

Safeguarding the Physical Environment of Your Servers

To maintain the availability of your servers, you should maintain high standards for the environment in which the servers must run. To increase the longevity and reliability of your server hardware, consider the following:

 Temperature and humidity Install mission-critical servers in a room established for that purpose—specifically a room in which you can carefully control temperature and humidity. Computers perform best at approximately 70 degrees Fahrenheit (approximately 21 degrees Celsius). In an office setting, temperature is not usually an issue. However, consider the effects of a long holiday weekend in the summer with the air conditioning turned off.  Dust or contaminants Where possible, protect servers and other equipment from dust and contaminants and check for dust periodically. Dust and other contaminants can cause components to short-circuit or overheat, which can cause intermittent failures. Whenever a server's case is open, quickly check to determine whether the unit needs cleaning. If so, check all the other units in the area.  Power supplies As with any disaster-recovery planning, planning for power outages is best done long before you anticipate outages and involves identifying resources that are most critical to the operation of your business. When possible, provide power from at least two circuits to the computer room and divide redundant power supplies between the power sources. Ideally, the circuits should originate from two sources that are external to the building. Be aware of the maximum amount of power a location can provide. It is possible that a location could have so many servers that there is not sufficient power for any additional servers. Consider a backup power supply for use in the event of a power failure in your computer center. It may be necessary to continue providing computer service to other buildings in the area or to areas geographically remote from the computer center. You can use uninterruptible power supply (UPS) units to handle short outages and standby generators to handle longer outages. When reviewing equipment that requires backup power during an outage, include network equipment, such as routers.  Maintenance of cables To prevent physical damage to cables, make sure the cables are neat and orderly, either with a cable management system or tie wraps. Cables should never be loose in a cabinet, where they can be disconnected by mistake. If possible, make sure that all cables are securely attached at both ends. Also, make sure that pull-out, rack-mounted equipment has enough slack in the cables, and that the cables do not bind and are not pinched or scraped. Set up good pathways for redundant sets of cables. If you use multiple sources of power or network communications, try to route the cables into the cabinets from different points. This way, if one cable is severed, the other can continue to function. Do not plug dual power supplies into the same power strip. If possible, use separate power outlets or UPS units (ideally, connected to separate circuits) to avoid a single point of failure.

Security Measures Security is a critical component to achieving a highly available messaging system. Although there are many security measures to consider, the following are some of the more significant:

 Permission practices  Security patches  Physical security  Antivirus protection  Anti-spam solutions

For detailed information about these and other security measures, see the Exchange Server 2003 Security Hardening Guide.

Message Routing Considerations

Your routing topology is the basis of your messaging system. As a result, you must plan your routing topology with network, bandwidth, and geographical considerations in mind. Routing describes how Exchange transfers messages from one server to another. When planning your routing topology, you must understand how messages are transferred within Exchange and then plan a topology for the most efficient transfer of messages. You must also plan the locations of connectors to messaging systems outside your Exchange organization. Careful planning can reduce the volume of network traffic and optimize Exchange and Windows services.

To ensure that your message routing is reliable and available, consider the following high-level recommendations:

 Make sure that your physical network has built-in redundancy. For more information, see "Network Hardware" earlier in this topic.  Make sure that you have correctly configured connectors and routing groups. For example, in some scenarios, using Exchange System Manager to configure redundant connector paths can limit a single point of failure.  Configure your connectors to ensure there are multiple paths to all bridgehead servers.  If applicable, make sure that your Simple Mail Transfer Protocol (SMTP) gateway servers are redundant. In large data centers, it is generally recommended that you dedicate specific Exchange 2003 servers to handle only inbound and outbound SMTP traffic. These servers are usually called SMTP gateway servers or SMTP hubs. These servers are responsible for moving SMTP e-mail between clients and Exchange 2003 mailbox servers (back-end servers).

For information about planning your routing design and configuration (including recommendations for creating routing groups and connectors), see Planning an Exchange Server 2003 Messaging System. For information about how to configure message routing, see the Exchange Server 2003 Transport and Routing Guide.

Using Multiple Physical Sites To improve disaster recovery and increase availability, some organizations use multiple physical sites. Most multi-site designs include a primary site and one or more remote sites that mirror the primary site. The level at which components and data are mirrored between sites depends on the SLA and the business requirements. Another option is to implement geographically dispersed clusters. With geographically dispersed clusters, in the event of a disaster, applications at one site can fail over to another site. The following sections provide more information about site mirroring and geoclustering. Site Mirroring Site mirroring involves using either synchronous or asynchronous replication to mirror data (for example, Exchange 2003 databases and transaction log data) from the primary site to one or more remote sites. Using site mirroring to provide data redundancy in multiple physical sites

If a complete site failure occurs at the primary site, the amount of time it takes to bring Exchange services online at the mirrored site depends on the complexity of your Exchange organization, the amount of preconfigured standby hardware you have, and your level of administrative support. For example, an organization may be able to follow a preplanned set of disaster recovery procedures and bring their Exchange messaging system online within 24 hours. Although 24 hours may seem like a lot of downtime, you may be able to recover data close to the point of failure. For information about synchronous and asynchronous replication of Exchange data, see "Exchange Data Replication Technologies" in Overview of Storage Technologies.

Geographically Dispersed Clusters

A more advanced way to implement fault tolerance at the site level is to implement geographically dispersed clusters. To deploy geographically dispersed clusters with Windows Server 2003, you use virtual LANs (VLANs) to connect SANs over long distances. Using geographically dispersed clustering to provide application failover between physical sites

Geographically dispersed cluster configurations can be complex, and the clustered servers must use only components supported by Microsoft. You should deploy geographically dispersed clusters only with vendors who provide qualified configurations. For more information about geographically dispersed cluster solutions with Exchange 2003, see Planning for Exchange Clustering. For information about Windows Server 2003 and geographically dispersed clusters, see Geographically Dispersed Clusters in Windows Server 2003.

Operational Best Practices

When operating and administering your Exchange 2003 messaging system, it is important that your IT staff use standard IP best practices. This section provides best practices for maximizing the availability of your applications and computers. (This information applies to both clustered and non-clustered environments.) Minimize or eliminate support for multiple versions of operating systems, service packs, and out-of-date applications It is difficult to provide reliable support when multiple combinations of different software and hardware versions are used together in one system (or in systems that interact on the network). Out-of-date software, protocols, and drivers (and associated hardware) are impractical when they do not support new technologies. Set aside resources and time for planning, testing, and installing new operating systems, applications, and hardware. When planning software upgrades, work with users to identify the features they require. Provide training to ease users through software transitions. In your software and support budget, provide funds for upgrading applications and operating systems in the future.

Isolate unreliable applications

An unreliable application is an application that your business cannot do without, but that does not meet appropriate standards for reliability. If you must work with such an application, there are two basic approaches you can take:

 Remove the unreliable applications from the servers that are most critical to your enterprise. If an application is known to be unreliable, take steps to isolate it, and do not run the application on a mission-critical server.  Provide sufficient monitoring, and use automatic restarting options where appropriate. Sufficient monitoring requires taking snapshots of important system performance measurements at regular intervals. You can set up automatic restarting of an application or service by using the Services snap-in. For more information about Windows services, see "Services overview" in Windows Server 2003 Help. Use current, standardized hardware Incompatible hardware can cause performance problems and data loss. Maintain and follow a hardware standard for new systems, spare parts, and replacement parts.

Plan for future capacity requirements Capacity planning is critical to the success of highly available systems. To understand how much extra capacity currently exists in the system, study and monitor your system during peak loads.

Maintain an updated list of operational procedures When a root system problem is fixed, make sure you remove any outdated procedures from operation and support schedules. For example, when software is replaced or upgraded, certain procedures might become unnecessary or no longer be valid. Pay special attention to procedures that may have become routine. Make sure that all procedures are necessary and not temporary fixes for issues for which the root cause has not been found.

Perform adequate monitoring practices If you do not adequately monitor your messaging system, you might not identify problems before they become critical and cause system failures. Without monitoring, an application or server failure could be your only notification of a problem.

Determine the nature of the problem before reacting If the operations staff is not trained and directed to analyze problems carefully before reacting, your personnel can spend large amounts of time responding inappropriately to a problem. They also might not be effectively using monitoring tools in the crucial time between the first signs of a problem and an actual failure.

Treat the root cause of problems instead of treating symptoms When an unexpected failure occurs or when performing short-term preventive maintenance, symptom treatment is an effective strategy for restoring services. However, symptom treatments that are added to standard operating procedures can become unmanageable. Support personnel can be overwhelmed with symptom treatments and might not be able to correctly react to new failures. void stopping and restarting services and servers to end error conditions Stopping and restarting a server may be necessary at times. However, if this process temporarily fixes a problem but does not address the root cause, it can create additional problems.

Laboratory Testing and Pilot Deployments Before you deploy any new solution, whether it is fault tolerant or network hardware, a software monitoring tool, or a Windows Clustering solution, you should thoroughly test the solution before deploying it in a production environment. After testing in an isolated lab, test the solution in a pilot deployment in which only a few users are affected, and then make any necessary adjustments to the design. After you are satisfied with the pilot deployment, perform a full-scale deployment in your production environment. Depending on the number of users in your Exchange organization, you may want to perform your full-scale deployment in stages. After each stage, verify that your system can accommodate the increased processing load from the additional users before deploying the next group of users. For complete information about setting up test and pilot environments, see "Designing a Test Environment" and "Designing a Pilot Project" in the Microsoft Windows Server 2003 Deployment Kit.

Exchange Capacity Planning Tools To determine how many Exchange servers are required to manage user load, use the following capacity planning tools:

 Exchange Server Load Simulator 2003 (LoadSim)  Exchange Server Stress and Performance (ESP) tool  Jetstress

Important:

Because some of these tools create accounts that have insecure passwords, these tools are intended for use in test environments, not in production environments.

Exchange Server Load Simulator 2003

With Exchange Server Load Simulator 2003 (LoadSim), you can simulate the load of MAPI clients against Exchange. You simulate the load by running LoadSim tests on client computers. These tests send messaging requests to the Exchange server, causing a load on the server. Use the output from these tests in the following ways:

 To calculate the client computer response time for the server configuration under client load  To estimate the number of users per server  To identify bottlenecks on the server You can download LoadSim 2003 from the Downloads for Exchange Server 2003 Web site.

Exchange Server Stress and Performance Tool The Exchange Server Stress and Performance (ESP) 2003 tool is a highly scalable stress and performance tool for Exchange. It simulates large numbers of client sessions by concurrently accessing one or more protocol services. Scripts control the actions that each simulated user performs. The scripts contain the logic for communicating with the server. Test modules (DLLs) then run these scripts. Test modules connect to a server through Internet protocols, calls to application programming interfaces (APIs), or through interfaces like OLE DB. ESP is modular and extensible and currently provides modules for most Internet protocols, including the following:

 WebDAV  Internet Message Access Protocol version 4rev1 (IMAP4)  Lightweight Directory Access Protocol (LDAP)  OLE DB  Post Office Protocol version 3 (POP3)  Simple Mail Transfer Protocol (SMTP) You can download ESP 2003 at http://go.microsoft.com/fwlink/?linkid=27881.

Jetstress

Exchange 2003 is a disk-intensive application. To function correctly, Exchange requires a fast, reliable disk subsystem. Jetstress (Jetstress.exe) is an Exchange tool that helps administrators verify the performance and stability of the disk subsystem prior to deploying Exchange servers in a production environment. For more information about Jetstress and Exchange back-end storage, see Planning a Reliable Back-End Storage Solution.

You can download Jetstress at http://go.microsoft.com/fwlink/?linkid=27883.

Using Jetstress to Test Disk Performance

Exchange 2003 is a disk-intensive application. To function properly, it requires a fast, reliable disk subsystem. Jetstress (Jetstress.exe) is an Exchange tool that allows administrators to test the performance and stability of the disk subsystem prior to introducing the server into a production environment.

Specifically, Jetstress tests disk performance by simulating the Exchange disk I/O load. To verify that your disk subsystem meets or exceeds your performance criteria, you can use System Monitor, Event Viewer, and Eseutil.exe in conjunction with Jetstress.

With Jetstress you can perform two types of tests: the Jetstress Disk Performance Test and the Jetstress Disk Subsystem Stress Test. The Jetstress Disk Performance Test runs for two hours and allows you to verify the performance and sizing of your storage solution. The Jetstress Disk Subsystem Stress Test runs for 24 hours and enables you to test the storage reliability over a significant amount of time. Running both tests is the best way to verify the integrity and performance of your disk subsystem.

After successfully completing the Jetstress Disk Performance Test and Jetstress Disk Subsystem Stress Test in a non-production environment, you can move to the next stage in your Exchange 2003 deployment process. By running Jetstress, you will have ensured that your Exchange 2003 disk subsystem is adequately sized (in terms of performance criteria you establish) for the user count and user profiles you established.

Note:

Jetstress is supported only when running versions of Ese.dll from Exchange 2000 or later. Because of this support limitation, Jetstress is supported only on Microsoft Windows Server 2003; Windows Server 2003, Datacenter Edition; Windows® 2000 Server; and Windows 2000, Advanced Server. Windows NT® Server 4.0 and earlier are not supported.

To download Jetstress and the accompanying documentation, see the Downloads for Exchange Server 2003 Web site.

For information about other tools you can use for Exchange capacity planning, see "Exchange Capacity Planning Tools" in System-Level Fault Tolerant Measures.

Planning for Exchange Clustering

Server clustering is an excellent way to increase the availability of your Microsoft® Exchange Server 2003 messaging system. Specifically, server clusters provide failover support and high availability for mission-critical Exchange applications and services. This section provides planning considerations and strategies for deploying server clustering in your Exchange 2003 organization. For information about deploying and administering Exchange 2003 clusters, see the following resources:  For deployment information, see "Deploying Exchange 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide.  For administration information, see "Managing Exchange Server Clusters" in the Exchange Server 2003 Administration Guide.

Before you plan and deploy Exchange 2003 clusters, you must be familiar with Microsoft Windows® Clustering concepts. For information about Windows Clustering technologies, see the following resources:

 The "Clustering Technologies" section of the Microsoft Windows Server 2003 Technical Reference  Microsoft Windows Server™ 2003 Help  Microsoft Developer Network (MSDN®) Benefits and Limitations of Clustering

In general, Exchange clustering provides high availability by allowing your mission-critical applications to keep running in the event of a failure. Although clustering adds additional complexity to your messaging environment, it provides a number of advantages over using stand-alone (non-clustered) servers.

The following is a general summary of clustering benefits and limitations.

Clustering benefits

Clustering provides:

 Reduced single points of failure through Exchange Virtual Server (EVS) failover functionality.  Ability to perform maintenance and upgrades with limited downtime.  Ability to easily scale up your cluster to a maximum of seven active EVSs. Clustering limitations

Clustering does not provide protection from:

 Shared storage failures.  Network service failures.  Operational errors.  Site disasters (unless a geographically dispersed clustering solution has been implemented).

For information about the fault tolerant benefits of clustering, see "Implementing a Server Clustering Solution" in System-Level Fault Tolerant Measures.

Exchange 2003 Clustering Features

Exchange 2003 offers many clustering improvements, including support, performance, and security improvements. The following are some of the significant Exchange 2003 clustering features:

 Support for up to eight-node clusters Exchange has added support for up to eight-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 the performance of clustering by reducing the amount of time it takes a server to fail over to a new node.  Improved security Exchange cluster servers are now more secure. For example, the Exchange 2003 permissions model has changed, and Kerberos authentication protocol is enabled by default.  Improved prerequisite checking Exchange performs more prerequisite checks to help make sure your cluster servers are deployed and configured properly.

The following sections discuss these features in detail.

Note:

Some of the improvements to clustering discussed in this section become available when using Windows Server 2003 in conjunction with Exchange 2003. For information about additional benefits of using Windows Server 2003 for your Exchange 2003 clusters, see Technical Overview of Windows Server 2003 Clustering Services.

Support for Up to Eight-Node Clusters

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 clusters with three or more nodes is that at least one node must be passive. For complete details about the supported cluster configurations based on Windows and Exchange editions, see "Windows and Exchange Edition Requirements" in Understanding Exchange Server 2003 Clustering.

Note:

All Exchange 2003 clustering recommendations are for active/passive cluster configurations. For information about active/passive and active/active cluster configurations, see "Cluster Configurations" in Understanding Exchange Server 2003 Clustering.

Support for Volume Mount Points

Volume mount points are now supported on shared disks when the nodes of your cluster are running Window Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. 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 volume mount points, see "Windows Server 2003 Volume Mount Points" in Planning Considerations for Clustering.

Improved Failover Performance

For clustering in Exchange 2003, the amount of time it takes for a node to fail over to another node is reduced, thereby improving overall performance. The following sections provide information about the improvements to failover times.

Improved Dependency Hierarchy for Exchange Services

To decrease the amount of time it takes to fail over a server, Exchange 2003 provides an improved dependency hierarchy for Exchange services. Specifically, in Exchange 2000, the Exchange protocol services are dependent on the Microsoft Exchange Information Store service. However, in Exchange 2003, these services are dependent on the Microsoft Exchange System Attendant service.

Hierarchy of Exchange dependencies in Exchange 2000

Hierarchy of Exchange dependencies in Exchange 2003

Note: In Exchange 2003, the Internet Message Access Protocol version 4rev1 (IMAP4) and Post Office Protocol version 3 (POP3) resources are not created automatically when you create a new Exchange Virtual Server (EVS).

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 start and stop simultaneously, thereby improving failover time. Additionally, if the Exchange store stops, it no longer must wait for its dependencies to go offline before the store resource can be brought back online

Improved Detection of Available Nodes

When running Exchange 2003 on Windows Server 2003, the Cluster service automatically detects the available node. The overall time it takes for Exchange to fail over to the available node is reduced. Therefore, for both planned and unplanned failovers, downtime is reduced.

Improved Security

Exchange 2003 clustering includes the following security features:

 The clustering permission model has changed.  Kerberos is enabled by default on Exchange Virtual Servers (EVSs).  Internet Protocol security (IPSec) support from front-end servers to clustered back-end servers is included.  IMAP4 and POP3 resources are not added by default when you create an EVS.

The following sections discuss each of these features in detail. Clustering Permission Model Changes

The permissions needed to create, delete, or modify an EVS 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.

Note:

In the following sections, the term cluster administrator refers to the person who manages Exchange clusters for your organization.

Exchange 2000 Permissions Model

For an Exchange 2000 cluster administrator to create, delete, or modify an EVS, the cluster administrator's account and the Cluster service account require the following permissions:

 If the EVS is the first EVS in the organization, you must have Exchange Full Administrator permissions at the organizational level.  If the EVS is not the first EVS in the organization, you must have Exchange Full Administrator permissions at the administrative group level. Exchange 2003 Permissions Model

In Exchange 2003, the permissions model has changed. The Windows Cluster service account is no longer Exchange-specific. This means that the Cluster service account no longer requires that the Exchange Full Administrator role be applied to it, neither at the Exchange organizational level nor at the administrative group level. The default permissions for the Cluster service account in the forest are sufficient for it to function in Exchange.

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

 If the EVS is the first EVS 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 EVS is not the first EVS in the organization, the cluster administrator 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 on the configuration of your topology, your cluster administrators must have the following additional permissions:

 When your Exchange organization is in native mode, if the EVS is in a routing group that spans multiple administrative groups, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at the administrative group level for all of the administrative groups that the routing group spans. For example, if the EVS 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 for the First Administrative Group and must use an account that is a member of a group that has the Exchange Full Administrator role for the Second Administrative Group.

Note:

Routing groups in Exchange organizations that are running in native mode can span multiple administrative groups. Routing groups in Exchange organizations that are running in mixed mode 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, you must have Exchange Administrator Only permissions at the organizational level to specify the server responsible for Recipient Update Service in the child domain. Kerberos Enabled by Default on Exchange Virtual Servers

Kerberos is the authentication protocol in Microsoft Windows 2000 Server and later that provides mutual authentication. However, the Cluster service did not support Kerberos enabled cluster groups until Service Pack 3 (SP3) for Windows 2000. Because of this, the older authentication protocol, NTLM, was the default authentication protocol for Exchange servers running in clusters.

Because Kerberos is supported in the Cluster service on Windows 2000 with SP3 or later or Windows Server 2003 and Exchange 2003, Kerberos is enabled by default when you create an EVS on a server running Windows Server 2003 or Windows 2000 with SP3.

IPSec Support from Front-End Servers to Clustered Back-End Servers

You can use 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.

IMAP4 and POP3 Resources Not Added by Default

For improved security, when you create an EVS, the IMAP4 and POP3 protocol resources are no longer created. For more information about enabling IMAP4 or POP3, see "Managing Exchange Clusters," in the Exchange Server 2003 Administration Guide.

Checking Clustering Prerequisites

To ensure that your clusters meet certain requirements, Exchange 2003 performs more prerequisite checks on clusters than previous versions of Exchange. For example, to help make sure that Exchange is correctly installed on your cluster nodes, Exchange 2003 performs more pre-installation checks on the cluster nodes. Similarly, to help make sure that your EVSs are correctly configured, Exchange 2003 performs more checks on your cluster when creating and removing EVSs.

For a complete list of the prerequisite checks that Exchange performs, see the following resources:

 The "Deploying Exchange 2003 in a Cluster" section in the Exchange Server 2003 Deployment Guide.  The "Managing Exchange Clusters" section in the Exchange Server 2003 Administration Guide. Understanding Exchange Server 2003 Clustering

Windows Clustering technologies can help you achieve scalability, availability, reliability, and fault tolerance for your Exchange 2003 organization. A cluster consists of individual computers (also called nodes) that function cohesively in a Cluster service. These computers act as network service providers or as reserve computers that assume the responsibilities of failed nodes. Depending on how you configure your cluster, clustering can simplify the process of recovering a single server from disasters.

Note:

The clustering solution described in this topic (Windows Clustering) is not supported on front-end servers. Front-end servers should be stand-alone servers, or should be load balanced using Windows Server 2003 Network Load Balancing (NLB). For information about NLB and front-end and back-end server configurations, see "Ensuring Reliable Access to Exchange Front-End Servers" in System-Level Fault Tolerant Measures.

In a clustering environment, Exchange runs as a virtual server (not as a stand-alone server) because any node in a cluster can assume control of a virtual server. If the node running the EVS experiences problems, the EVS goes offline for a brief period until another node takes control of the EVS. All recommendations for Exchange clustering are for active/passive configurations. For information about active/passive and active/active cluster configurations, see "Cluster Configurations" later in this topic.

A recommended configuration for your Exchange 2003 cluster is a four-node cluster comprised of three active nodes and one passive node. Each of the active nodes contains one EVS. This configuration is cost-effective because it allows you to run three active Exchange servers, while maintaining the failover security provided by one passive server.

Recommended configuration of a four-node Exchange cluster

Note: All four nodes of this cluster are running Windows Server 2003, Enterprise Edition and Exchange 2003 Enterprise Edition. For information about the hardware, network, and storage configuration of this example, see "Four-Node Cluster Scenario" in the Exchange Server 2003 Deployment Guide.

This section discusses the following aspects of Exchange 2003 clustering:

 Windows Clustering  Exchange Virtual Servers  Quorum disk resource  Cluster configurations  Windows and Exchange version requirements  Example of a two-node cluster topology  Understanding failovers  IP addresses and network names

Windows Clustering

To create Exchange 2003 clusters, you must use Windows Clustering. Windows Clustering is a feature of Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition. The Windows Cluster service controls all aspects of Windows Clustering. When you run Exchange 2003 Setup on a Windows Server 2003 cluster node, the cluster-aware version of Exchange is automatically installed. Exchange 2003 uses the following Windows Clustering features:

 Shared nothing architecture Exchange 2003 back-end clusters require the use of a shared-nothing architecture. In a shared-nothing architecture, although all nodes in the cluster can access shared storage, they cannot access the same disk resource of that shared storage simultaneously. For example, in Figure 5.3, if Node 1 has ownership of a disk resource, no other node in the cluster can access the disk resource until it takes over the ownership of the disk resource.  Resource DLL Windows communicates with resources in a cluster by using a resource DLL. To communicate with Cluster service, Exchange 2003 provides its own custom resource DLL (Exres.dll). Communication between the Cluster service and Exchange 2003 is customized to provide all Windows Clustering functionality. For information about Exres.dll, see Microsoft Knowledge Base article 810860, "XGEN: Architecture of the Exchange Resource Dynamic Link Library (Exres.dll)."  Groups To contain EVSs in a cluster, Exchange 2003 uses Windows cluster groups. An EVS in a cluster is a Windows cluster group containing cluster resources, such as an IP address and the Exchange 2003 System Attendant.  Resources EVSs include Cluster service resources, such as IP address resources, network name resources, and physical disk resources. EVSs also include their own Exchange-specific resources. After you add the Exchange System Attendant Instance resource (an Exchange-specific resource) to a Windows cluster group, Exchange automatically creates the other essential Exchange-related resources, such as the Exchange HTTP Virtual Server Instance, the Exchange Information Store Instance, and the Exchange MS Search Instance.

Exchange Virtual Servers

To create an Exchange 2003 cluster, you create a Windows Server 2003 cluster group and then add specific resources to that group. Exchange 2003 clusters create logical servers referred to as Exchange Virtual Servers (EVSs). Unlike a stand-alone (non-clustered) Exchange 2003 server, an EVS is a cluster group that can be failed over if the primary server running the EVS fails. When one cluster node fails, one of the remaining nodes assumes the responsibilities of the failed EVS. To access this new server, clients can use the same server name.

An EVS is a cluster group that requires, at a minimum, the following resources:

 Static IP address.  Network name.  One or more physical disks for shared storage.  An Exchange 2003 System Attendant resource. (The System Attendant resource installs other required Exchange resources.)

The following figure illustrates Exchange 2003 cluster resources and the resource dependencies.

Exchange 2003 cluster resources and dependencies

Note:

In Exchange 2003, when you create a new EVS, the IMAP4 and POP3 resources are not automatically created. For more information about IMAP4 and POP3 resources, see "Managing Exchange Clusters," in the Exchange Server 2003 Administration Guide.

Client computers connect to an EVS the same way they connect to a stand-alone Exchange 2003 server. Windows Server 2003 provides the IP address resource, the Network Name resource, and disk resources associated with the EVS. Exchange 2003 provides the System Attendant resource and other required resources. When you create the System Attendant resource, all other required and dependant resources are created.

The following table lists the Exchange 2003 cluster resources and their dependencies.

Exchange 2003 cluster resources and dependencies

Resource Description Dependency

System System Attendant is the fundamental resource that controls the Network Name Attendant creation and deletion of all the resources in the EVS. resource and shared disk resources

Exchange Provides mailbox and public folder storage for Exchange. System Attendant store

SMTP Handles relay and delivery of e-mail messages. System Attendant

IMAP4 Optional resource that provides access to e-mail messages for System Attendant IMAP4 clients.

POP3 Optional resource that provides access to e-mail messages for POP3 System Attendant clients. HTTP Provides access to Exchange mailboxes and public folders by means System Attendant of HTTP (for example, Microsoft Office Outlook® Web Access 2003).

Exchange MS Provides content indexing for the EVS. System Attendant Search Instance

Message There can be only one MTA per cluster. The MTA is created on the System Attendant transfer agent first EVS. All additional EVSs are dependent on this MTA. The MTA is (MTA) responsible for communication with an X.400 system and for interoperation with Exchange 5.5.

Routing Builds the link state tables. System Attendant service

Exchange 2003 clusters do not support the following Windows and Exchange 2003 components:

 Active Directory Connector (ADC)  Exchange 2003 Calendar Connector  Exchange Connector for Lotus Notes  Exchange Connector for Novell GroupWise  Microsoft Exchange Event service  Site Replication Service (SRS)  Network News Transfer Protocol (NNTP)

Note:

The NNTP service, a subcomponent of the Windows Server 2003 Internet Information Services (IIS) component, is still a required prerequisite for installing Exchange 2003 in a cluster. After you install Exchange 2003 in a cluster, the NNTP service is not functional.

Cluster Groups

When you configure an Exchange cluster, you must create groups to manage the cluster, as well as the EVSs in the cluster. Moreover, you can independently configure each EVS. When creating cluster groups, consider the following recommendations:

 The Microsoft Distributed Transaction Coordinator (MSDTC) resource is required for Exchange Server Setup and Service Pack Setup. On a cluster that is dedicated to Exchange, it is recommended that the MSDTC resource be added to the default Cluster Group. It is further recommended that the 'Affect the Group' option be unchecked for the MSDTC resource. This prevents a failure of the MSDTC resource from affecting the default cluster group.  For information about adding the MSDTC resource in Windows Server 2003, see Microsoft Knowledge Base article 301600, "How to Configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 Cluster." Microsoft Knowledge Base article 301600 includes a reference to article 817064, "How to enable network DTC access in Windows Server 2003." It is an Exchange Server security best practice to not enable network DTC access for an Exchange cluster. If you are configuring the Distributed Transaction Coordinator resource for an Exchange cluster, do not enable network DTC access.  To provide fault tolerance for the cluster, do not add any other applications or cluster resource to the default cluster group other than the MSDTC resource, and do not use the quorum volume for anything other than the cluster quorum and MSDTC resource.  Assign each group its own set of Physical Disk resources. This allows the transaction log files and the database files to fail over to another node simultaneously.  Use separate physical disks to store transaction log files and database files. Separate hard disks prevent the failure of a single spindle from affecting more than one group. This recommendation is also relevant for Exchange stand-alone servers.

For more information about storage considerations for server clusters, see "Cluster Storage Solutions" in Planning Considerations for Clustering.

Quorum Disk Resource

The most important resource in the cluster is the quorum disk resource. The quorum disk resource maintains configuration data for the cluster, including the quorum log, the cluster database checkpoint, and the resource checkpoints. The quorum resource also provides persistent physical storage across system failures. If you are running Windows Server 2003, you can select from the following quorum types:

Note:

If you are running Windows 2000, you must use the standard quorum.

 Standard quorum (also known as a single quorum) With a standard quorum, the quorum disk resource data is hosted on a shared physical disk resource that is accessible by all cluster nodes. When using a standard quorum, because the cluster configuration data is kept on the quorum disk resource, all cluster nodes must be able to communicate with the node that currently owns it.  Majority node set quorum With a majority node set quorum, the quorum data is stored locally on the system disk of each cluster node. The Majority Node Set resource makes sure that the cluster configuration data stored on the majority node set quorum is kept consistent across the disks.

The following figure illustrates a standard quorum disk and a majority node set quorum for a four-node cluster.

A standard quorum and majority node set quorum

When a cluster is created or when network communication between nodes in a cluster fails, the quorum disk resource prevents the nodes from forming multiple clusters. To form a cluster, a node must arbitrate for and gain ownership of the quorum disk resource. For example, if a node cannot detect a cluster during the discovery process, the node attempts to form its own cluster by taking control of the quorum disk resource. However, if the node does not succeed in taking control of the quorum disk resource, it cannot form a cluster.

The quorum disk resource stores the most current version of the cluster configuration database in the form of recovery logs and registry checkpoint files. These files contain cluster configuration and state data for each individual node. When a node joins or forms a cluster, the Cluster service updates the node's individual copy of the configuration database. When a node joins an existing cluster, the Cluster service retrieves the configuration data from the other active nodes.

The Cluster service uses the quorum disk resource recovery logs to:

 Guarantee that only one set of active, communicating nodes can operate as a cluster.  Enable a node to form a cluster only if it can gain control of the quorum disk resource.  Allow a node to join or remain in an existing cluster only if it can communicate with the node that controls the quorum disk resource.

Note:

You should create new cluster groups for EVSs, and no EVS should be created in the cluster group with the quorum disk resource.

When selecting the type of quorum for your Exchange cluster, consider the advantages and disadvantages of each type of quorum. For example, to keep a standard quorum running, you must protect the quorum disk resource located on the shared disk. For this reason, it is recommended that you use a RAID solution for the quorum disk resource. Moreover, to keep a majority node set cluster running, a majority of the nodes must be online. Specifically, you must use the following equation:

/2 + 1.

For detailed information about selecting a quorum type for your cluster, see "Choosing a Cluster Model" in the Windows Server 2003 Deployment Kit.

Cluster Configurations

With the clustering process, a group of independent nodes works together as a single system. Each cluster node has individual memory, processors, network adapters, and local hard disks for operating system and application files, but shares a common storage medium. A separate private network, used only for cluster communication between the nodes, can connect these servers.

In general, for each cluster node, it is recommended that you use identical hardware (for example, identical processors, identical network interface cards, and the same amount of RAM). This practice helps ensure that users experience a consistent level of performance when accessing their mailboxes on a back-end server, regardless of whether the EVS that is providing access is running on a primary or a stand-by node. For more information about the benefits of using standardized hardware on your servers, see "Standardized Hardware" in Component-Level Fault Tolerant Measures.

Note:

Depending on roles of each cluster node, you may consider using different types of hardware (for example, processors, RAM, and hard disks) for the passive nodes of your cluster. An example is if you have an advanced deployment solution that uses the passive cluster nodes to perform your backup operations. For information about how you can implement different types of hardware on your cluster nodes, see Messaging Backup and Restore at Microsoft.

The following sections discuss Exchange 2003 cluster configurations—specifically, active/passive and active/active configurations. Active/passive clustering is the recommended cluster configuration for Exchange. In an active/passive configuration, no cluster node runs more than one EVS at a time. In addition, active/passive clustering provides more cluster nodes than there are EVSs. Note:

Before you configure your Exchange 2003 clusters, you must determine the level of availability expected for your users. After you make this determination, configure your hardware in accordance with the Exchange 2003 cluster that best meets your needs.

Active/Passive Clustering

Active/passive clustering is the strongly recommended cluster configuration for Exchange. In active/passive clustering, an Exchange cluster includes up to eight nodes and can host a maximum of seven EVSs. (Each active node runs an EVS.) All active/passive clusters must have one or more passive nodes. A passive node is a server that has Exchange installed and is configured to run an EVS, but remains on stand-by until a failure occurs.

In active/passive clustering, when one of the EVSs experiences a failure (or is taken offline), a passive node in the cluster takes ownership of the EVS that was running on the failed node. Depending on the current load of the failed node, the EVS usually fails over to another node after a few minutes. As a result, the Exchange resources on your cluster are unavailable to users for only a brief period of time.

In an active/passive cluster, such as the 3-active/1-passive cluster illustrated in the following figure, there are three EVSs: EVS1, EVS2, and EVS3. This configuration can handle a single-node failure. For example, if Node 3 fails, Node 1 still owns EVS1, Node 2 still owns EVS2, and Node 4 takes ownership of EVS3 with all of the storage groups mounted after the failure. However, if a second node fails while Node 3 is still unavailable, the EVS associated with the second failed node remains in a failed state because there is no stand-by node available for failover.

Effect of failures on an active/passive cluster

Active/Active Clustering

Active/active is a strongly discouraged cluster configuration for Exchange. When using an active/active configuration for your Exchange clusters, you are limited to two nodes. If you want more than two nodes, one node must be passive. For example, if you add a node to a two-node active/active cluster, Exchange does not allow you to create a third EVS. In addition, after you install the third node, no cluster node will be able to run more than one EVS at a time.

Important:

Regardless of which version of Windows you are running, Exchange 2003 and Exchange 2000 do not support active/active clustering with more than two nodes. For more information, see Microsoft Knowledge Base article 329208 "Exchange virtual server limitations on Exchange 2000 clusters and Exchange 2003 clusters that have more than two nodes."

In an active/active cluster, there are only two EVSs: EVS1 and EVS2. This configuration can handle a single node failure and still maintain 100 percent availability after the failure occurs. For example, if Node 2 fails, Node 1, which currently owns EVS1, also takes ownership of EVS2, with all of the storage groups mounted. However, if Node 1 fails while Node 2 is still unavailable, the entire cluster is in a failed state because no nodes are available for failover.

Effect of failures on an active/active cluster

If you decide to implement active/active clustering, you must comply with the following requirements:

 Scalability requirements To allow for efficient performance after failover, and to help ensure that a single node of the active/active cluster can bring the second EVS online, you should make sure that the number of concurrent MAPI user connections on each active node does not exceed 1,900. In addition, you should make sure that the average CPU utilization by the Microsoft Exchange Information Store (store.exe) on each node does not exceed 40 percent. For detailed information about how to size the EVSs running in an active/active cluster, as well as how to monitor an active/active configuration, see "Performance and Scalability Considerations" in Planning Considerations for Clustering.  Storage group requirements As with stand-alone Exchange servers, each Exchange cluster node is limited to four storage groups. In the event of a failover, for a single node of an active/active cluster to mount all of the storage groups within the cluster, you cannot have more than four total storage groups in the entire cluster. For more information about this limitation, see "Storage Group Limitations" in Planning Considerations for Clustering.

Because of the scalability limitations of active/active Exchange clusters, it is recommended that you deploy active/passive Exchange clusters. Active/active clusters are not recommended under any circumstances.

Example of a Two-Node Cluster Topology

Although a typical cluster topology includes more than two nodes, an easy way to explain the differences between active/passive and active/active clusters is to illustrate a simple two-node cluster topology.

In this example, both cluster nodes are members of the same domain, and both nodes are connected to the public network and a private cluster network. The physical disk resource is the shared disk in the cluster. If only one cluster node owns one EVS, the cluster is active/passive. If both nodes own one or more EVSs, or if either node owns two EVSs, the cluster is active/active.

Example of a two-node Exchange cluster

Windows and Exchange Edition Requirements

To create Exchange clusters, specific editions of Windows and Exchange are required. The following table lists these requirements.

Windows and Exchange edition requirements

Cluster nodes Windows editions Exchange editions available

Windows Server 2003, Exchange Server 2003 Enterprise Edition Up to eight Enterprise Edition

Windows Server 2003, Exchange Server 2003 Enterprise Edition Up to eight Datacenter Edition

Windows Server 2003 or Windows Exchange Server 2003 Standard Edition None Server 2000

Windows Server 2003, Standard Edition Exchange Server 2003 Standard Edition or None or Windows 2000 Server Exchange Server 2003 Enterprise Edition

Windows 2000 Advanced Server Exchange Server 2003 Enterprise Edition Up to two

Windows 2000 Datacenter Server Exchange Server 2003 Enterprise Edition Up to four

Note:

In active/passive clustering, you can have up to eight nodes in a cluster, and it is required that each cluster have one or more passive nodes. In active/active clustering, you can have a maximum of two nodes in a cluster. For more information about the differences between active/active and active/passive clustering, see "Cluster Configurations" earlier in this topic.

Understanding Failovers

As part of your cluster deployment planning process, you should understand how the failover process works. There are two scenarios for failover: planned and unplanned.

In a planned failover:

1. The Exchange administrator uses the Cluster service to move the EVS to another node. 2. All EVS resources go offline. 3. The resources move to the node specified by the Exchange administrator. 4. All EVS resources go online.

In an unplanned failover:

1. One (or several) of the EVS resources fails. 2. During the next IsAlive check, Resource Monitor discovers the resource failure. 3. The Cluster service automatically takes all dependent resources offline. 4. If the failed resource is configured to restart (default setting), the Cluster service attempts to restart the failed resource and all its dependent resources. 5. If the resource fails again:  Cluster service tries to restart the resource again.

-or-

 If the resource is configured to affect the group (default), and the resource has failed a certain number of times (default=3) within a configured time period (default=900 seconds), the Cluster service takes all resources in the EVS offline. 6. All resources are failed over (moved) to another cluster node. If specified, this is the next node in the Preferred Owners list. For more information about configuring a preferred owner for a resource, see "Specifying Preferred Owners" in the Exchange Server 2003 Administrations Guide. 7. The Cluster service attempts to bring all resources of the EVS online on the new node. 8. If the same or another resource fails again on the new node, the Cluster service repeats the previous steps and may need to fail over to yet another node (or back to the original node). 9. If the EVS keeps failing over, the Cluster service fails over the EVS a maximum number of times (default=10) within a specified time period (default=6 hours). After this time, the EVS stays in a failed state. 10. If failback is configured (default=turned off), the Cluster service either moves the EVS back to the original node immediately when the original node becomes available or at a specified time of day if the original node is available again, depending on the group configuration.

IP Addresses and Network Names

A typical cluster installation includes a public network that client computers use to connect to EVSs and a private network for cluster node communication. To make sure that you have sufficient static IP addresses available, consider the following requirements:

 Each cluster node has two static IP addresses (the public and private network connection IP addresses of each node) and one NetBIOS name.  The cluster itself has a static IP address and a NetBIOS name.  Each EVS has a static IP address and a NetBIOS name.

It is recommended that an -node cluster with EVSs use 2×n + e + 1 IP addresses. The +1 in this equation assumes that the quorum disk resource and the MSDTC resource will both be located in the default cluster group. For more information about these recommendations, see "Cluster Groups" earlier in this topic.

For a two-node cluster, the recommended number of static IP addresses is five plus the number of EVSs. For a four-node cluster, the recommended number is nine plus the number of EVSs.

Important:

It is recommended that you use static IP addresses in any cluster deployment. Using Dynamic Host Configuration Protocol (DHCP) prevents client computers from connecting to the cluster. If the DHCP server fails to renew the IP lease, the entire cluster may fail. It is also recommended that you use a private network for cluster communication. A public network connection failure on one node prevents the cluster nodes from communicating with each other. As a result, the failure blocks affected resources from failing over and may even cause the entire cluster to fail.

The following figure provides an example of the IP addresses and other components required in a four-node Exchange cluster configuration.

Example of IP addresses in a four-node Exchange cluster

Planning Considerations for Clustering

The following considerations are important when planning for Exchange 2003 clusters. These considerations apply to Exchange 2003 clusters on Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; Windows 2000 Advanced Server, and Windows 2000 Datacenter Server:

 Dedicating computers to Exchange  Cluster storage solutions  Performance and scalability considerations  Cluster hardware compatibility  Geographically dispersed clustering  Disaster recovery strategies for clusters

The following sections discuss these considerations in detail.

Dedicating Computers to Exchange

In addition to Exchange 2003, your server clusters can run other applications. However, if you run multiple applications on the same node, the performance of your Exchange Virtual Servers can be affected. When deciding whether to dedicate computers to only Exchange, consider the following:

 If you use a cluster for more than one application, consider dedicating a node for each application and make sure that enough passive nodes are available.  If you use clusters to provide Exchange services to your users, it is recommended that you run only Exchange 2003 on your clusters and run other applications on separate hardware.  For best results, an EVS should not fail over to an active node that runs another application.  Exchange 2003 cluster nodes must be member servers of a domain. Exchange 2003 clusters do not support cluster nodes as domain controllers or global catalog servers.

For more information about the performance of Exchange 2003 clusters, see "Managing Exchange Clusters" in the Exchange Server 2003 Administration Guide.

Cluster Storage Solutions

A detailed discussion about selecting a cluster storage solution is beyond the scope of this guide. However, this section provides general recommendations and strategies for implementing a cluster storage solution.

Most of the best practices that apply to stand-alone (non-clustered) servers apply to clustered servers as well (for example, RAID solutions and SAN solutions). For detailed information about Exchange storage solutions, see Planning a Reliable Back-End Storage Solution.

For detailed information about selecting a cluster storage method in Windows Server 2003, see Choosing a Cluster Storage Method.

Separate Hard Disks for Log Files

If the storage groups for an EVS are configured so that the log files are on one set of physical drives and the databases on another, all of the drives must be configured as disk resources within the same EVS. Specifically, all of the data must be on a shared disk, and all of the physical disk resources must be part of the Exchange cluster group. This allows the log files and the storage group databases to fail over to another node if the EVS goes offline.

Note:

The System Attendant should be made dependent on all physical disk resources (drives and volume mount points) that contain Exchange data. This ensures that the System Attendant resource can properly access Exchange data on the physical disk resources of the EVS. If the System Attendant is not dependent on these resources, Exchange resources may start before they have access to read data on the physical disk resources. This can cause the following Exchange database error: -1022 Jet_errDiskIO. For information about the -1022 Exchange database error, see Microsoft Knowledge Base article 314917, "Understanding and analyzing -1018, - 1019, and -1022 Exchange database errors."

Storage Group Limitations

Exchange 2003 is limited to four storage groups per server. This is a physical limitation and applies to each node of a cluster as well. This limitation may create problems with active/active configurations but does not affect active/passive configurations.

Note:

Active/passive clustering is the strongly recommended configuration for Exchange 2003. For information about why active/passive clustering is recommended, see "Cluster Configurations" in Understanding Exchange Server 2003 Clustering.

To help explain why this storage group limitation affects only active/active clusters, consider a two-node active/active cluster, where one node contains two storage groups and the other node contains three storage groups.

Two-node active/active cluster configuration five storage groups

Exchange Virtual Server State Storage group names

Node 1 Exchange Virtual Server (EVS)1 Active storage group 1, storage group 2, storage group 3

Node 2 EVS2 Active storage group 1, storage group 2

In this table, the Exchange cluster includes a total of five storage groups. If EVS2 on Node 2 fails over to Node 1, Node 1 cannot mount both storage groups because it will have exceeded the four-storage-group limitation. As a result, EVS2 does not come online on Node 1. If Node 2 is still available, EVS2 fails over back to Node 2.

Note:

For backup and recovery purposes, Exchange 2003 does support an additional storage group, called the recovery storage group. However, the recovery storage group cannot be used for cluster node failover purposes. For more information about recovery storage groups, see "New Recovery Features for Exchange 2003" in the Exchange Server 2003 Disaster Recovery Planning Guide.

Drive Letter Limitations

Before you deploy your Exchange 2003 cluster, make sure you have considered the Windows limitation of 26 drive letters per server. If you plan to configure the majority of the server disks as shared cluster resources, the 26 drive letter limitation applies to the entire cluster, not just to each individual node. Regardless of the number of cluster nodes, the maximum number of shared disks is typically 22. The reason the maximum number of shared disks is 22 and not 26 is because one disk must be reserved for the system disk on each node, and two additional disks are typically assigned for the floppy disk and CD (or DVD) drives.

Note:

If your cluster nodes are running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition, you can use volume mount points to avoid the 26 drive letter limitation. For more information, see "Windows Server 2003 Volume Mount Points" later in this topic.

It is recommended that you use one drive letter for the databases and one for the log files of each storage group. In a four-node cluster with three EVSs, you can have up to 12 storage groups. Therefore, more than 22 drive letters may be needed for a four-node cluster.

The following sections provide information about planning your cluster storage solution, depending on whether your operating system is Windows Server 2003 or Windows 2000.

Understanding Windows 2000 Drive Letter Limitations

For certain four-node cluster configurations running Windows 2000 Datacenter Server, you may need to disable one or more drives to make room for more shared disks in the cluster. For example, you may want to disable the CD- ROM or DVD-ROM drives on your servers. Maximizing the number of shared disks can reduce your ability to map drives for network share access.

Note:

Because Windows 2000 does not support the use of volume mount points (a form of logical disk), you cannot use volume mount points for your Exchange shared disks with Windows 2000. However, you can use volume mount points for local drives (for example, CD-ROM or DVD drives).

This drive letter limitation is also a limiting factor in how you design storage group and database architecture for an Exchange cluster. The following sections provide examples of how you can maximize data reliability on your cluster when using Windows Server 2003. Disk Configuration with Three Storage Groups

The configuration shown in the following table is reliable—each storage group (storage group 1, storage group 2, and storage group 3) has a dedicated drive for its databases and a dedicated drive for its log files. An additional disk is used for the EVS SMTP queue directory. However, with this design, you are limited to three storage groups per EVS.

3-active/1-passive cluster architecture with three EVSs, each with three storage groups

Node 4 Node 1 (EVS1 active) Node 2 (EVS2 active) Node 3 (EVS3 active) (passive)

Disk 1: SMTP/MTA Disk 8: SMTP Disk 15: SMTP Disk 22: Quorum

Disk 2: storage group 1 Disk 9: storage group 1 Disk 16: storage group 1 databases databases databases

Disk 3: storage group 1 logs Disk 10: storage group 1 Disk 17: storage group 1 logs logs

Disk 4: storage group 2 Disk 11: storage group 2 Disk 18: storage group 2 databases databases databases

Disk 5: storage group 2 logs Disk 12: storage group 2 Disk 19: storage group 2 logs logs

Disk 6: storage group 3 Disk 13: storage group 3 Disk 20: storage group 3 databases databases databases

Disk 7: storage group 3 logs Disk 14: storage group 3 Disk 21: storage group 3 logs logs

Disk Configuration with Four Storage Groups

The configuration shown in the following table adds an additional storage group. However, to stay within the 22- disk limit, the databases of each of the four storage groups per EVS (storage group 1, storage group 2, storage group 3, and storage group 4) are combined across two disks. The database files (.edb and .stm) of storage group 1 and storage group 2 share a common disk volume, and the database files of storage group 3 and storage group 4 share a common disk volume. The benefit of this configuration is that you can use all four storage groups in a four-node cluster. The disadvantage is that the volumes that house the shared storage group databases may need to be large. As a result, if a database disk fails, two storage groups are affected instead of one.

3-active/1-passive cluster architecture with three EVSs, each with four storage groups

Node 4 Node 1 (EVS1 active) Node 2 (EVS2 active) Node 3 (EVS3 active) (passive)

Disk 1: SMTP/MTA Disk 8: SMTP Disk 15: SMTP Disk 22: Quorum

Disk 2: storage group 1 and Disk 9: storage group 1 and Disk 16: storage group 1 and storage group 2 databases storage group 2 databases storage group 2 databases

Disk 3: storage group 1 logs Disk 10: storage group 1 logs Disk 17: storage group 1 logs

Disk 4: storage group 1 logs Disk 11: storage group 2 logs Disk 18: storage group 2 logs

Disk 5: storage group 3 and Disk 12: storage group 3 and Disk 19: storage group 3 and storage group 4 databases storage group 4 databases storage group 4 databases

Disk 6: storage group 3 logs Disk 13: storage group 3 logs Disk 20: storage group 3 logs Disk 7: storage group 4 logs Disk 14: storage group 4 logs Disk 21: storage group 4 logs

Windows Server 2003 Volume Mount Points

Volume mount points are now supported on shared disks when your cluster nodes (four nodes or more) are running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. Volume mount points (also known as NTFS junction points or mounted drives) 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.) Volume mount points bypass the need to associate each disk volume with a drive letter, thereby surpassing the 26-drive letter limitation.

Mount points are useful for large Exchange clusters (for example, four-node or eight-node clusters) that cannot provide a sufficient number of drive letters to deliver the best performance and reliability. For information about how mount points can be used to reduce the number of drive letters, see Using Clustering with Exchange 2003: An Example.

When installing volume mount points in clusters, consider the following:

 Make sure that you create unique volume mount points so that they do not conflict with existing local drives on any cluster node.  Do not create volume mount points between disks on the cluster storage device (cluster disks) and local disks.  Do not create volume mount points from the cluster disk that contains the quorum disk resource. You can, however, create a volume mount point from the quorum disk resource to a clustered disk.  Volume mount points from one cluster disk to another must be in the same cluster resource group and must be dependent on the root disk. Specifically, the volume mount point disk will not come online unless the root disk is first online. Setting this dependency prevents time-outs and failures when starting.

It is recommended that you use volume mount points with Exchange 2003 clusters that have four or more nodes. You should use one root disk per storage group. You can place the logs on the root disk and place the database on the mounted drive. If there are not enough drive letters available (such as in an 8-node cluster), you can use a single root disk. However, in case of disk failure, to minimize the risk of data loss, do not store data on the root disk. You need one root disk for each EVS.

For more information about support for mount points, see Microsoft Knowledge Base article 318458, "Volume Mount Point Support for an Exchange Server 2003 Cluster on a Windows Server 2003-based System."

For more information about adding a volume mount point to an EVS, see the following resources:

 "Deploying Exchange 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide  Microsoft Knowledge Base article 280297, "How to Configure Volume Mount Points on a Clustered Server" Performance and Scalability Considerations

This section discusses the following performance and scalability aspects of server clustering:

 Sizing active/passive clusters  Sizing active/active clusters  Scaling up or scaling out  Testing clustered server components

Important:

Similar to the effect that virtual memory fragmentation has on stand-alone (non-clustered) servers, Exchange cluster nodes (especially active/active cluster nodes) are also affected by virtual memory fragmentation. For tuning and monitoring information that can help you manage virtual memory fragmentation in a cluster, see "Managing Exchange Clusters" in the Exchange Server 2003 Administration Guide.

For more information about performance and scalability in Exchange 2003, see the Exchange Server 2003 Performance and Scalability Guide.

Sizing Active/Passive Clusters

Just as you would for stand-alone servers, you need to size your active/passive clusters.

Note:

Before deploying your clustered servers, it is recommended that you test your sizing metrics in a laboratory environment. To perform these tests, you can use Exchange tools such as Exchange Server Load Simulator 2003 (LoadSim) and Jetstress. For information about the importance of laboratory testing and pilot deployments, see "Laboratory Testing and Pilot Deployments" in System-Level Fault Tolerant Measures.

Sizing Active/Active Clusters

Active/active clusters are not a recommended configuration for Exchange clusters. However, if you decide to implement active/active clustering, remember that Exchange supports only two-node active/active clusters. Also, with active/active clusters, there are two important constraints to consider:

 The number of concurrent user connections per node cannot exceed 1,900. If you have more than one EVS per node, make sure that the sum of all concurrent MAPI user connections is less than 1,900.  The average CPU load per server cannot exceed 40 percent.

If these requirements are not met, your users may notice a significant decrease in performance after a failover. In addition, there is the risk that a single node of the active/active cluster may not be able to bring the second EVS online.

Note:

Monitoring Considerations for Active/Active Clusters

After you deploy your active/active cluster, you must do the following:

 Monitor the CPU load for each cluster node.  Monitor the number of concurrent connections (users) per node.

Note:

Consider monitoring these values during peak e-mail usage intervals. That way, if a failover is required during a peak e-mail period, you will know if the single node can run both EVSs. Also, you can monitor a counter manually in real time, or you can use it to compile a report during a specified period (for example, during a two-hour peak e-mail interval). Monitoring CPU Loads for Each Cluster Node

If the CPU load exceeds 40 percent (load generated from users) for more than 10 minutes, move mailboxes off the server. This load does not include administrative load increases (for example, moving users). To monitor the CPU load for each node in the active/active cluster, use the following Performance Monitor (Perfmon) counter:

Performance/%Processor time/_Total counter

Note:

Do not be concerned with spikes in CPU performance. Normally, a server's CPU load will spike beyond 80 or even 90 percent.

Monitoring Concurrent Connections (Users) per Node

If the number of concurrent users per node exceeds 1,900 for more than 10 minutes, move mailboxes off the EVS. Although you can meet this requirement by locating only 1,900 mailboxes on each EVS in your active/active cluster, it is generally recommended that you monitor the number of concurrent MAPI users per server. One reason to monitor this is because some users may be making multiple connections to their mailboxes.

To monitor the number of concurrent users per node, use one or both of the following Perfmon counters:

 MSExchangeIS/Active Connection Count  MSExchangeIS Mailbox(_Total)/Active Client Logons

Note:

These counters will provide somewhat different results, and will count Outlook Web Access connections differently than Outlook connections. To understand how the server is being used, monitor the changes in these counters during a typical work day

Scaling Up or Scaling Out

When considering how you can accommodate more users (or perhaps more messages per user) in your clustered environment, one option is to scale up. Scaling up refers to the process of using more powerful server components on your cluster nodes to meet increased performance demands. However, it is important to consider that, as you scale up the hardware on your cluster nodes (for example, so you can host more users on each node), the availability of each node becomes significantly more important.

An alternative to scaling up is to scale out. Scaling out refers to the process of adding nodes to a cluster.

To explain these two options, consider an organization that that hosts 3,000 users on a four-node cluster. The cluster has three active nodes (1,000 users per node) and one passive node. If the need to accommodate an additional 1,000 users emerges, the organization has two options:

 Option 1: Scale up Specifically, upgrade the RAM and CPUs on each of the cluster nodes and then distribute the additional 1,000 users evenly on among the nodes.  Option 2: Scale out Specifically, add an additional node to the cluster. This changes the cluster configuration to a five-node cluster with four active nodes, each active node hosting 1,000 mailboxes.

In this example, if a disaster causes one of the servers to fail, implementing option two would affect fewer users. Therefore, when deploying Exchange in a cluster, consider scaling out as part of your scalability plan.

Scaling out can also increase the fault tolerance of your Exchange cluster. For example, a four-node, 2-active/2- passive cluster can handle more simultaneous failures than a four-node, 3-active/1-passive cluster. For more information about active/passive clustering, see "Active/Passive Clustering" in Understanding Exchange Server 2003 Clustering.

Testing Clustered Server Components Before you deploy your clustered servers in a production environment, it is important that you test their capacity. The tools you use to test your cluster deployment are the same you use to test non-clustered servers (for example LoadSim and Jetstress). For information about the importance of laboratory testing and pilot deployments, see "Laboratory Testing and Pilot Deployments" in System-Level Fault Tolerant Measures.

The following lists provide testing considerations specific to server clustering.

Test the following hardware components:

 Individual computer components such as hard disks, controllers, processors, and RAM  External components such as routers, bridges, switches, cabling, and connectors

Set up the following stress tests:

 Test cluster performance under heavy network loads  Test cluster performance under heavy disk input/output (I/O) to the same disk  Test cluster performance under heavy Exchange services load  Test cluster performance under a large number of simultaneous logon attempts  Fail over each EVS at least once to each of the nodes. Do this under heavy Exchange services load

Use the output from these tests to:

 Calculate the client response time for the server configuration under client load.  Estimate the number of users per server.  Identify bottlenecks on the server.

Cluster Hardware Compatibility

For Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition, Microsoft supports only complete server cluster systems selected from the Windows Server Catalog.

The support for third-party system components is limited based on the requirements of the third-party solutions. For more information, see Microsoft Knowledge Base article 814607, "Microsoft Support for Server Clusters with 3rd Party System Components."

In general, it is recommended that you use identical hardware (for example, identical processors, identical NICs, and the same amount of RAM) for each cluster node. For more information about why this is recommended, and when you may want to consider using asymmetrical hardware in your cluster nodes, see "Cluster Configurations" in Understanding Exchange Server 2003 Clustering.

Note:

For a geographically dispersed cluster, both the hardware and software configuration must be certified and listed in the Windows Server Catalog. For information about hardware compatibility for geographically dispersed clusters, see "Qualified Configurations for Geographically Dispersed Clusters" later in this topic.

For more information about cluster hardware, see Microsoft Knowledge Base article 309395, "The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog."

Geographically Dispersed Clustering

The main goal of a geographically dispersed cluster is to ensure that loss of one site does not cause a loss of the complete application. Geographically dispersed clustering provides enhanced availability and recoverability for Exchange e-mail services. (However, the cluster nodes in the alternate recovery site do not provide Exchange services unless a site failure occurs.) Moreover, in the event of a site disaster, geographically dispersed clusters provide fault tolerance and failover for specific applications. Many hardware and software solutions exist for Exchange geographically dispersed clustering that provide business continuity at both the site and cluster level.

As you plan your geographically dispersed cluster solution, be sure that you have answers to the following questions:

 What main issues must my geographically dispersed cluster address?  What are the qualified configurations for a geographically dispersed cluster?  What Cluster service requirements must be met by a geographically dispersed clustering solution?  The remainder of this section provides information about each of these questions.

For general information about how geographically dispersed clustering helps provide fault tolerance for your Exchange 2003 organization, see "Using Multiple Physical Sites" in System-Level Fault Tolerant Measures.

Issues that a Geographically Dispersed Cluster Must Address

A geographically dispersed cluster must address the following issues:

 How can you make sure that multiple sites have independent copies of the same data? How are data changes replicated across sites? If data is changed at one site, and that site fails, how are those changes transmitted to the remaining sites?  If one site fails, how can an application such as Exchange 2003 continue to provide Exchange services?  How can you make sure your geographically dispersed clusters are protected from natural disasters?

Solving the first issue does not present much of a problem for the replication of read-only data between physical sites—you can easily copy read-only data and an instance of that data can be hosted at each site. To solve the issue of data replication, you can implement software and hardware mirroring or synchronous replication. These replication techniques enable you to keep current data mirrors of each physical site.

To solve the second issue, you must implement a failover clustering solution. For this solution to work, the cluster nodes in separate physical sites must appear to the Cluster service as being on the same network. You can accomplish this by using virtual local area networks (VLANs). VLANS allow you to connect in separate physical locations over long distances.

To solve the third issue, make sure your sites are spaced far enough apart so that a natural disaster would not impact more than one site. Each site should have completely different power sources and different communications infrastructure providers.

The following figure illustrates a basic geographically dispersed cluster with these solutions in place.

Basic geographically dispersed cluster topology

Qualified Configurations for Geographically Dispersed Clusters

A geographically dispersed cluster is a combination of hardware and software components supplied by original equipment manufacturers (OEMs) and software vendors. Exchange 2003 geographically dispersed cluster configurations can be complex, and the clusters must use only components supported by Microsoft. Geographically dispersed clusters should be deployed only in conjunction with vendors who provide qualified configurations.

In general, the restrictions that apply to Windows Server 2003 geographically dispersed clusters also apply to Exchange 2003. For detailed information about geographically dispersed clusters in Windows Server 2003, see Geographically Dispersed Clusters in Windows Server 2003.

The hardware in a geographically dispersed cluster must be qualified and appear on the Microsoft Hardware Compatibility List. For a separate Hardware Compatibility List for geographically dispersed clusters, see the Windows Server Catalog.

Note:

You can create geographically dispersed clusters by adding data-replication software and extended LAN hardware to existing certified configurations. However, these solutions radically change the nature of a pre- certified configuration, particularly with respect to timing and latency. To be supported by Microsoft, the hardware and software configuration of a geographically dispersed cluster must be certified and listed on the cluster Hardware Compatibility List.

For additional information about the Hardware Compatibility List and Windows Clustering, see Microsoft Knowledge Base article 309395, "The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog." Cluster Service Technology Requirements

Windows Clustering software is unaware of the extended nature of geographically dispersed clusters. Specifically, the Cluster service does not include features that are unique to geographically dispersed cluster configurations. Therefore, the network and storage architecture of geographically dispersed clusters must meet the following requirements:

 The private and public network connections must be in the same subnet (non-routed LAN). To implement this, use VLANs to ensure that all cluster nodes are on the same IP subnets.  The network connections must be able to provide a maximum guaranteed round trip latency between nodes of no more than 500 milliseconds. The cluster uses heartbeat to detect whether a node is alive or not responding. These heartbeats are sent out on a periodic basis (every 1.2 seconds). If a node takes too long to respond to heartbeat packets, the Cluster service starts a heavy-weight protocol to figure out which nodes are still functional and which ones are unavailable. This is known as a cluster re-group.  If you are using a standard-node quorum (also known as a single quorum), the cluster must have a single shared disk (known as the quorum disk).

Note:

If you are running Exchange 2003 on Windows Server 2003, you can avoid this requirement by using the majority node set quorum. For more information about quorum types, see "Quorum Disk Resource" in Understanding Exchange Server 2003 Clustering.

 To make a set of disks in two separate sites appear to the Cluster service as a single disk, the storage infrastructure can provide mirroring across the sites. However, it must preserve the fundamental semantics that are required by the physical disk resource:  The Cluster service uses Small Computer System Interface (SCSI) reserve commands and bus reset to arbitrate for and protect the shared disks. The semantics of these commands must be preserved across the sites, even if communication between the sites fails. If a node on Site A reserves a disk, nodes on Site B should not be able to access the contents of the disk. To avoid data corruption of cluster and application data, these semantics are essential.  The quorum disk must be replicated in real-time, synchronous mode across all sites. The different members of a mirrored quorum disk must contain the same data.

Disaster Recovery Strategies for Clusters

For information about disaster recovery strategies specific to Exchange 2003 clusters, see "Backing up Exchange 2003 Clusters" and "Restoring Exchange 2003 Clusters" in the Exchange Server 2003 Disaster Recovery Operations Guide.

Implementing Software Monitoring and Error-Detection Tools

Monitoring your Microsoft® Exchange Server 2003 organization is critical to ensuring the high availability of messaging and collaboration services. Monitoring tools and techniques allow you to determine your system's health and identify potential issues before an error occurs. For example, monitoring tools allow you to proactively check for problems with connections, services, server resources, and system resources. Monitoring tools can also help you notify administrators when problems occur.

As you plan your monitoring strategy, you must decide which system components you want to monitor and how frequently you want to monitor them. To help with these decisions, consider the following questions:  Is messaging a mission-critical service in your organization? (In general, if Exchange messaging is a mission-critical service in your organization, you should monitor your system more frequently.)  What services do you rely on most? (In general, you should vigorously monitor the services on which most of your users rely.)

After considering these basic questions, you can begin planning a monitoring strategy that allows you to optimize the performance and availability of your Exchange 2003 messaging system.

Note:

Prescriptive guidance for monitoring Exchange 2003 is beyond the scope of this guide. For detailed information about monitoring your Exchange messaging system, see Monitoring Exchange Server 2003 at Microsoft. Although this document focus on using Microsoft Operations Manager (MOM) to monitor an enterprise messaging environment, the information is applicable whether or not you use MOM.

Monitoring Strategies

A common misconception is that monitoring is simply an automatic process in which your system administrators are notified of major issues. However, there are many monitoring strategies that can help increase the availability of your messaging system. This section provides overviews of some of the more important monitoring strategies.

Monitoring in Pre-Deployment Environments

Before deploying Exchange 2003 in a production environment, you should test your Exchange messaging system in a laboratory and pilot deployment. Moreover, to make sure that your system will perform adequately in a production environment, you should carefully monitor all aspects of the test deployment.

To monitor your test deployment, you can use the following tools in conjunction with the tools discussed in this section:

 Exchange Server Stress and Performance (ESP) 2003  Jetstress  Exchange Server Load Simulator 2003 (LoadSim)  These tools are available for download from the Downloads for Exchange Server 2003 Web site.

For information about using these tools, see "Laboratory Testing and Pilot Deployments" in System-Level Fault Tolerant Measures.

Routine (Daily) Monitoring

After deploying Exchange 2003 in a production environment, you must develop a routine monitoring strategy. This strategy should include allocating a substantial number of administrative resources for monitoring tasks. The information in this topic can help you plan a routine monitoring strategy.

Establishing a routine monitoring strategy has the following advantages:

 Helps make sure that the performance requirements of your service level agreements (SLAs) are being met  Helps make sure that specific administrative tasks (such as daily backup operations) are being successfully completed  Enables you to detect and address issues in your Exchange organization before they affect productivity Monitoring for Troubleshooting Purposes

There are various ways in which you may be notified of performance problems within your Exchange 2003 messaging system. For example, one way is when users notify your messaging support staff of a loss in e-mail services. Another way is through routine monitoring results. In some cases, you may be able to quickly resolve the issue without extensive diagnosis. However, for complex issues, you may need to temporarily increase the level at which you are monitoring specific components of your system.

For example, if a routine monitoring report notifies you that there is significant latency in regard to e-mail messages sent from one mailbox server to another, you can increase the depth at which you monitor the servers involved. Specifically, to create a more detailed report of the latency issues, you can use the Windows Server 2003 Performance Monitor (Perfmon) tool. In addition, you can use the Exchange 2003 tools Queue Viewer and Message Tracking Center. You can use Queue Viewer to monitor the specific message queue for any message flow problems. You can use Message Tracking Center to view the path of a message as it is flows through your messaging infrastructure.

After using these monitoring tools and examining additional monitoring reports, you should be more able to determine the root cause of the issue. In general, an increase in monitoring can help you regain your expected performance levels.

For information about Queue Viewer and Messaging Tracking Center, see "Exchange 2003 Monitoring Features" in Monitoring Features and Tools. For information about Performance Monitor, see "Windows Monitoring Features and Tools" in Monitoring Features and Tools.

For information about how to monitor your Exchange 2003 organization, including how to determine the root causes of performance issues, see Troubleshooting Exchange Server 2003 Performance.

For information about tuning your Exchange 2003 organization, see the Exchange Server 2003 Performance and Scalability Guide.

Monitoring for Long-Term Trend Analysis

Whenever possible, you should establish long-term monitoring strategies to help you with trend analysis and capacity planning.

Establishing a long-term monitoring strategy has the following advantages:

 Increases your ability to predict when system expansion is necessary  Assists in identifying strategies for load balancing  Helps detect changes in Exchange service usage by client computers  Helps troubleshoot for problems such as memory leaks or abnormal disk consumption

A monitoring strategy that includes measuring the capacity of Exchange resources is important to the long-term success of a highly available messaging system. Specifically, this strategy allows you to anticipate future system usage, scalability, and growth requirements.

Note:

Do not limit capacity planning to components such as disks. Make sure that your plans encompass all system components that could become bottlenecks, such as CPU, memory, network, and domain controller services.

Exchange 2003 and Windows Server 2003 provide monitoring and management tools that can help you monitor for long-term trend analysis. However, it is recommended that you consider additional tools as well. For example, to create a historical trend analysis of your Exchange 2003 messaging system, you can use Microsoft Operations Manager (MOM) 2000 in conjunction with Application Management Pack for Exchange 2003 or a third-party monitoring tool.

For information about MOM 2000 and Application Management Pack for Exchange 2003, see "Microsoft Operations Manager 2000" in Monitoring Features and Tools. For information about third-party monitoring tools, see "Third-Party Monitoring Products" in Monitoring Features and Tools.

Monitoring Features and Tools

Before deploying Microsoft Exchange Server 2003 in a production environment, you should establish routine, automated monitoring and error detection strategies for your operating system and applications. Immediately detecting application and system errors increases your chances of resolving errors before the system shuts down. Monitoring can also help alert you of scalability needs. For example, if one or more servers are operating at capacity some or all of the time, you can decide if you need to add more servers or upgrade the hardware of existing servers.

For more information about monitoring, see "Monitoring and status tools" in Windows Server 2003 Help.

You can use the following tools and programs to monitor your Exchange Server 2003 organization:

 Exchange 2003 monitoring tools  Windows Server 2003 monitoring tools  Additional monitoring tools  Monitoring with MOM  Third-party tools

Exchange 2003 Monitoring Features

Exchange System Manager includes the following features to help you monitor your Exchange 2003 organization:

 Monitoring and Status  Queue Viewer  Diagnostic logging  Protocol logging  Message Tracking Center

For procedural information about using these features, see Exchange 2003 Help.

Monitoring and Status

The Monitoring and Status feature in Exchange System Manager includes basic monitoring and reporting functionality that allows you to view the status of servers and connectors in your organization. In addition, you can use Monitoring and Status to notify administrators when services fail or when specific resource thresholds are reached (for example, when the free disk space on a particular disk reaches a specific capacity). To access the Monitoring and Status feature in Exchange System Manager, expand Tools in the console tree.

The following sections provide an overview of the Monitoring and Status feature. For procedural information about how to use Monitoring and Status, see Exchange 2003 Help.

Verifying Server and Connector Status

To make sure that your servers are operating properly, you can use Monitoring and Status to view the list of servers in your organization and their current status. You can also use Monitoring and Status to verify that your connectors are available to transmit messages. To view the status of servers and connectors, in Exchange System Manager, expand Tools, expand Monitoring and Status, and then click Status.

Note:

If you set warning and critical state thresholds to monitor server resources, the server status displays a warning or critical state icon if thresholds are met or exceeded. You can access server monitors from the same window in which you verify server status.

Setting Notifications

When setting notifications, you can alert an administrator by e-mail or you can use a script to respond to server or connector problems. To configure notifications, in Exchange System Manager, expand Tools, expand Monitoring and Status, and then click Notifications. You can only send notifications in the following circumstances:

 If a server enters a warning state  If a server enters a critical state  If a connector enters a down state

You cannot send a notification if a server resource is low. After an alert is sent, you can use the Status window to view the state of a server or connector and use the Monitor tab to view server resource monitor states.

Components You Can Monitor in Exchange System Manager

To configure the resources you want to monitor, use the Monitoring tab in the server's Properties. Specifically, you can use this tab to define the parameters within which your server's hardware and software should function before a warning or critical state icon is displayed. After resource monitoring thresholds are met or exceeded, a warning icon is displayed on both the Monitoring tab of a server's Properties and on the Status node under Monitoring and Status.

Note:

Regular maintenance should include checking the status of all server resources to see if resources are low and if additional resources, such as memory, are required.

You can use Exchange System Manager to monitor the following components:

 Virtual memory  CPU utilization  Free disk space  Simple Mail Transfer Protocol (SMTP) queue growth  Windows Server 2003 services  X.400 queue growth Virtual Memory

Because applications use virtual memory to store instructions and data, problems can occur when there is not enough virtual memory available. To monitor the available virtual memory on your Exchange server, use the Monitoring tab to add performance limits. When the amount of available virtual memory falls below a specified limit (for a specified duration), the virtual memory monitor is identified on the Monitoring tab with a warning or critical state icon. You can set a limit for a warning state, a critical state, or both.

CPU Utilization

You can monitor the percent of your server's CPU utilization. When CPU utilization is too high, Exchange 2003 may stop responding.

Note:

During some server events, CPU utilization may increase to high levels. When the server event is complete, CPU utilization returns to normal levels. The duration that you specify should be greater than the number of minutes that such system events normally run.

To monitor CPU utilization, use the Monitoring tab to add performance limits. When the amount of CPU utilization exceeds a specified limit (for a specified duration), the CPU utilization monitor is identified on the Monitoring tab with a warning or critical state icon. You can set a limit, in percent, for both a warning state and a critical state.

Free Disk Space

To make sure that enough disk space is available to use virtual memory and store application data after an application is closed, use the Monitoring tab to add performance limits. When the amount of available disk space falls below a specified limit, the free disk space monitor is identified on the Monitoring tab with a warning or critical state icon. You can set a limit for a warning state, a critical state, or both.

SMTP Queue Growth

If a SMTP queue continuously grows, e-mail messages do not leave the queue and are not delivered to another Exchange server as quickly as new messages arrive. This can be an indication of network or system problems. To avoid delays in delivering messages, you should monitor SMTP queue growth. When the queue continuously grows for a specified period of time, the SMTP queue monitor displays a warning icon on the Monitoring tab. You can set a growth threshold for a warning state, a critical state, or both.

Windows Server 2003 Service Monitor

You can use the Windows Server 2003 service monitor to monitor the Windows Server 2003 services running on your Exchange server. To monitor a Windows Server 2003 service on your server running Exchange 2003, use the Monitoring tab. If a service is not running, you can specify the type of warning you receive. You can also monitor multiple Windows Server 2003 services using a single Windows Server 2003 service monitor.

X.400 Queue Growth

If an X.400 queue continuously grows, e-mail messages do not leave the queue and are not delivered to an Exchange Server 5.5 or X.400 server as quickly as new messages arrive. This can be an indication of network or system problems. To avoid delays in delivering messages, you should monitor X.400 queue growth. When the queue continuously grows for a specified period of time, the X.400 queue monitor displays a warning icon on the Monitoring tab. You can set a growth threshold for a warning state, a critical state, or both.

Queue Viewer

Queue Viewer is a utility in Exchange 2003 that allows you to maintain and administer your organization's messaging queues, as well as the messages contained within those queues. Queue Viewer is available on all SMTP virtual servers, X.400 objects, and all installed Microsoft Exchange Connectors for Novell GroupWise, Lotus Notes, and Lotus cc:Mail.

To access Queue Viewer, in Exchange System Manager, expand the server you want, and then click Queues. Expanding Queues reveals one or more system queues, which are default queues specific to the protocol transporting the messages (SMTP, X.400, or MAPI). The system queues are always visible.

The link queues are also visible in the Queues container. These queues are visible only if the SMTP virtual server, X.400 object, or connector is currently holding or sending messages to another server. Link queues contain outbound messages that are going to the same next-destination server.

Diagnostic Logging

You can use Exchange 2003 diagnostic logging to record significant events related to authentication, connections, and user actions. Viewing these events helps you keep track of the types of transactions being conducted on your Exchange servers. By default, the logging level is set to None. As a result, only critical errors are logged. However, you can change the level at which you want to log Exchange-related events. To do this, on the Diagnostics Logging tab of a server's Properties, select a service and one or more categories to monitor, and then select the logging level you want. After you configure the logging level, you can view the log entries in Event Viewer. In Event Viewer, events are logged by date, time, source, category, event number, user, and computer. To help resolve issues for any server in your organization, you can research errors, warnings, and diagnostic information in the event data. Use the event's Properties page to view the logging information and text for the event. For more information about using Event Viewer, see Windows Server 2003 Help.

Note:

It is not recommended that you use the maximum logging settings unless instructed to do so by Microsoft Product Support Services. Maximum logging considerably drains resources.

Protocol Logging

The protocol logging feature provides detailed information about SMTP and Network News Transfer Protocol (NNTP) commands. This feature is particularly useful in monitoring and troubleshooting protocol or messaging errors. To enable protocol logging, in an SMTP or NNTP virtual server's Properties, on the General tab, select the Enable logging check box.

Message Tracking Center

Message Tracking Center can track messages in both Exchange 2003 organizations and mixed Exchange 2003 and Exchange 5.5 organizations. To access Message Tracking Center, in Exchange System Manager, expand Tools, and then click Message Tracking Center. Message Tracking Center can also track messages going to or coming in from a foreign e-mail system, such as Lotus Notes. You cannot track the path of a message that is forwarded after the message arrives at a foreign e-mail system, but you can determine whether the message was delivered successfully. When using Message Tracking Center, you must complete two main tasks: First, you must search for and select a particular message to track. Then, you can view the history of the message path. You can also save the history of the message path to a text file for reference if message tracking logs are cleared.

Note:

By default, message tracking is not enabled. To enable message tracking, in Exchange System Manager, on the General tab of each server's Properties, enable mailbox store and public folder store message tracking.

Windows Monitoring Features and Tools

In addition to the monitoring features in Exchange System Manager, there are various Microsoft Windows features and tools you can use to monitor your Exchange 2003 organization. These features and tools include:

 Performance Monitor (Perfmon)  Event Viewer  Network Monitor (Netmon)  Service Control Manager  Shutdown Event Tracker  Windows error reporting  Windows Management Instrumentation (WMI)  Simple Network Management Protocol (SNMP)

Windows Server 2003 Performance Monitor

Windows Server 2003 Performance Monitor (Perfmon) is a tool you can configure to collect information regarding the performance of your messaging system. Specifically, you can use Perfmon to monitor, create graphs, and log performance metrics for core system functions. You can also use Perfmon to monitor Exchange-specific parameters, such as the number of inbound or outbound messages per hour or the number of directory lookups performed by DSAccess and DSProxy. However, Perfmon is commonly used to gather baseline performance data and to monitor key parameters when performance problems occur. With Perfmon, you can monitor a single computer, or you can monitor several computers simultaneously. This flexibility can be helpful when you want to locate a specific problem in your messaging system. Depending on your needs, you can use the Chart window to monitor performance, or you can store data in logs to review later.

Note:

To increase administrator response, you can use Perfmon to generate an e-mail message or a customized notification whenever a counter exceeds or drops below a specified measurement. After the data is generated, you can export it to a spreadsheet or database for further review and analysis.

When planning your performance logging strategy, determine the information you need and collect it at regular intervals. However, performance sampling consumes CPU and memory resources. It is difficult to store and extract useful information from excessively large performance logs. For more information about how to automatically collect performance data, see "Performance Logs and Alerts overview" in Windows Server 2003 Help.

Client-side Monitoring with Perfmon

In previous versions of Exchange, you could not use Perfmon to monitor end-user performance for Microsoft Office Outlook users. However, Exchange 2003 and Outlook 2003 provide this functionality.

Exchange 2003 servers record both remote procedure call (RPC) latency and errors on client computers running Outlook 2003. You can use this information to determine the overall experience quality for your users, as well as to monitor the Exchange server for errors. For detailed information about using Perfmon to monitor client-side performance, see the "Monitoring Outlook Client Performance" section in Performance and Scalability Features of Exchange Server 2003.

Note:

Although you can use Perfmon to monitor client-side RPC data, MOM includes functionality that allows you to monitor this data more easily.

Event Viewer

Event Viewer reports Exchange and messaging system information and is often used in other reporting applications. Whenever you start Windows, logging begins automatically, and you can view the logs in Event Viewer. Event Viewer maintains logs about application, security, and system events on your computer. You can use Event Viewer to view and manage event logs and gather information about hardware and software problems.

To diagnose a system problem, event logs are often the best place to start. By using the event logs in Event Viewer, you can gather important information about hardware, software, and system problems. Windows Server 2003 records this information in the system log, application log, and security log. In addition, some system components (such as the Cluster service) also record events in a log. For more information about event logs, see "Checking event logs" in Windows Server 2003 Help.

Network Monitor

Network Monitor (Netmon) is used to collect network information at the packet level. Monitoring a network typically involves observing resource usage on a server and measuring network traffic. You can use Netmon to accomplish these tasks. Unlike System Monitor, which is used to monitor hardware and software, Netmon exclusively monitors network activity. You can use System Monitor to monitor your network's hardware and software. However, for in- depth traffic analysis, you should use Netmon.

Service Control Manager

Service Control Manager (SCM) is a Microsoft Windows Server tool that maintains a database of installed services. You can configure SCM to automatically restart failed services, thereby increasing availability. For more information about SCM, see the topic "Service Control Manager" in Windows Server 2003 Help.

Shutdown Event Tracker Shutdown Event Tracker is a Windows Server 2003 feature that enables you to consistently track why users restart or shut down their computers. You can use codes to categorize the reasons for each shutdown and record a comment for each. For more information, see "Shutdown Event Tracker overview" in Windows Server 2003 Help.

Windows Error Reporting

With Windows error reporting functionality, you are immediately notified (through a dialog box) of severe errors that occur on your servers running Windows Server 2003 applications. Windows error reporting allows you to send information about any failures that may occur to Microsoft. Microsoft then uses this information to determine and prioritize potential updates to future versions of Windows and Exchange.

Note:

Depending on your system configuration, you can manually send error information to Microsoft, you can have the information sent automatically, or you can turn off the error reporting functionality.

In addition, the integration of Exchange 2003 errors into Windows error reporting allows you to report and review error reporting data related to the following:

 Exchange System Manager  Microsoft Exchange System Attendant service  Directory Services Management  Microsoft Exchange Management service  Exchange Setup  Microsoft Exchange Information Store service

Corporate Error Reporting (CER) is a tool designed for administrators to manage error reports created by the Windows Error Reporting client and error-reporting clients included in other Microsoft programs. For information about installing and using CER, see "Corporate Error Reporting" on the Microsoft Software Assurance Web site.

For more information about error reporting in relation to Exchange issues, see "Reliability and Clustering Features" in What's New in Exchange Server 2003.

Windows Management Instrumentation

Windows Management Instrumentation (WMI) helps you manage your network and applications as they become larger and more complex. With WMI, you can monitor, track, and control system events that are related to software applications, hardware components, and networks. WMI includes a uniform scripting application programming interface (API), which defines all managed objects under a common object framework that is based on the Common Information Model (CIM). Scripts use the WMI API to access information from different sources. WMI can submit queries that filter requests for specific information. WMI can also subscribe to WMI events based on your particular interests, rather than being limited to events predefined by the original developers.

Exchange 2003 provides many WMI classes that you can use to monitor and analyze Exchange servers, track messages, and check mail flow status. The Exchange 2003 SDK contains complete information about the Exchange WMI providers, including many sample scripts to help you get started. You can download or view the Exchange 2003 SDK from the Microsoft Exchange Server Downloads page on MSDN®.

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) allows you to capture configuration and status information about your network and have the information sent to a designated computer for event monitoring. For more information about SNMP, see "SNMP" in Windows Server 2003 Help.

Additional Monitoring Tools and Features In addition to the tools and features of Exchange 2003 and Windows Server 2003, Microsoft provides additional tools and features that can help you monitor and troubleshoot your Exchange 2003 organization. These tools and features include:

 Exchange Server Connection Status  RPC Ping  WinRoute Exchange Server Connection Status

Exchange Server Connection Status is a client-side feature in Outlook 2003 that enables users to quickly determine the status of their connection. This is useful for computers that are experiencing connection problems. Specifically, you can use this feature to check RPC connectivity from client to server, including any intermediate RPC (or RPC over HTTP) proxies in between.

This feature is available for Outlook 2003 users who have e-mail accounts on Exchange 2003 servers. To access this feature, users must press and hold CTRL, right-click the Microsoft Office Outlook icon in the notifications area, and then click Connection Status. The Exchange Server Connection Status dialog box appears, providing users with information about the connection status.

For more information about using Exchange Server Connection Status, see "Verify connection to Exchange through the Internet" in Microsoft Office Outlook 2003 Help.

RPC Ping

You can use the RPC Ping tool to check RPC connectivity from client to server. Specifically, this tool is used to confirm the RPC connectivity between the Exchange 2003 server and any supported Exchange clients, including any intermediate RPC (or RPC over HTTP) proxies in between.

For usage and download information regarding RPC Ping, see Microsoft Knowledge Base article 831051 "How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003."

WinRoute

You can use the WinRoute tool to monitor the routing services on your servers if you suspect a problem. When establishing your routine monitoring strategy, be sure to include the use of this tool. To obtain a visual representation of your Exchange routing topology and the status of the different routing components, you can use WinRoute to connect to the link state port (TCP 691) on an Exchange 2003 server. In addition, WinRoute extracts link state information for your Exchange organization and presents it in a readable format.

You can download WinRoute at http://go.microsoft.com/fwlink/?linkid=25049.

For information about how to use WinRoute, see Microsoft Knowledge Base article 281382, "How to Use the WinRoute Tool."

Microsoft Operations Manager 2000

Microsoft Operations Manager (MOM) 2000 includes a full set of features to help administrators monitor and manage both the events and performance of their information technology (IT) systems running Windows Server 2003 or Windows 2000 Server.

Note:

MOM 2000 is sold separately from Windows Server 2003 and Windows 2000 Server.

MOM uses rules and scripts to define which events and performance counters should be monitored. MOM also provides administrative alerts (including recommended actions that should be performed) when an event occurs, when performance falls outside the acceptable range, or when a probe detects a problem. The MOM 2000 Application Management Pack (which is a set of management pack modules and reports that facilitate the monitoring and management of Microsoft server products) improves the availability of Windows-based networks and server applications. The MOM Application Management Pack includes the Exchange 2003 Management Pack, which extends the capabilities of MOM by providing specialized monitoring for Exchange 2003 servers.

For information about MOM 2000 and the Application Management Pack, see the MOM Web site.

The following sections provide an overview of Exchange 2003 Management Pack for MOM. For detailed information about the Exchange 2003 Management Pack, see the Exchange Server 2003 Management Pack for MOM 2005.

Exchange 2003 Management Pack

The Exchange 2003 Management Pack is designed to help you achieve the highest possible server availability. A key feature of the Exchange 2003 Management Pack is the ability to monitor all of your Exchange servers from a single console or Web page. The Exchange 2003 Management Pack monitors the performance, availability, and security of Exchange 2003, alerting you of events that have a direct impact on server availability while filtering out events that require no action. Through alerts, knowledge base solutions, and reports, the Exchange 2003 Management Pack helps you correct problems before a disaster occurs. The Exchange 2003 Management Pack also includes reports that allow you to summarize server availability and analyze trends.

The Exchange 2003 Management Pack includes the following functionality:

 Provides a complete Exchange solution by monitoring access to Active Directory® directory service, Microsoft Exchange Information Store service, Extensible Storage Engine (ESE), message transport, Exchange clustering, Microsoft Office Outlook Web Access, and Internet protocols (such as SMTP, POP3, and IMAP4).  Detects, alerts, and automatically responds to critical events. The Exchange 2003 Management Pack helps indicate, correct (by referring administrators to Microsoft Knowledge Base articles that can help resolve problems), and in many cases, prevent possible Exchange service outages.  Monitors critical Exchange performance counters. Using performance thresholds and related alert definitions to emphasize performance conditions that may indicate service problems or even possible denial of service attacks, Exchange 2003 Management Pack allows you to identify issues before they become critical.  Contains an array of scripts to monitor single and cross-server usage, performance, reliability, and configuration.  Monitors all Exchange 2003 server configurations, including stand–alone and cluster servers, as well as front-end and back-end servers.  Increases the availability and performance of your Exchange installation. Exchange 2003 Management Pack reduces your total cost of ownership (TCO) by enabling proactive Exchange management. Components and Operations That Are Monitored

The Exchange 2003 Management Pack monitors events that are placed in the application event log by various Exchange components, such as Active Directory access, Microsoft Exchange Information Store service, ESE, message transfer agent (MTA), Outlook Web Access, Internet protocols, and Exchange cluster servers.

The Exchange 2003 Management Pack also quickly notifies you of any service outages or configuration problems, thereby helping to increase the security, availability, and performance of your Exchange 2003 organization. To alert you of critical performance issues, the management pack also monitors all key Exchange performance metrics. Using the MOM reporting feature, you can analyze and graph performance data to understand usage trends, to assist with load balancing, and to manage system capacity.

The Exchange 2003 Management Pack proactively manages your Exchange installation to avoid costly service outages. For example, the Exchange 2003 Management Pack monitors the following components and operations in your organization:  Vital performance monitoring data, which can indicate that the Exchange server is running low on resources.  Important warning and error events from Exchange 2003 servers. Alerts operators of those events.  Disk capacity. Alerts operators when disk capacity is running low. Provides knowledge as to which Exchange files are on the affected drives.  Exchange services that are expected to be running on a specific server.  Exchange database that can be reached by a MAPI client logon. This verifies both the Exchange database and Active Directory functionality.  High queue lengths that are caused by an inability to send e-mail messages to a destination server.  Simultaneous connections. Alerts operators of a high number of simultaneous connections, which often indicates a denial–of–service attack.  Errors or resource shortages that affect service levels.  Mail flow between defined servers, to confirm end-to end mail flow capability within your Exchange organization. Views and Reports

The Exchange 2003 Management Pack includes several views and reports to help you quickly identify Exchange issues. With these views and reports, you can analyze and graph performance data to understand usage trends, do accurate load balancing, and manage system capacity.

Exchange reports cover the following items.

 Exchange 2003 and Exchange 2000 Health Monitoring and Operations Reports You can use the monitoring and operations reports to analyze database sizes, disk usage, mailboxes, server availability, and the configuration of Exchange servers. For example, you can list database sizes for Exchange servers, where database size (in megabytes) is presented for each server, storage group, and database. The reports in this category are as follows:  Exchange Disk Usage This report provides data about servers running Exchange based on disk performance counters, presenting daily averages for each counter.  Exchange Server Availability This report provides the percentage of server availability for Exchange servers during a specified time period and also lists the categories of failure types that could lead to a server being unavailable.  Exchange Server Configuration This report provides configuration information including computer and operating systems configuration and local disk information.  Exchange 2003 Outlook Client Monitoring This report gives you the results of analysis data collected by Exchange 2003 servers monitoring Outlook clients for the end user's experience in terms of response times and errors.  Exchange Mailboxes This report shows the distribution of mailboxes across storage groups and databases for Exchange servers.  Exchange Database Sizes This report shows the total database size on each server, in addition to the individual components of the database. For example, if a database contains both a mailbox store and a public folder store, this report shows the size of each.  Exchange 2003 and Exchange 2000 Protocol Usage Reports The protocol usage reports obtain data about usage and activity levels for the mail protocols that are used by Exchange, such as POP3, IMAP4, and SMTP. You can also obtain usage and activity level reports for Exchange components, such as Microsoft Exchange Information Store service, mailbox store, public folder store, MTA, and Outlook Web Access. These reports use key performance counters for operations conducted in a specific time period. The reports include data for Exchange 2000 servers only when the Exchange 2000 Management Pack for Microsoft Operations Manager is installed.  Exchange 2003 and Exchange 2000 Traffic Analysis Reports The traffic analysis reports summarize Exchange mail traffic patterns by message count and size for both Recipient and Sender domains. For example, the report Mail Delivered: Top 100 Sender Domains by Message Size provides a list of the top 100 sender domains sorted by message size during a specific time period, as reported in the Exchange message tracking logs. The reports include data for Exchange 2000 servers only when the Exchange 2000 Management Pack for Microsoft Operations Manager is installed.  Exchange Capacity Planning Reports By analyzing your daily client logons and messages sent and received, in addition to work queues, the capacity planning reports show the Exchange server resource usage. These reports help you plan for current and future capacity requirements.  Exchange Mailbox and Folder Sizes Reports You can use these reports to monitor the size of Exchange mailboxes and folders and to determine your highest growth areas. The reports in this category include the top 100 mailboxes by size and message count, and the top 100 public folders by size and message count.  Exchange Performance Analysis Report The Queue Sizes report summarizes Exchange performance counters and helps you to analyze queue performance.  Exchange 5.5 Reports There are several Exchange 5.5 reports that can help you obtain data about operations such as average time for mail delivery, as well as pending replication synchronizations and remaining replication updates. There are also several Exchange 5.5 traffic analysis reports available.

For detailed information about monitoring your Exchange messaging system, see Monitoring Exchange Server 2003 at Microsoft.

Third-Party Monitoring Products

Rather than using the monitoring tools and features provided by Exchange 2003, Windows Server 2003, and MOM 2000, you can use third-party products to monitor your Exchange 2003 organization. Third-party monitoring and management tools vary widely in price and capability. This section provides an overview of the features and capabilities available in third-party monitoring and management products.

For information about vendors that offer third-party monitoring solutions, see the Exchange Server Partners Web site.

Third-Party Application Monitoring Products

Some third-party monitoring products are designed to monitor all of the applications in your organization. Other products focus entirely on monitoring Exchange 2003. In general, third-party monitoring products provide similar levels of monitoring functionality and are highly competitive. For example, most third-party monitoring products include features that enable you to proactively monitor your server environment, as well as features that provide a detailed analysis of the logged data. To make sure that you select a monitoring product that meets the needs of your organization, consider evaluating the features of multiple third-party application monitoring products before making a purchasing decision.

Note:

Some third-party application monitoring products offer functionality similar to MOM. However, when selecting a monitoring strategy, it is recommended that you compare the features and functionality of MOM to any third- party solutions.

For more information about selecting third-party monitoring products, see "Selecting Third-Party Monitoring Products" later in this topic.

Third-Party Hardware Monitoring Products

Third-party hardware monitoring products are often designed exclusively to help you monitor and manage your hardware. These monitoring products (often referred to as system management tools) may include both hardware and software as part of the solution.

Essentially, system management tools can be separated into three organizational levels: entry-level, mid-level, and high-level.

 Entry-level system management tools Entry-level system management tools provide the basic information you need to monitor the performance of you server's hardware. The fundamentals of hardware management include monitoring system voltage, fan speed, and thermal conditions, as well as examining the system hardware for specific failure types. When the system management software or firmware detects such faults, the response varies. In some cases, the software may only generate an alert. (For example, if the voltage drops or spikes, an e-mail message is sent to an administrator.) In other cases (for example, a faulty fan is detected), the software alerts the network administrator and transfers the cooling load to the other fans in the server.  Mid-level system management tools In addition to providing the same functionality as entry-level tools, mid-level system management tools may also be able to analyze system information and alert the administrators about potential system failures before they occur. This capability is often called prefailure monitoring or predictive failure analysis. If a component, such as a power supply, hard disk, fan, or memory, begins to fail, an administrator is notified before the component failure or system shutdown actually occurs. Coupled with warranties and service contracts that offer prefailure replacement parts, predictive failure analysis can help warn administrators about key components (for example, hard disks, memory, and CPUs) that could potentially fail and need replacing.  High level system management tools In addition to providing the same functionality as mid-level tools, high-level system management tools also include hardware-based system management cards and add-on processors. In general, vendors who sell enterprise-level server hardware also offer system management solutions that include different combinations of high-end hardware and system management features. System management cards and add-on processors extend the basic capabilities of the system's standard management tools. When selecting high-level system management tools, look for features such as in-band and out-of-band management, and modems that support direct dial-out to alphanumeric pagers. With the use of such high- level system management tools, it is theoretically possible to contact technical support without human intervention. Additionally, some system management tools offer the following functionality:  You can dial in to a server that is down and run diagnostics or reboot the server.  You can redirect the server console to another system through an in-band connection, out-of band connection, or both.  You can access server controls and diagnostic features through a Web-browser interface, which enables you to monitor and, in some cases, control systems from different computers. For detailed information about selecting fault tolerant hardware for your Exchange 2003 organization, see Component-Level Fault Tolerant Measures.

Selecting Third-Party Monitoring Products

To help you identify which third-party monitoring products best meet the needs of your organization, consider the following factors:

 Does the vendor have a good record of shipping products that work well with Exchange?  What is the vendor's support policy? Do they offer adequate support to meet uptime and service level guarantees that may be affected if there are problems with their tools?

Important:

If you implement a third-party solution for Exchange 2003, the vendor of the monitoring application is your primary support provider for software-related issues, and your hardware provider is your primary support provider for hardware-related issues.

 How much does the tool cost? Are its costs and capabilities in concordance with the downtime costs that you calculated at the beginning of the planning process?

Note:

This guide does not provide recommendations about non-Microsoft tools. For information about non-Microsoft management tools, see the Exchange Server Partners Web site.