Info Tech Articles: MS Exchange 2003 ( Howto & Info )

Microsoft Exchange Server 2003

Introduction

You should have the following skills before studying for the Implementing and Managing Microsoft Exchange Server 2003 certification:

Detailed knowledge of TCP/IP and TCP/IP protocols such as HTTP, SMTP, POP3
Knowledge of Active Directory and Active Directory management tools
Knowledge of DNS
Knowledge of network infrastructure design and configuration
Knowledge of IIS and IIS management tools

Exchange Server 2003

As you study this section, answer the following questions:

What are the advantages of a client/server messaging system?
What are the differences between shared folder and client/server messaging systems?
How does Active Directory affect the deployment of Exchange?
What advantages does clustering offer?
What are the differences between the Standard and Enterprise editions of Exchange 2003?

Installation Prerequisites

Exchange Server 2003 requires the following components and services:

Windows 2000 Server with SP3 or Windows Server 2003
Active Directory
DNS services
Internet connectivity for sending and receiving e-mail over the Internet

Active Directory performs many of the services that earlier versions of Exchange performed. Active Directory has three partitions (also referred to as naming contexts). Each partition has its own replication and permissions configuration.

Partition	Function
Schema	The schema defines the rules for how objects are created and the properties and bounds for object properties. When you install Exchange, the schema is extended to: Add Exchange-specific objects Add Exchange-specific properties to existing objects
Configuration	The configuration partition controls communication and replication for all Exchange 2003 servers. The configuration partition: Stores information on the physical structure of the Exchange organization Stores information for routing groups and connectors Stores replication configuration Replicates data to all domain controllers in the forest
Domain	The domain holds all data for individual users, contacts, and mailboxes. As Exchange runs, it stores and modifies data in the domain.

Before installing Exchange Server 2003, you should prepare the forest and Active Directory domains. Although these actions can be performed during installation, doing them first allows for enough time to complete the replication process. The following table describes the actions to take.

Phase	Description
Forest Preparation	Forestprep extends the Active Directory schema by adding classes and attributes used by Exchange. Run Setup.exe /forestprep once on the forest root domain. To run /forestprep, the account you use must have the following roles: Schema Administrator Enterprise Administrator Domain Administrator Local machine Administrator
Domain Preparation	Domainprep adds the necessary objects for Exchange administration. Run Setup.exe /domainprep once in the following domains: The forest root domain Any domain that hosts an Exchange server Any domain that contains users that will access Exchange mailboxes To run /domainprep, the account you use must have the following roles: Domain Administrator Local machine Administrator

In order for Exchange Server 2003 to use Active Directory properly, a good DNS infrastructure must be set up. Exchange Server 2003 uses DNS for the following:

An Exchange server contacts DNS to get service locator records (SRV) to locate Active Directory domain controllers.
An Exchange server contacts DNS servers to retrieve MX (mailbox) records and to locate SMTP domains.
An Exchange server uses DNS to resolve hosts names, especially when locating hosts on the Internet.

Installation Requirements

As you plan your Exchange implementation, you need to select the Exchange version that best meets your organization's needs. The following table compares the two Exchange Server 2003 versions.

Exchange Version	Feature Support
Exchange Server 2003 Standard Edition	Up to 16 GB disk storage for mailboxes Single mailbox store Single public folder store
Exchange Server 2003 Enterprise Edition	Up to 8 TB disk storage for mailboxes Up to 20 mailbox and public folder stores Clustering support Mount point support

Exchange Server 2003 requires a Windows Server operating system and Active Directory. You can install Exchange Server 2003 on the following operating systems:

Windows 2000 Server with SP3
Windows 2000 Advanced Server with SP3
Windows 2000 Datacenter Server with SP3
Windows Server 2003 Standard Edition
Windows Server 2003 Enterprise Edition
Windows Server 2003 Datacenter Edition

Note: To take full advantage of Exchange Server 2003 functionality, you must run Windows Server 2003. The following features are only available on a Windows Server 2003 version:

Mount points
Volume Shadow Copy service for database backup
Internet Protocol Security (IPSec) support for front-end and back-end clusters.
Cross-forest Kerberos authentication with Microsoft Outlook 2003
Internet Information Server (IIS) 6 enhanced security and dedicated application mode.
Hypertext Transfer (HTTP) access from Outlook 2003 Real-time collaboration (requires Real-Time Collaboration service).
Microsoft SharePoint Portal Server Web Parts

The following table lists the hardware requirements for installing Exchange.

Component	Minimum Hardware Requirements	Recommended Hardware
Processor	Pentium 133	Pentium III 500 (Standard Edition) Pentium III 750 (Enterprise Edition) Multiprocessor support: Windows 2000 Server/Windows Server 2003 supports up to 4 processors Windows 2000 Advanced Server/Windows Server 2003 Advanced Edition supports up to 8 processors
Memory	256 MB	512 MB Windows 2000 Server/Windows Server 2003 supports up to 4 GB RAM Windows 2000 Advanced Server/Windows Server 2003 Advanced Edition supports up to 8 GB RAM Note: Exchange uses only 3 GB of RAM. Additional RAM can be used by the operating system and other running programs, but will not be used by Exchange. Adding RAM above about 4 GB has little effect on Exchange performance.
Disk Space	500 MB on partition where Exchange Server 2003 is installed	200 MB on system drive 500 MB on Exchange Server 2003 drive Separate physical disks for the Exchange binaries, database files, and transaction logs Exchange Server 2003 Standard Edition supports up to 16 GB for mailbox storage Exchange Server 2003 Enterprise Edition supports up to 8 TB for mailbox storage
File System	All disks used by Exchange must be formatted with NTFS
Display	VGA or better	SVGA or Better
Other	NIC CD-ROM drive	NIC CD-ROM, DVD-ROM RAID configuration

Exchange also requires the following components and services be installed and running prior to performing the Exchange installation. Note that in many cases the default installation of Windows will not include all necessary components.

Component	Windows 2000 Server	Windows Server 2003
Microsoft .NET Framework	Added during Exchange installation	Included in the default installation
Microsoft ASP.NET	Added during Exchange installation	Included in the default installation
Internet Information Services (IIS)	Included in the default installation	Installation required
World Wide Web Publishing Service	Installation required	Installation required
Simple Mail Transfer Protocol (SMTP) Service	Installation required	Installation required
Network News Transfer Protocol (NNTP) Service	Installation required	Installation required

Installation Facts

To install Exchange Server 2003, you must be a member of the following groups:

Full Exchange Administrator
Local Administrators

You can begin the Exchange Server 2003 Setup automatically or manually. To start the installation manually, run <drive>:\setup\i386\setup.exe. The following table lists common switches to use with the installation program.

Switch	Purpose
/ChooseDC dcname	Identifies a domain controller used during Setup Note: When installing Exchange on multiple servers at the same time, use this switch to have all servers use the same domain controller. Specifying the domain controller name avoids Active Directory synchronization problems that might result when different domain controllers are accessed during installation. When using this option, the Exchange server must be in the same domain as the specified domain controller.
/DisasterRecovery	Recovers an Exchange installation after the server's configuration has been restored from backup
/ForestPrep	Prepares Active Directory for Exchange Server 2003
/DomainPrep	Prepares each Active Directory domain for an Exchange Server 2003 installation or mailbox-enabled objects
/?	Display a list of all command-line switches with a brief function description
/CreateUnattend filename.ini	Creates an .ini for an unattended setup Note: You cannot use an unattended installation for the first Exchange server in an organization, for installing Exchange into an Exchange 5.5 organization, or for installing an Exchange cluster.
/EncryptedMode	Encrypts the .ini file
/UnattendFile filename.ini	Launches the unattended setup using the .ini file specified
/Password password	Allows the currently logged on user to bypass entering a password during Setup
/ShowUI	Displays the wizard user interface during unattended Setup
/NoEventLog	Decreases clutter in the event log by disabling messages from being written to it
/NoErrorLogging	Disables error logging during Setup
/All	Enables all Exchange components for an install, upgrade, or reinstall

The Exchange Deployment Tools are a collection of tools and a predefined process for installing Exchange. Although you can run Setup.exe directly, in most cases you will use the process outlined in the Deployment Tools. Using the Deployment Tools you can:

Deploy the first Exchange 2003 server
Install Exchange 2003 on an additional server
Perform post-installation setup
Install Exchange System Management Tools only

Keep in mind the following details regarding Exchange Server 2003 installation:

The installation is the same whether you are installing the Exchange Server 2003 Standard or Enterprise Edition.
The default directory for the Exchange Server 2003 installation is C:\Program Files\Exchsrvr.
Exchange Deployment Tools guides you through the installation.
The Messaging and Collaboration Services option installs all the necessary components of an Exchange server.
If you haven't run /forestprep or /domainprep they will run when you run the standard setup (if your account has the necessary rights).
View the event log to see installation events and troubleshoot the installation.
To upgrade from Exchange 2000 to Exchange 2003, run the setup program. Following the upgrade, you must remove the Mobile Information Server Exchange 2000 Event Source.
When you install Exchange, the SMTP and HTTP virtual servers are the only servers that are started. If you require other services (such as POP3, IMAP4, or NNTP), you must start these virtual servers manually.

After installing Exchange 2003, you can verify the installation in the following ways:

Use the Services snap-in to view the list of installed services. Make sure that the Exchange-specific services have been installed and started on the server.
In Active Directory Users and Computers, check a user account to make sure the Exchange Tasks wizard has been added.
Run the Exchange System Manager and verify the Exchange organization and server are correctly listed.
Check the C:\Exchange Server Setup Progress.log file for successful installation messages.
Check the Application log in Event Viewer for the following message: ID: 1001 "Setup [build nnnn] completed successfully."

Core Component Facts

The following table identifies the core component of Exchange.

Component	Service and Function
Information Store (IS)	Store.exe is a service running on the Exchange server that manages the database process of Exchange. This service is required for databases to be loaded and for clients to connect to Exchange server. Note: Store.exe requires more memory than most other processes that are running on the Exchange server
Internet Information Services (IIS)	Exchange relies on IIS and several of its services including: The IIS Admin Service to provide security and reliability by isolating an application's authentication, processes, and extensions. The SMTP Service handles message transfer, inside and outside of the Exchange server. The Routing Engine enables message transfer from server to server and executes and tracks multiple process instances in an Exchange folder.
System Attendant (SA)	Mad.exe is a service running on the Exchange server that is responsible for: Tracking messages and recipients Running the Recipient Update Service (RUS) which updates Active Directory object properties.
Active Directory (AD)	Exchange requires Active Directory for locating users and routing processes. NTDS.dit is the name of the Active Directory database. Note: It is recommend that you don't install Active Directory on Exchange Server unless you have only one server in the organization.

Exchange Organization and Objects

The following table lists some of the major objects that are used to organize and administer Exchange. You will learn more details about each throughout this course.

Object	Description
Organization	The organization is the top Exchange infrastructure object.
Administrative Group	An administrative group is a logical administrative structure that is used to manage permissions and delegate permissions to Exchange servers. Administrative groups organize servers for management purposes. Administrative groups match your network administrative structure. Groups are often based on locations or major departments. Use permissions to allow administrators to manage the Exchange servers within the group.
Server	The server object in Exchange System Manager represents a physical Exchange server. Objects below the server identify resources and processes running on the server.
Queue	The queue folder beneath a server holds the messages or jobs that are awaiting transmission or processing.
Virtual Server	A virtual server identifies a protocol running on the Exchange server. You can have multiple different protocols running at the same time or multiple instances of the same protocol running on a single server. Each instance of a protocol is represented by a different virtual server. Virtual servers used in Exchange are: SMTP, used for communication between mail servers and by clients for sending mail X.400, used to communicate with X.400 mail servers POP3 and IMAP used to communicate with e-mail clients NNTP used for communicating with news clients and servers HTTP used to provide mail access through a Web browser The virtual servers you will need on your Exchange server depends on the servers and clients that will need to communicate with your server.
Recipient	A recipient is an Active Directory object that has Exchange mail capabilities. Potential recipient objects include users, groups, contacts, and InetOrgPerson objects.
Mailbox	A mailbox is a logical storage location associated with a recipient. The mailbox is where all e-mail messages are stored. The In Box and all other associated folders make up the mailbox.
Store	A store is a database of Exchange information. The store contains individual recipient mailboxes. All mailboxes in the store share common configuration settings.
Storage Group	A storage group is a collection of stores. All stores in the storage group are held on the same physical server.
Address Lists	An address list is a list of recipients. The global address list is an address list that is automatically generated by Exchange and which includes all recipients in the Exchange organization. In addition, you can define custom address lists.
Public Folder	A public folder is a repository for data that can be accessed by multiple users. A public folder is a recipient that can have an associated e-mail address. Users can e-mail or post content into the public folder. Content in the public folder is accessible through the Outlook clients.
Routing Group	A routing group is a group of Exchange servers that are connected by constant, high-speed links. The routing group identifies Exchange servers that can contact each other without any additional routing considerations. The routing group topology typically mirrors sites in your organization that are connected by WAN links. Routing groups identify the physical routes that messages take. By default all Exchange servers are in the First Routing Group.
Routing Group Connector	Connectors identify paths between routing groups, to the Internet, or to external mail systems. Connectors identify the protocols used to communicate between routing groups. You can also control how communication occurs by controlling delivery time, message size, and users among other criteria.
Recipient Update Service	The Recipient Update Service is responsible for updating Active Directory with Exchange-specific information. For example, the Recipient Update Service updates e-mail addresses associated with user accounts.

Exchange Management Tools Facts

You have several tools available to you to monitor and manage Exchange servers. The table below describes some common Exchange management tools.

Tool	Description
Exchange System Manager	The System Manager tool is installed by default and is the primary tool you use to monitor and manage your Exchange Server 2003 configuration. Use System Manager to: Change server settings Change database settings Move databases Create additional databases Enable message tracking System Manager runs on Windows 2003 or Windows 2000 SP3 as long as Active Directory Users and Computers is running on the machine. You can also use System Manager on a Windows XP machine with SP1 as long as SMTP service is running on the machine during the installation of the tools.
Active Directory Users and Computers	Active Directory Users and Computers is the primary tool you use to manage users in an Exchange Server 2003 environment. Use Active Directory Users and Computers to: Create recipients Modify recipients Hide recipients Manipulate additional recipient options Active Directory Users and Computers runs on Windows 2003, Windows 2000 SP3, or Windows XP.
Adsiedit	Adsiedit is the tool you use to modify advanced properties in Active directory. Use Adsiedit to: Grant advanced security permissions Add, modify, delete, and organize user accounts, computer accounts, security and distribution groups Adsiedit runs on any Windows 2003, Windows 2000 SP3 or Windows XP machine that is part of the domain. Install Adsiedit using the Support Tools available on the Windows 2000 or Windows 2003 CD.
LDAP Viewer	The LDAP viewer allows you to view advanced properties of recipients such as: The SMTP addresses of users The date and time of a user's last log on SID of an object Object history How an object was migrated

Keep in mind the following facts regarding management tools:

Because Exchange System Manager and the Active Directory Users and Computers are snap-ins, you can create custom MMCs for both of them. You do this by typing MMC.exe at the command line to run the Microsoft Management Console.
Exchange System Manager can only be used to administer Exchange Server 2003.
Use Active Directory Users and Computers to move mailboxes within an organization. Use the migration wizard and other migration tools to move mailboxes between organizations.

Exchange Modes

An Exchange Server 2003 organization runs in one of two modes of operation: mixed mode or native mode. The following table defines each mode and identifies characteristics of each.

Mode Type

Description

Mixed

Mixed mode is the default Exchange mode that is designed for backwards compatibility with other Exchange servers. When operating in mixed mode:

Overall Exchange functionality is limited to features shared by all servers in the organization.
Exchange 2003 servers appear as just another server to earlier versions of Exchange.

Used mixed mode if your organization includes servers running previous versions of Exchange.

Native

An organization in native mode contains only computers that are running Exchange 2000 Server or Exchange Server 2003 or later. To switch to native mode, the following conditions must exist:

All Exchange servers must be upgraded to Exchange Server 2003.
Domain controllers that communicate with Exchange servers must be running Windows 2000 Server SP3 or later.

Note: After you change to native mode, you cannot change back to mixed mode. This means that no earlier releases can be added to the Exchange organization. It is important to understand the implications of the conversion before you convert. Use native mode to take advantage of the following features:

Moving servers between routing groups in different administrative groups.
Creating query-based distribution groups.
Moving mailboxes between administrative groups.
Mail-enabling or mailbox enabling the InetOrgPerson object.

To determine the mode of the Exchange organization, view the properties of the Organization object in Exchange System Manager. Edit the setting on the General tab to change the Exchange mode.

Administrative Groups and Permission Facts

An administrative group is a logical administrative structure that is used to manage permissions and delegate permissions to Exchange servers. Note the following facts about installing Administrative Groups:

During installation you specify the name of the administrative group into which you install the Exchange server.
It is important to select the correct administrative group for each server because you cannot change it after installation.
During the installation, if there is only one administrative group, all Exchange servers will automatically be installed in that group. You are not prompted to select the administrative group if Exchange only has a single administrative group.
You can set up administrative groups prior to the installation of the first Exchange server. This gives you the advantage of being able to select multiple administrative groups during the install of the first Exchange Server. To set up administrative groups prior to installation:

Run /forestprep
Use Adsiedit to create administrative groups in Active Directory.

After installation, you can use Exchange System Manager to create new administrative groups.
If Exchange is running in native mode, you can rename administrative groups in Exchange System Manager. Otherwise, use Adsiedit to rename administrative groups.

Using permissions you can delegate Exchange server administrative tasks to other users. Keep in mind the following facts for managing Exchange permissions:

Permissions are assigned either at the organizational level or the administrative group level.
Use the Exchange Delegation Wizard in Exchange System Manager to manage delegations.
While running /forestprep or during the Exchange Server 2003 installation, you identify the default Exchange System Administrator. This administrator has all permissions to the Exchange organization.
Exchange administrators must have specific permissions in Active Directory for the objects and levels they will be working. They must also have permissions on the local computer.

The following table identifies the permissions of each Exchange administrator role.

Administrator Role	Administrative Rights
Full Administrator	Full control over all objects within the hierarchy Change all permissions Delegate permissions Read mailboxes
Administrator	Full control over all objects, except cannot change permissions
View Only Administrator	View configuration

Note: When you assign the Full Administrator or Administrator roles to an administrative group, the user also receives View Only permissions to the organization, allowing the administrator to view the configuration of the entire organization.

System Policies

A system policy is a collection of configuration settings that are applied to multiple objects. For example, you can create a single policy with settings that are applied to multiple Exchange servers. Exchange includes three different types of system policies:

Public Store Policy
Mailbox Store Policy
Server Policy

System policies are created inside an administrative group. To configure a system policy, take the following steps:

If you have not yet defined a system policy in an administrative group, add a System Policy container (right-click the administrative group and select New | System Policy Container).
Add a policy to the System Policy container (right-click the System Policies container and select New, followed by the type of policy you want to create). Select the property pages that the policy will define.
Edit the policy settings. Give the policy a name and modify the property settings that will be controlled by the policy.
Add objects that will be controlled by the policy (right-click the policy and add the servers, public stores, or mailbox stores to which the policy will be applied).

Be aware of the following facts about system policies:

Although policies are defined inside an administrative group, policies can apply to objects outside of the administrative group.
You can move or copy policies between administrative groups. However, you cannot move or copy the System Policies container between administrative groups.
After copying the policy, you must apply it to the corresponding objects that will be controlled by the policy.
When a policy is applied to an object, the properties controlled by the policy are disabled in the corresponding objects. For example, if a policy enables message tracking on a server, you will be unable to edit the server and modify the message tracking settings.
When you remove an object from a policy or delete a policy, the settings remain on the corresponding object. You must edit the properties of the object in order to modify the settings after it has been removed from the control of the policy.

Recipient Concepts

As you study this section, answer the following questions:

What is an Exchange recipient?
What administrative tasks can you perform using the Exchange Tasks wizard?
How do you determine when to mailbox-enable or mail-enable a user?
What types of recipient objects can be mailbox-enabled?
How does a query-based distribution group alleviate administrative overhead?

After finishing this section, you should be able to complete the following tasks:

Use the Exchange Tasks wizard to perform recipient configuration tasks.

This section covers the following exam objectives:

502. Manage user objects
503. Manage distribution and security groups
504. Manage contacts

Recipient Facts

A recipient is an Active Directory object that has Exchange mail capabilities. The mail capabilities of an object are classified as follows:

Classification	Description
Mailbox-enabled	Mailbox-enabled recipients can both send and receive e-mail through Exchange. The recipient appears in the global address list. The Active Directory object (recipient) has an associated Exchange mailbox. Mail is sent and received through an Exchange-managed account. Create mailbox-enabled recipients to identify users who use the Exchange system for e-mail services.
Mail-enabled	Mail-enabled recipients can only receive e-mail. The recipient appears in the global address list. The recipient does not have an Exchange mailbox. Mail is sent to an external e-mail account. Create mail-enabled recipients to identify users who have external e-mail addresses and for which e-mail services are provided by another mail system.

When you install Exchange, the Active Directory schema is extended to add mail properties to existing objects. The following table lists the objects with e-mail capabilities.

Object	Description
User	A normal Active Directory user account can be designated as an Exchange recipient. Users accounts: Can be used to log on. Once logged on, the user account could have access to network resources. Can have resource access controls configured in Active Directory. Can be mailbox-enabled or mail-enabled. Use Active Directory user accounts as recipients to add e-mail capabilities to existing network users, or to add new users who need both e-mail services and access to network resources.
InetOrgPerson	The InetOrgPerson object is a user account object used in non-Microsoft LDAP and X.500 directory services. In Active Directory, the InetOrgPerson object is different than a user account but with the same capabilities. An InetOrgPerson object can be used to log on and access resources. Access controls can be configured in Active Directory. The InetOrgPerson object can be mailbox-enabled or mail-enabled. To mail-enable or mailbox-enable an InetOrgPerson object, you must have a Microsoft Windows Server 2003 domain controller and an Exchange 2003-only environment. Use InetOrgPerson to create user accounts in Active Directory that are compatible with non-Microsoft directories or to prepare for migration from other LDAP directory systems.
Contact	A contact is and Active Directory object that represents a recipient in an external (non-Exchange) messaging system. Contacts cannot be used for logon or to access or control access to network resources. Contacts can only be mail-enabled. Use contacts to identify e-mail addresses for users outside of your network who do not need to access network resources.
Public Folder	A public folder is a folder where users with the appropriate permissions can post and read messages. Public folders can only be mail-enabled. Messages sent to the public folder are posted in the folder.
Group	Use groups to identify a list of recipients. Groups can only be mail-enabled. Mail sent to the group is forwarded to each group member. The following objects can be members of a group: user, InetOrgPerson, contact, public folder, other groups. Active Directory has the following group types: Security groups are security principals and can be used to assign permissions and control resource access. Identify a security group as a recipient if you want to use the group to control resource access in addition to building the e-mail list, or to quickly add e-mail capabilities to existing groups. Distribution groups are like Exchange 5.5 distribution lists. The Distribution group holds a list of recipients. Use a distribution group to identify e-mail groups but not to control security.
Query-based Distribution Group	A query-based distribution group is similar to a regular group. However, group membership is dynamically generated rather than statically configured. LDAP filters define a search criteria based on Active Directory attributes. All objects with the defined attributes are automatically made a member of the group each time the group is accessed. Like regular groups, query-based distribution groups can only be mail-enabled. Mail sent to the group is forwarded to each user who meets the filter criteria. Use a query-based distribution group to simplify e-mail group management. Be aware, however, that these groups require increased processing capabilities.

Mailbox-enabled Recipients

After finishing this section, you should be able to complete the following tasks:

Create mailbox-enabled users and mailbox-enable existing users.
Move and delete mailboxes.
Manage mailbox properties such as size limits and sending mail.

This section covers the following exam objectives:

502. Manage user objects.

Mailbox-enabled Facts

When you mailbox-enable an object, Exchange-specific properties are added to the object in Active Directory. Use Active Directory Users and Computers to manage individual mailbox settings. Keep in mind the following when managing mailboxes:

A mailbox is not set up until a mail message is sent to the mailbox or a user logs into the mailbox.
When you mailbox-enable the object, an Alias is defined. The default value for the alias matches the logon name. The alias is also used by default for the recipient's e-mail address.
E-mail addresses used by Exchange are automatically generated using recipient policies. The recipient policy identifies the format used to generate the e-mail addresses. The Automatically update e-mail addresses based on recipient policy setting identifies whether the e-mail addresses are generated automatically by the recipient policy.

In most cases, you will not need to create e-mail addresses manually. Instead you will use recipient policies to generate e-mail addresses based on the rules you define.
Having multiple e-mail addresses allows you to receive e-mail at different e-mail addresses. This feature is very useful for company acquisitions, name changes and those situations in which you want to continue to receive mail at an address while it is being phased out.
The primary address is the e-mail address automatically used for the recipient when sending mail.
All addresses used by a recipient must be within the domain that the Exchange Server is responsible for.

Message size and/or storage limits can be configured at the following levels in Exchange:

Global settings apply to all recipients in the organization.
Connector settings apply to all messages sent using a logical connector.
SMTP virtual server settings apply to all messages that use a specific virtual server.
Store settings apply to all mailboxes within the store.
Mailbox settings are configured for each recipient and apply to that recipient.

The most restrictive of these settings is enforced. This means that for the mailbox, you can only configure more restrictive settings than exist at other levels. For example, you cannot configure a higher mailbox storage size for a user through the user account settings.

Message size limits restrict the size of messages that can be sent or received. Storage limits restrict the amount of disk space that the mailbox uses.
When configuring storage limits, setting the Prohibit send at and Prohibit send and receive at values could result in a user being unable to send or receive e-mail. If users are unable to send or receive e-mail, check to see if storage limits have been exceeded.
You can use two methods to enable other recipients to send mail for a recipient:

Use the Send on behalf of property to identify recipients who can send mail for the recipient. When messages are sent, the From field in the message appears as: From UserB on behalf of UserA.
Use the Security tab to grant Send As permissions to allow other users to send mail as if they were the recipient. When messages are sent, the From field in the message appears as: From UserA. (Note: Users will not be able to tell that the message was not sent from the purported recipient.)

The Deleted item retention setting identifies how long mail messages are kept after they have been removed from the Deleted Items folder. By default, Exchange keeps e-mail items for 7 days. During this time, messages can be recovered through the Outlook client. Items can be permanently deleted and therefore they are non-recoverable. This happens in the following ways:

In Outlook a user presses Shift+Delete to remove an item.
The client application the recipient uses to access Exchange does not move items to a Deleted Items folder. The IMAP4 and POP3 clients do not move items to a Deleted Items folder.
An Outlook user working offline with an offline folder file (.ost) moves the item to the Deleted Items folder and then deletes the Deleted Items folder before the offline folder file is synchronized with the server.

Note: Deleted item retention is an exception to the rule about global limits overriding less restrictive limits set at the mailbox level. You can specify that the e-mail from the Deleted Items folder be held longer than the global setting.

The Hide from Exchange address lists option allows you to prevent a recipient from appearing in address lists.

If you hide an e-mail name from the Exchange address list, the name is not available from any point.
This feature is useful in situations when the e-mail address is used only for client communication, a recipient leaves the company, or a similar circumstance in which you do not want internal users sending e-mail to that address.

Recipient Policies

As you study this section, answer the following questions:

What does a recipient policy do?
When you have multiple recipient policies, when is the default recipient policy applied?
How do you determine which address is a user's return address when the user has multiple addresses?
Which variables (and variable combinations) allow you to display a user's whole name in an e-mail address?
What is the relationship between the Recipient Update Service (RUS) and Active Directory?

After finishing this section, you should be able to complete the following tasks:

Modify the default recipient policy.
Create, modify, and delete recipient policies.
Configure filter rules to customize how recipient policies are applied.

This section covers the following exam objectives:

501. Manage recipient policies.

Recipient Policy Facts

A recipient policy is a collection of configuration settings that apply to Exchange recipients. Specifically, recipient policies specify the way in which e-mail addresses are generated for recipients.

Keep in mind the following facts when modifying recipient policies:

The default policy assigns the SMTP address format for recipients as alias@ADdomain where alias is the Exchange alias (by default the user account logon name) and ADdomain is the DNS domain of Active Directory.
You cannot delete the default recipient policy. You can, however, edit the default policy to modify how the default e-mail address is formatted or to add one or more addresses to enable users to receive mail at multiple addresses.
For a recipient with more than one address, only one is considered to be the primary address. The primary address is the address used as the return e-mail address when a recipient sends mail.
Each user can have a primary SMTP and a primary X.400 address.
You can create additional recipient policies for a subset of recipients. When you create the recipient policy you chose the types of recipients to apply the policy to. These recipient policies use LDAP filters to determine the subset of the specified recipients to apply the policy.
When you have multiple policies, only one is applied to each recipient. The policy used for the recipient is the policy with the highest priority that meets the specified LDAP filter criteria. If no criteria is met, the default policy is used.
If multiple policies might apply to a given user, give the more specific policy a higher priority to ensure it gets applied.

Variables allow you to use names other than the user account name in the address. The following table lists the available variables.

Variable	Description
%g	Given name (first name)
%i	Middle initial
%s	Surname (last name)
%d	Display name
%m	Exchange 2003 alias
%rxy	Replaces character x with character y If x = y, the character will be deleted
%number+variable	Uses the specified number of characters in the variable

The following table lists several examples of using variables in the address string of the recipient policy. Each example uses the following information from a sample user account:

Given name = Mary
Middle initials = R.
Last name = Smith
Display name = Mary R. Smith
Exchange 2003 alias = MarySmith

Policy Entry	Resultant E-mail Address
@westsim.com	MarySmith@westsim.com The Exchange 2003 alias will be used as the first part of the e-mail address.
%m@westsim.com	MarySmith@westsim.com
%g.%s@westsim.com	Mary.Smith@westsim.com
%1g%i%s@westsim.com	MR.Smith@westsim.com The first character of the given name is used, followed by the middle initials value, followed by the surname. Notice how the middle initials field contains two characters (R followed by a period).
%1g%1i%2s@westsim.com	MRSm@westsim.com The first character of the given name and middle initials is used followed by the first two characters of the surname field.
%d@westsim.com	MaryR.Smith@westsim.com
%r..%d@westsim.com	MaryRSmith@westsim.com All periods in the display name are removed.

Keep in mind the following when working with variables in recipient policies:

Spaces are removed automatically.
Invalid e-mail address characters will automatically be removed.

Recipient Update Service Facts

The Recipient Update Service updates recipient objects in a domain with specific types of information. The Recipient Update Service is responsible for:

Updating SMTP addresses for mailbox-enabled recipients
Populating address lists
Associating mailboxes with recipients
Verifying membership of the Exchange Enterprise Servers security group

There are two different types of Recipient Update Services:

A single instance of the Enterprise Configuration Recipient Update Service runs in each organization.
The Domain Recipient Update Service runs in the domain. Each domain with mailbox-enabled recipients must have at least one instance of the service running.

Be aware of the following facts about the Recipient Update Service:

When you create a mailbox for a user or create or modify a recipient policy, the Recipient Update Policy is responsible for communicating those changes to Active Directory.
The Recipient Update Service update is scheduled to run at regular intervals (the default is every 60 seconds). You can administratively change this interval.
Users will not be able to log on to their mailboxes and changes will not appear until after the update service runs.
The Recipient Update Service processes only those changes that were made since the last time it was run.
You can manually force the update service to run to make the changes take place immediately.

Perform an update operation (select Update Now) to make only those changes since the last time the service has run.
Perform a rebuild operation (select Rebuild) to regenerate all SMTP addresses. This process can take some time and should be run in off-peak hours.

Note: Manual updates might fail if you have insufficient permissions to force the update.

Keep in mind the following facts regarding managing the Recipient Update Service:

The Recipient Update Service runs on an Exchange server and communicates with a domain controller. The Recipient Update Service object is associated with both the Exchange server and the domain controller.
A single Exchange server can run multiple instances of the service. A single domain controller can only participate in one instance of the Recipient Update Service.
For those domains without an Exchange server running, you create a Recipient Update Service in a domain with an Exchange server and specify in the Active Directory domain where the recipients exists.
If you have multiple domain controllers in a domain, you can have multiple instances of the Recipient Update Service running.
The enterprise and domain services are installed automatically when Exchange is installed. However, under special circumstances you will need to manually add the service to a domain. Add instances of the Recipient Update Service in the following cases:

If a domain has no Exchange servers but does have Exchange recipients.
If a domain has only Exchange 5.5 servers.
If a domain has multiple sites. This allows changes to be propagated with local domain controllers instead of waiting for Active Directory replication across sites to occur. For example, if your network consists of two sites with the update service running only in the first site, mailboxes created in the second site will not appear until cross-site replication has taken place. By creating an instance of the Recipient Update Service that uses a domain controller in the second side, updates take place much sooner.

Note: When you make changes to a recipient in a domain where there are no Exchange Server 2003 servers and where the Recipient Update Service is not running, the Exchange-specific attributes specified in the recipient policy will not be propagated to the Active Directory objects.

To add an instance of the Recipient Update Service to a domain:

Run /domainprep.
Use the Exchange System Manager to add the instance.
When you create a Recipient Update Service, you select the domain (not the domain controller) that is associated with the service. After you create the Recipient Update Service, edit the properties of the Recipient Update Service to select a specific domain controller.

Managing Groups

As you study this section, answer the following questions:

What factors should you consider when choosing whether to create security, distribution, or query-based groups?
How does the group scope affect your choice of the type of group to create?
What requirements must your system meet to allow you to use query-based distribution groups?

After finishing this section, you should be able to complete the following tasks:

Mail-enable security and distribution groups.
Create mail-enabled groups and modify group properties.
Create query-based distribution groups.

This section covers the following exam objectives:

503. Manage distribution and security groups.

Group Management Facts

Groups can be mail-enabled. E-mail sent to the group is forwarded to all group members. Groups that can be mail-enabled are:

Security groups
Distribution groups
Query-based distribution groups

As you administer mail-enabled groups, keep in mind the following:

Security groups can be used to control resource access in Active Directory in addition to providing e-mail group capabilities.
Distribution groups can be assigned permissions to public folders in Exchange only if Active Directory is running in Windows 2000 native mode or higher. When you assign permissions to the distribution group, it is automatically converted to a security group if Active Directory supports it. If the conversion fails, change the functional level to Windows 2000 native mode or higher.
Universal groups of the security type (USGs), can be used only in native-mode domains.
Universal groups of the distribution type (UDGs), can be used in mixed mode and in native mode domains.
Membership of global group objects is replicated to every domain controller in a forest.
The membership of global groups can only be visible from domain controllers or global catalogs that are located in the same domain as the group.
Only universal group memberships are replicated across all domains to all global catalog servers in the forest. Microsoft strongly recommends using universal distribution groups for mail distribution in a multi-domain environment.

Be aware of the following special facts about using query-based distribution groups:

Query-based distribution groups are only available when Exchange is running in native mode.
When you create the query-based distribution group, you create an LDAP filter with filter rules. The rules define the criteria used for determining group membership.
To use query-based distribution groups, your network requires the following:

Exchange Server 2003 only or a native mode environment including both Exchange Server 2003 and Exchange Server 2000 with SP3.
Global catalog servers running Windows Server 2003 or Windows 2000 Server. When implementing on an Exchange Server 2000 with a global catalog server running Windows 2000 Server, you must modify the registry on the Exchange server for reliable performance.
It is recommended that you update all Exchange System Manager consoles to the Exchange Server 2003 versions. You can only create query-based distribution groups through the Exchange Server 2003 console.

Group membership is dynamically determined each time the group is accessed. For example, when you send mail to the query-based distribution group, the following process is used:

The mail is sent to the e-mail submission queue.
Exchange identifies that the recipient is a query-based distribution group.
Exchange sends the LDAP query contained in the group to a global catalog server.
The global catalog server returns a list of recipients that meets the filter rules.
Exchange builds a list of recipients based on the query results.
Exchange forwards the e-mail to each individual recipient.

When working in a multi-domain environment, use universal groups.
After creating the filter rules, use the Preview tab to view the results of the query. If the filter contains bad information, the query will fail on the global catalog server and mail will not be forwarded to group members.
The Exchange server must have the necessary permissions to execute the query. If the query returns an incomplete list of objects, check to make sure the Exchange server security context is sufficient to read all necessary object attributes.
Using query-based distributions increases the processor load on the server.

Address Lists

As you study this section, answer the following questions:

What methods can you use to create an easily navigable address list?
How can you determine which users to include in an offline address list?
What are the advantages of creating address lists in addition to the global address list?

After finishing this section, you should be able to complete the following tasks:

Create and modify address lists.
Hide contacts from global address lists.

This section covers the following exam objectives:

505. Manage address lists.

Address List Facts

An address list displays a list of recipients with similar characteristics. Address lists let users easily list and find recipients. You can use address lists to display recipients based on Active Directory attributes such as department or city. Exchange System Manager organizes address lists into the following categories:

Address List Type	Description
Address Lists	An address list is a custom list that filters recipients according to filter rules. Exchange includes default address lists for All Contacts, All Groups, All Users, and Public Folders. You can base address list filters on nearly any Active Directory attribute. Membership of address lists based on Active Directory attributes is dynamic. When you modify the attribute in Active Directory, any affected address lists are updated. You can nest address lists so that each level of the nest is a logical subset of the preceding level. To create an empty address list (for example to use as the top of a nested structure), do not define any filter rules. Use fields for address list search variables where the variations in value are not large. For example, organize address lists by department or location instead of employee ID number. Name your address lists to reflect their content. When planning address lists, your goal should be to make it easier for a user to find the recipient they want to find. You can make the address lists server- or mailbox store-specific. This configuration may be helpful for multiple virtual organizations.
Global Address Lists	The Global Address List represents all recipients in the organization. The Default Global Address List includes all recipients. You can define additional Global Address Lists that contain a subset of all recipients. Virtual organization hosting allows you to create additional Global Address Lists and then filter permission across multiple organizations that are hosted by the Exchange server. If you want a user to access a specific Global Address List, make sure that the user is a member of the list, and that the user has permissions to access only that list.
Offline Address Lists	An offline address list is an address list that is downloaded and stored on the client computer. In this way, the address list will be available even when the client is disconnected from the Exchange server. When you create an offline address list, the specified recipient lists are converted to a single data file and stored in a public folder. Offline address lists normally contain a list that represents the Global Address List. If your organization is large, you may want to modify the Global Access List so that offline clients don't have to download a large file. To create an offline Global Address List address, use address lists instead of the Global Address Lists. If you create an offline address list that contains any Global Address List, the users download the largest Global Address List even if the list is filtered. The MAPI client (such as Outlook) displays the Global Address List that meet the following criteria The user has permissions to access the Global Address List. The user is a member of the Global Address List. The Global Address List is the largest of all of the Global Address Lists.

Recipient Bulk Creation

As you study this section, answer the following questions:

How do Csvde.exe and Ldifde.exe differ in terms of features supported and file format?
Which command would you choose if you need to modify existing user accounts?

This section covers the following exam objectives:

502. Manage user objects.

Recipient Bulk Creation Facts

If you have a large number of objects to create or modify, you can use one of the following tools:

Tool	Description
CSVDE	Csvde.exe imports and exports Active Directory objects using a comma-separated list file. CSVDE can read existing information from Active Directory (export) or create new objects in Active Directory (import). You cannot use CSVDE to modify existing objects in Active Directory Common uses for CSVDE include: Using CSVDE to export object from one Active Directory system (or an Exchange 5.5 database) and import it into a different Active Directory database. Using a database program to create a CSV file, modifying the file, and importing the objects into Active Directory. Csvde.exe switches include: -i to import objects -e to export objects -f to identify the filename
LDIFDE	Ldifde.exe imports, exports, modifies, and deletes objects in Active Directory using LDAP Data Interchange Format (LDIF) files. LDIFDE files include a changeType parameter that identifies the action to take using the data in the file: Add Modify Delete Common uses for LDIFDE include: Using LDIFDE to export a set of Active Directory objects, modifying various attributes, and then re-importing the file to change the attributes. Exporting or importing data that exists on non-Active Directory LDAP directories. Ldifde.exe switches include: -i to import objects -e to export objects -f to identify the filename
Programmatic changes to Active Directory	Using a programming or scripting language (such as Visual Basic), you can programmatically access the Active Directory database to modify, delete, or add objects or attributes. This approach requires a thorough knowledge of programming and the APIs that give you access to Active Directory.

Storage Concepts

As you study this section, answer the following questions:

In which database would you look to find messages from an Internet client?
What types of backups should you use if circular logging is enabled?
When does the system delete log files (both when circular logging is used and when it is not used)?
What are the storage group and store limitations with Exchange Standard edition? What are the limitations with Exchange Enterprise edition?

This section covers the following exam objectives:

202. Manage, monitor, and troubleshoot data storage.

Storage Group and Store Facts

Databases within Exchange are organized as follows:

Unit	Description
Store	A store is a database of Exchange information. There are two types of Exchange stores: A Mailbox store holds message information. Sent and received e-mails are held in the mailbox store. A Public Folder store holds information that can be shared by users. Messages posted to public folders are held in the public folder store.
Storage Group	A storage group is a collection of stores. All stores in a storage group: Share the same transaction logs. Are handled by the same instance of the exchange store.

An Exchange server can hold multiple stores and multiple storage groups. The edition of Exchange Server 2003 determines the maximum number of stores, storage groups, and store size as shown in the following table.

Exchange Server 2003 Edition	Maximum Storage Groups	Maximum Stores per Storage Group
Standard Edition	One	Two stores, one for mailboxes and one for public folders. Each store has a 16 GB size limit.
Enterprise Edition	Four	Five stores per storage group for a total of 20 stores (any combination of mailbox and public folder stores are allowed).

Note: In addition to the storage groups listed here, you can also create one additional storage group, the Recovery Storage Group. This storage group is used to restore stores to a location other than the regular store.

Database File Facts

A store is made up of two database files: .edb and .stm. These two files together make up the store for either a mailbox or a public folder. The client application and the original message format determines which database is used to hold the message.

Database File	Client Application	Format
.edb	Outlook and other MAPI clients	MDBEF (native Exchange format)
.stm	Native Internet client (HTTP, NNTP, or SMTP)	MIME (streaming format)

In addition to these two files, a copy of each message is stored in a transaction log file.

The log file is a flat ASCII text file.
The active log file is called E00.log and has a 5 MB size limit.
Log files are used to protect data that has not yet been backed up.
Log files are deleted during a full, incremental, or differential backup.

What happens when the log file is full depends on the type of logging enabled on the storage group.

Logging Method	Description
Default Logging	When the E00.log file is full it is renamed and a new log file gets created. Takes more disk space because there might be multiple log files on the server.
Circular Logging	When the E00.log file is full, data in the log file is flushed and a new log file is created. Saves disk space because there is only one log file at a time.

Be aware of the following facts about the Exchange database files:

Every store has both a .edb and a .stm file.
The .edb file contains folders, tables, and indexes as well as MAPI client messages.
Messages are stored in the database that corresponds to the format of the sending client:

Messages from Outlook clients are put in the .edb database.
Messages from other clients are put in the .stm database.

The message is converted in memory to the appropriate format for the client. The message is not copied or converted to be stored in a different database file.
A copy of every message is also placed in a log file. The log file contains copies of messages that are in both the .edb and the .stm files.
Log files are maintained on a storage group level. This means that all stores in a storage group share the same transaction log.
Do not use circular logging if you use the Volume Shadow Copy Service to enable third-party (or custom) backup and recovery operations.
With circular logging enabled, you should only perform Full backups, and these backups should be very regular.

Stores and Storage Groups

After finishing this section, you should be able to complete the following tasks:

Create and manage stores and storage groups.
Move transaction logs and database files.
Configure store and mailbox store properties.

This section covers the following exam objectives:

202. Manage, monitor, and troubleshoot data storage.

Store and Storage Group Properties

Stores and storage groups are managed using Exchange System Manager. Be aware of the following facts regarding managing stores.

Storage limits apply to all mailboxes in the store. More restrictive settings for a mailbox override these settings.
The Keep deleted items setting can be less restrictive on the mailbox. For example, you can configure a specific mailbox to keep deleted items longer than the default configured on the store.
Items can be permanently deleted and therefore they are non-recoverable. This happens in the following ways:

The client specifically requests the item be permanently deleted.
The deleted item retention time is set to zero.
In Outlook a user presses Shift+Delete to remove an item.
The registry key that indicates Force Hard Deletes is enabled for the private or public information store.
The account requesting the deletion is a gateway.
The account requesting the deletion is a system.
The client application the recipient uses to access Exchange does not move items to a Deleted Items folder. The IMAP4 and POP3 clients do not move items to a Deleted Items folder.
An Outlook user working offline with an offline folder file (.ost) moves the item to the Deleted Items folder and then deletes the Deleted Items folder before the offline folder file is synchronized with the server.

The Archive all messages sent or received by mailboxes on this store setting sends a copy of all messages to another mailbox. Archival of messages can impact performance and there may also be legal issues that should be explored before enabling this option.
You should move the Exchange database (EDB) and Exchange Streaming Database files (STM) files to a disk separate from other files for fault tolerance and performance reasons.
Online defragmentation is the process of automatically detecting and deleting objects that are no longer being used frees space in the database. The Maintenance interval setting controls when defragmentation occurs (by default it is 1 am every day). Do not start a back up after starting an online defragmentation. Doing so stops the defragmentation.
You can view the last successful backup time to verify that the last full and incremental backups that you performed were completed successfully.
The Do not mount this store at start-up setting prevents the store from mounting after a server reboot.

Not mounting a store after a reboot is beneficial if you are performing data recovery on the store or you want to perform an offline maintenance procedure on the store.
If no users can access mailboxes in the store, check this setting and verify that the store is mounted.

By default a restore will not overwrite an existing database. To restore over an existing store, enable the This database can be overwritten by a restore setting. Note: This setting is reset after each restore operation. If you have to perform multiple restore operations on a store, you must re-enable this setting prior to each restore operation.
It is recommend that mailboxes of employees no longer with the company are kept at least 30 days.
Use the Do not permanently delete mailboxes and items until the store has been backed up setting to ensure that a copy of deleted mailboxes and deleted items are available on a backup.
You can apply system policies to mailbox stores to centrally control settings such as the default public store, offline address list, mailbox limits, deleted item and mailbox retention, and indexing.

Storage group settings apply to all stores within the storage group.

The Transaction log location is where all copies of old log files are stored (E0000001.log etc. files). These files need to be on a disk that is very large.
The System path location is the location of the current log file (E00.log). This file needs to be on a disk that is very fast. By default, the system path and transaction log locations are the same.
The Zero out deleted database pages setting overwrites deleted database tables with zeros during a backup. Enabling this setting increases security because data is completely erased. However, it increases the amount of time required to complete a backup.
Use the Enable circular logging setting to use circular logging. When using circular logging, you should only perform full backups. Reserve this option for storage groups that support Network News Transfer Protocol (NNTP) folders (in public folder stores), which do not require log files.

SMTP Facts

Simple Mail Transfer Protocol (SMTP) is the default protocol for Exchange Server 2003. SMTP is used in an Exchange system to:

Transfer mail between servers within an Exchange organization
Transfer mail between an Exchange server and a mail server on the Internet
Send mail from some Outlook clients to an Exchange server

You should be aware of the following facts regarding Exchange servers and SMTP:

By default, SMTP is enabled on all Exchange servers.
Windows 2000 Server and Window Server 2003 support Extended SMTP (ESMTP) by default. ESMTP supports host authentication and encryption.
An ESMTP host reverts to SMTP when the receiving host does not support ESMTP.
Exchange Server 2003 communicates with other mail servers using standard SMTP commands and numerical reply codes over TCP port 25. Exchange uses an asymmetric request-response protocol. This means that one host sends a command, waits for a reply and then sends another command.

Exchange uses one of three methods to identify the destination mail server for each message.

Method	Description
Active Directory	For messages sent within an Exchange organization, the Exchange server uses information stored in Active Directory to locate the destination mail server. The destination mail server is the Exchange server that holds the mailbox store that contains the recipient's mailbox.
DNS	For mail sent outside of your organization, the virtual server can be configured to use DNS for locating mail servers. The Exchange server uses its TCP/IP properties to identify the DNS server(s) it should use for name resolution. The Exchange server requests the MX (mailbox) records for all mail servers in the destination domain (the destination domain is the part of the e-mail address following the @ symbol). The normal DNS name resolution process is used by the DNS server to locate the DNS server of the destination domain. The destination DNS server returns all MX records for its domain. MX records include a preference value that identifies which record (and therefore which server) should be contacted first for sending mail. The DNS server also retrieves the A (host) records for the target mail servers. The A record maps the destination mail server name to its IP address. The Exchange server must have the IP address to be able to contact the destination mail server. If the first mail server does not respond, Exchange will contact the next mail server indicated by the next highest-preference MX record.
Smart Host	For mail sent outside of your organization, you can configure the Exchange server to forward all mail to a smart host (also called an SMTP relay). When using a smart host, all mail for external domains is sent to the smart host. The Exchange server will not use DNS to locate the destination mail server. Instead, the smart host is responsible for locating destination mail servers and sending the mail accordingly.

SMTP Virtual Server Facts

Keep in mind the following facts about managing SMTP virtual servers:

An SMTP virtual server is installed and enabled by default. Virtual servers for POP3, IMAP4, and NNTP are disabled by default on a new install, but enabled for an upgrade from Exchange Server 2000 (if they were enabled on the Exchange 2000 system).
To run multiple SMTP virtual servers on a single Exchange server, you need to assign a different IP address and port combination for each.
By default, the SMTP virtual server uses port 25. You can also configure an outbound port on which the server will try to communicate with other servers.
For internal mail servers, you can choose a custom port to prevent communication with servers on the Internet.
With Anonymous access disabled, Internet servers will not be able to communicate with your Exchange server.
Basic authentication sends credentials in plain text. Use TLS to encrypt authentication credentials. When using TLS, you will need to import a certificate.
An SMTP relay accepts mail from a client or server and relays it to other servers. By default, the Exchange server will only relay mail for internal users.
An open SMTP relay accepts inbound connections and relays messages from outside your organization. For security purposes, do not allow this type of relay. If necessary, add only specific hosts that are allowed to relay through the Exchange server.
You can configure message size limits on the virtual server. The message sizes enforced depend also on the global settings and the mailbox settings.
The Send copy of Non-Delivery Report to setting identifies an e-mail address where undeliverable mail is forwarded.
The Badmail directory receives messages that cannot be delivered. You should periodically review this directory and delete messages. The Badmail directory is not used with Exchange 2003 SP1--all bad mail is automatically deleted.
The Queue directory receives messages that are waiting to be delivered.
The Delay notification period identifies when a message is sent to the user indicating that there might be a problem sending the mail. The Expiration timeout is the amount of time after which an NDR is returned and the server stops trying to contact the destination mail server.
The Masquerade domain is a domain name that is used externally. Configuring the masquerade domain replaces internal SMTP addresses as they are used externally. This makes sent messages appear as if they have come from a different domain.
Use the Smart host setting to identify an SMTP server to which Internet mail will be forwarded. When you use a smart host, the Exchange server will no longer use DNS to locate other SMTP servers. Note: Typically you configure this at the connector, not on the virtual server itself.
When using the IP address to identify the smart host, enclose the address in brackets. For example: [192.168.1.1].
When you configure reverse DNS lookups, mail is not blocked. Instead, failed lookups are simply logged and the mail is allowed to be delivered.

Exchange Routing Facts

Routing in Exchange is the process of identifying how messages are sent within and outside of the Exchange organization. Routing is controlled by the following components.

Component	Description
Routing Group	A routing group is a group of Exchange servers that are connected by constant, high-speed links. The routing group topology typically mirrors sites in your organization that are connected by WAN links. Routing groups identify the physical routes that messages take. For communication within a routing group: All Exchange servers can send messages directly to each other. Messages are sent immediately. For this reason, the links between servers within the routing group should be constantly available and high-speed. SMTP is used as the protocol. For communication between routing groups or with external systems: You can control which servers are allowed to send messages between routing groups. You can block messages or schedule message delivery. You can customize the protocol used (SMTP, RPC, or X.400).
Connectors	Connectors identify paths between routing groups, to the Internet, or to external mail systems. By default there are no connectors. As soon as you create separate routing groups, the servers in the different groups cannot communicate with each other until connectors are created. Connectors are one-way paths between routing groups. To enable two-way communications, you must create a connector in both routing groups. When you create one connector, the Exchange System Manager asks you if you want to automatically create the connector on the other routing group. The connector defines the protocol used between the routing groups. Configure the connector properties to enforce message restrictions or delivery times.
Link State Information	Link state information is information about routing groups and connectors that the routing process uses to make routing decisions. Each routing group has a master server that maintains the link state information. By default, the first server in a routing group is the master.
Internal Routing Components	Various software processes within Exchange are used to make routing decisions. Internal components include the following: The routing engine is responsible for determining the message delivery path. The advanced queuing engine retrieves messages, categorizes them, and identifies the message destination. The message categorizer is a component of the advanced queuing engine that sends LDAP queries to the global catalog to retrieve the following information from Active Directory: The recipient's e-mail address The mailbox store where the user's mailbox is located The Exchange server that hosts the corresponding mailbox store

By default, all servers are part of a single routing group. You can create additional routing groups, move existing servers into new routing groups, and identify the routing group location during Exchange installation. After creating a routing group, you must also create connectors between those groups for communication to take place. The following table identifies the three types of connectors you can create.

Connector Type	Description
Routing group connector	Use a routing group connector to connect two Exchange routing groups. Routing group connectors use SMTP for message delivery between routing groups or RPC to connect a routing group to an Exchange 5.5 routing group that uses a site connector. You can control which servers within the routing group are able to send messages using the connector by designating bridgehead servers. The bridgehead server is the server in charge of sending messages to other routing groups. You can designate one or multiple sending bridgehead servers. You can also identify the servers in the remote routing group to which messages will be sent by configuring remote bridgehead servers. Although you can connect routing groups using one of the other connector types, routing group connectors are the preferred method of connecting two routing groups.
SMTP connector	Use an SMTP connector to connect a routing group to an external mail system, the Internet, or a non-Exchange system. SMTP connectors identify SMTP virtual servers that are used to connect to external mail systems. You can control which servers within the routing group are able to send messages using the connector by designating bridgehead servers. Messages are sent to destination mail systems using either DNS to locate the remote mail system or by forwarding messages to a smart host.
X.400 connector	Use an X.400 connector to connect to X.400 systems or to Exchange 5.5 mail servers that are external to your organization. When using the X.400 connector, you can have only one originating server and one destination server. To configure multiple source or destination servers, you must create additional X.400 connectors X.400 connectors are only available in Exchange Server 2003 Enterprise Edition.

Routing Group and Connector Facts

When you install Exchange, you decide which routing group the server goes in. You can also customize the routing group configuration by creating new routing groups. To manage routing groups, use the following process:

Create new routing groups and rename existing ones.
Move servers to the appropriate routing group.

In mixed mode, you can only move servers to routing groups in the same administrative group.
You cannot move a server that is a bridgehead server for a connector in the current routing group. Remove the connectors from the server first, then move the server.

Create connectors. Without a connector, communication between routing groups is not possible.

You must create a connector between the groups from each group. When you create the first connector, you will be prompted if you want to create a corresponding connector on the other routing group.
Before you can create a connector, you will need to define a virtual server if it does not already exist.

The following table describes some important configuration settings for the routing group connector and the SMTP connector.

Connector Type

Setting Considerations

Routing Group Connector

For routing group connectors,

You can specify local and remote bridgehead servers.

Select These servers can send mail over this connector to identify local bridgehead servers.
Use the Remote Bridgehead tab to identify remote bridgehead servers.

The bridgehead server links to a virtual server on the Exchange server.

You can configure mail restrictions on the connector that restrict the users, message priorities, and message sizes that are allowed to use the connector.
Use the Delivery Options tab to configure a schedule when messages of certain types are allowed.

SMTP Connector

For the SMTP connector,

You can choose to use DNS for mail server resolution, or identify a smart host to which all mail will be forwarded.
Add local bridgeheads to identify the local bridgehead servers that will send mail through the connector.
Use the Address Space tab to identify the destination mail domains that will be sent over the connector.

To connect to other mail systems (such as GroupWise or Lotus Notes), select the corresponding address type.
Use * to identify all destination domains.
If you identify * as the accepted destination domains, do not check the Allow messages to be relayed to these domains checkbox. This configures the connector as an open SMTP relay.

The Connector scope setting identifies the replication scope for the connector (either within the routing group or the entire organization). Select Entire organization to allow all servers to use the connector, such as when you are configuring an Internet connection.
You can configure mail restrictions on the connector that restrict the users, message priorities, and message sizes that are allowed to use the connector.
Use the Delivery Options tab to identify a schedule for when messages are sent. Specifically, use the settings on this tab if you do not have a persistent connection to the Internet.
On the Advanced tab, you can configure the STMP commands that the connector will issue:

The EHLO command opens an ESMTP session. By default, Exchange sends an EHLO command.
The HELO command opens a standard client SMTP session. Configure the connector to send an HELO command if the other server does not support ESMTP.
The ETRN command requests that the server send any mail in its queue for the specified domain. You can customize how the SMTP connector accepts ETRN commands.
The TURN command switches the communication roles, allowing the client to become the server without establishing a new session.

Note: Many settings in the connector can also be configured in the virtual server. As a best practice, you should configure settings on the connector, not the virtual server. When conflicting settings are configured, the settings in the connector are used.

Communication Troubleshooting Facts

In a organization with different routing groups, there might be multiple routes between any two routing groups. The following table lists the criteria used to select the route.

Factor	Criteria
Schedule restrictions	Is the connector available now?
Size restrictions	Is the size of the message under the maximum specified?
Message priority restrictions	Does the message qualify given its priority?
Permission of user	Does the user have permission to use this connector?
Cost of the route	Which route has the lowest cost?

An Exchanger server selects one route over another in the following way.

The server identifies all routes that meet the first four conditions.
If multiple routes can be used to send the message, the route cost is then used to select the route.
The cost is cumulative for each connector on the route. This means that the total cost is the sum of the costs for all connectors on the route.
The route with the lowest cost will be the one selected among the available routes.
In situations where the routes have the same costs, the route is selected at random.

Message tracking is an invaluable tool in troubleshooting Exchange servers. Message tracking allows you to track messages within and between Exchange servers. Keep in mind the following facts regarding message tracking:

To use message tracking, you must enable message tracking in the properties of each server the message will be routed through.
The Message Tracking Center allows you to see the whole flow process for each message.
Tracking information is kept in log files. The log files are stored in the Drive:\Program Files\Exchsrvr\servername.log.
You can specific the number of days that log files will be kept.
When troubleshooting message flow, use the Message Tracking Center. The Message Tracking Center allows you to track messages:

Using the message id
Based on the message sender or recipient
That have flowed through a specific server

In addition to message tracking, you can use the WinRoute tool to view the contents of the link state table. The link state table contains message routing information such as routing group and connector configuration. The link state table is maintained by the master server in the routing group (by default the first Exchange server installed in the routing group).

Exchange Client Facts

An e-mail client is a software application that supports specific protocols and provides the user with an interface to a server. Exchange Server 2003 supports many different types of client connections. The following table identifies the most common clients used.

Client	Description
Outlook 2003 (MAPI) client	The Outlook 2003 client is the recommended client for Exchange Server 2003. Outlook 2003 takes advantage of newer Exchange Server 2003 features. The Outlook 2003 client: Use RPC or RPC over HTTP Communicates with the Exchange server using the MAPI interface through a DLL
Outlook Web Access (OWA)	Outlook Web Access connects to the Exchange server through the Internet. Outlook Web Access provides the same look and feel as Outlook 2003 and many of the same features. Outlook Web Access: Uses HTTP or HTTP with SSL Communicates through the HTTP virtual server to the Exchange virtual directory
Outlook Express	Outlook Express is a generic e-mail client that can be used to connect to Exchange and non-Exchange e-mail servers. Outlook Express: Uses POP3 or IMAP4 for receiving e-mail Uses SMTP for sending e-mail Communicates with the Exchange server through POP3, IMAP4, or SMTP virtual servers Note: You can also connect to an Exchange server using various other clients
Outlook Mobile Access (OMA)	Outlook Mobile Access is used with WAP-enabled browsers such as a cell phone or other portable device and is only available through Exchange 2003 servers. Outlook Mobile Access: Uses HTTP for mail access Communicates with the Exchange server using an HTTP virtual server with a special virtual directory
Non-Outlook Clients	Non-Outlook clients use POP3, IIMAP3, or SMTP for sending and receiving e-mail. To enable non-Outlook client support, you must configure the corresponding virtual servers on your Exchange server.

Note: Outlook and Outlook Web Access gives users the ability to create their own public folders.

Outlook 2003 provides users access to more features of the Exchange environment than other clients and even previous versions of Outlook. The following table identifies some of the Outlook 2003 enhancements and their benefits.

Enhancement	Benefit
Cache mode	Allows a copy of the Exchange mailbox to be stored offline on the Outlook client. Allows a background connection with the server while the client uses an offline copy of the mailbox. Allows a user to access the mailbox even when the Exchanger server is not available. Eliminates the need for a constant connection to the server. Reduces required bandwidth between the client and the server. Increases the number of users the network can support. Eliminates problems with slow connections. Note: Cache mode is different than the offline files used in previous versions. Outlook 2003 users do not have to select between working in cache mode offline or working with an online copy.
RPC over HTTP or HTTPS	Allows the client to establish an RPC connection over any Internet link Allows the RPC message encapsulated with HTTP to pass through standard ports that are typically open in firewalls Eliminates the need for Outlook and other MAPI clients to be connected remotely using a virtual private network (VPN) session. A virtual private network is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. Note: When you install Exchange Server 2003, support is automatically enabled for Outlook 2003 and Outlook Web Access clients. To enable support for other clients, start the corresponding virtual servers (POP3 or IMAP4). When you upgrade to Exchange Server 2003 from Exchange Server 2000, POP3 and IMAP4 virtual servers are already started.

Front-end Server Facts

When you create a front-end/back-end server configuration, clients connect to the front-end server. The front-end server then routes all requests to the Exchange server where the mailbox resides.

The primary benefit for using a front-end/back-end server configuration is to provide a single point of access for clients. For example, you can have a single URL for all Outlook Web Access users in your organization even though mailboxes might be located on multiple Exchange servers in the organization.
Using a front-end server also creates a single point of access to e-mail within the organization. This simplifies security administration and control, and allows you to disable various protocols that must be supported on each server.

When you use a front-end/back-end server configuration, one server is designated as the front-end server. All other servers are back-end servers.

Server	Description
Front-end server	The front-end server is the point of communication between the clients and the back-end servers. The front-end server: Communicates with clients using the following protocols: HTTP HTTPS POP3 IMAP4 SMTP RCP over HTTP to allow Outlook 2003 clients to connect to the front-end server using HTTP Communicates with back-end servers using the same protocols. However, when HTTPS is used by the client, the front-end server uses HTTP to communicate with back-end clients. In this case, use IPSec to secure front-end to back-end communications. No longer hosts mailboxes or public folders. Is typically accessible through the Internet (although you can also use a front-end server internally). Contacts Active Directory to determine the home server for each client (the server where the mailbox is stored). You must specifically configure a front-end server by editing the properties of the server object in Exchange System Manager.
Back-end server	Back-end servers host mailboxes and process client requests. By definition, all Exchange Server 2003 computers are back-end servers. When you configure a front-end server, you do not need to complete any additional tasks to configure the back-end servers.

The following Exchange versions support front-end servers:

Exchange Server 2000, Enterprise Edition
Exchange Server 2003, Standard Edition
Exchange Server 2003, Enterprise Edition

Note: Front-end servers are not supported in a Windows cluster. To provide fault tolerance and improve performance, configure multiple front-end servers using Network Load Balancing.

To configure a front-end server, complete the following steps:

Edit the properties of the server object in Exchange System Manager to designate the server as a front-end server. Restart all necessary services.
On the front-end server, move any mailboxes to other servers. Delete all public folder stores. If using SMTP, delete all mailbox stores except for one, otherwise delete all mailbox stores.
If necessary, configure additional virtual servers to support necessary clients (POP3, IMAP4). By default, HTTP and SMTP virtual servers are already configured on an Exchange Server 2003 system.
Disable any unneeded services and protocols.
Enable SSL to use HTTPS. To secure front-end and back-end server communications, use IPSec between the front-end and back-end servers.
Open required firewall ports to enable communication with the front-end server. Close unnecessary ports.

Public Folder Facts

Public folders are a shared storage location for any type of electronic documents.

Public folders can hold contacts, calendars, tasks, e-mail messages, and other documents.
Public folders, and the data they contain, are accessed through a client such as Outlook 2003, Outlook Web Access, IMAP clients, or NNTP applications.
Public folders exist in the public folder store on an Exchange server. Like a mailbox store, the public folder store is composed of two database files: .edb and .stm.
Public folders are organized in a public folder tree. The tree is the hierarchy of public folders.
The public folder organization is automatically replicated between Exchange servers in the organization. Content within a public folder (the data) is stored on a server and is not replicated automatically.
Each public store on the server is associated with a public folder tree. Only one public store per server can be associated for each tree, although a single tree may have multiple public stores associated with it as long as each store is on a different server.
Each organization has a single public folder tree. You can create additional public folder trees (called general purpose trees). One reason to use additional trees is for hosting news groups. Additional trees:

Are not replicated automatically.
Are not accessible through Outlook.
Are accessible only to NNTP and HTTP clients.
Require an HTTP virtual server for users to access from a Web browser.

To create a new public store on a server, there must be a public folder tree in the organization that is not associated with an existing store on that server. This means that to create a second public store on the server in a default environment, you will need to create a new public folder tree.
Public folders have an Active Directory entry with associated properties.
You can configure a public folder as a recipient. Public folders appear as objects in the global address list if they are mail-enabled.

In a mixed mode Exchange environment, public folders are mail-enabled by default.
In a native mode Exchange environment, public folders are not mail-enabled.

If you have the appropriate permissions, you can create public folders in the Exchange System Manager or in Outlook. Note: The tool you use determines some of the features available for managing public folders. For example, in Outlook (but not in Exchange System Manager) you can identify the type of data held in a public folder.
Properties for the public folder store are similar to properties for the mailbox store.
To create additional public folder stores for non-default public folder trees, you must create the public folder tree first.
To allow clients to access additional public folder trees, you must create an associated virtual directory beneath the HTTP virtual server.
You can configure storage limits and deleted item limits on the public store or on the public folder itself.
You can apply system policies to public stores to centrally control settings such as the maintenance interval, replication interval, store limits and deletion settings, and indexing.

Public Folder Permissions

Public folder permissions control what users can do to both the folder and its contents. Public folder permission types include:

Permission Type	Description
Client Permissions	Client permissions identify the actions that users can take on the contents of the public folder, such as posting or reading folder contents.
Directory Rights	Directory rights identify actions that can be performed on the Active Directory objects and properties associated with public folders. Note: The Directory rights option will be disabled if the public folder is not mail-enabled.
Administrative Rights	Administrative rights identify the actions that users can take on the public folder itself through an administrative tool (such as Exchange System Manager), modifying properties such as replication settings or modifying folder permissions.

Client permissions are configured either through Outlook or the Exchange System Manager. With two exceptions, client permissions are either granted or denied. Client permissions are:

Create items
Read items
Create subfolders
Folder owner (the folder owner can assign client permissions to the folder)
Folder contact
Folder visible
Edit items (options are None, Own, or All)
Delete items (options are None, Own, or All)

To assign permissions, add users or groups to the permission list, then give the user a role. Each role has an associated combination of client permissions.

Role	Permissions
Owner	All permissions (including Folder owner and Folder contact), Edit and Delete all items
Publishing Editor	Create items, Read items, Create subfolders, Folder visible, Edit and Delete all items
Editor	Same as Publishing Editor except without Create subfolders
Publishing Author	Create items, Read items, Create subfolders, Folder visible, Edit and Delete Own items
Author	Same as Publishing Author except without Create subfolders
Nonediting Author	Create items, Read items, Folder visible, Edit None and Delete Own
Reviewer	Read items, Folder visible, Edit and Delete None
Contributor	Create items, Folder visible, Edit and Delete None
None	Folder visible, Edit and Delete None

Note: If you manually choose a permission combination not represented by a role, the role is listed as Custom.

Keep in mind the following regarding managing client permissions:

By default, the Anonymous user is configured with Contributor permissions. This means that anyone can add content to a public folder.
When you create a child folder, permissions from the parent folder are copied to the child folder.
Changes made to the parent folder permissions are not automatically propagated to the child folders.
To copy parent folder permissions to child folders, use the Exchange System Manager to push the changes to child folders. When you propagate permissions to the child folder, existing permissions are deleted and replaced with the permissions from the parent folder.

One administrative task you might need to perform is to grant other users the ability to create top level folders. If you use the Delegate control wizard to grant rights to the organization or the administrative group, the rights granted using the predefined roles might be more than what you want to allow. To grant only the necessary rights to create top level public folders, take the following steps:

Open the registry.
Browse to HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin\.
Create the following DWORD value: ShowSecurityPage = 1
In Exchange System Manager, edit the properties of the organization or administrative group. Use the Security tab to grant the Create public folder and Create top level public folder rights.

Public Folder Replication Facts

Replication of the various public folder components takes place as described in the following table.

Component	Replication method
Hierarchy	The hierarchy is the public folder tree or organization. The hierarchy for the default public folder tree is replicated automatically to other Exchange servers within the organization by the Information Store.
Content	Public folder data or contents are not replicated automatically. You must configure public folder content replication manually between servers. When you configure replication, you can configure the schedule and frequency that replication occurs.
Directory entry	The directory entry is the Active Directory object and its properties. Directory entries are replicated automatically through Active Directory replication.

When users view public folders, they see a replica of the public folder hierarchy. When the contents of the public folder are accessed, the data itself comes from the public folder store on the server on which the data resides. Replicating public folder data:

Increases the fault tolerance of the public folder data.
Places copies of the data on local servers. Access data from local can reduce WAN link usage and improve access times.

Keep in mind the following facts about public folder data replication:

Replicating public folder data can decrease the WAN traffic associated with data access. However, it does cause an increase in WAN traffic due to replication traffic. Depending on the number of users, replication traffic might be less than data access traffic.
Only new information going into the original public folder is replicated.
When configuring replication, you specify the public folder store that will host a replica of the public folder.
The amount of time data in two replicas is different is called replication latency. Replication latency is dependent on the replication schedule. It is also associated with the amount of time it takes to replicate.
Determine the importance of current data being available in the replicated public folder, then adjust the replication schedule to reflect that level of importance.
When a user connects to a public folder store and the store does not contain a copy of the content the user is requesting, Exchange Server 2003 automatically redirects the user to a server that does contain the content. This is known as public folder referral.
To disable public folder referrals, edit the properties of the connector and check Do not allow public folder referrals. With this setting disabled, clients will only access local copies of public folder content.

When a client needs to access data in a public folder, Exchange uses replicas in the following order:

The public folder held on the mailbox server for the recipient.
A public folder held on another server in the local routing group.
If public folder referrals are allowed, a public folder in a remote routing group. The client chooses the routing group with the lowest cost. If two routing groups with the same cost exist, the location is chosen at random.

Exchange Firewall Ports

The following table lists various protocols and their associated ports that might be used in an Exchange implementation.

Protocol	Description	Ports
Protocol	Description	Ports
SMTP	Used to communicate with mail servers and by POP3 and IMAP4 clients to send mail. Note: SMTP with SSL is rarely used.	TCP 25 Using SSL, TCP 26
SMTP		TCP 25 Using SSL, TCP 26
POP3	Used to retrieve mail from an Exchange Server. Disabled on the Exchange server by default.	TCP 110 Using SSL, TCP 995
IMAP4	Used to retrieve mail and other directories from an Exchange Server. Disabled on the Exchange server by default.	TCP 143 Using SSL, TCP 993
HTTP	Used by Outlook Web Access for mail access.	TCP 80 Using SSL, TCP 443
LDAP	Used to access information from Active Directory.	TCP and UDP 389 for Active Directory access TCP 3268 for Global Catalog access
NNTP	Used to retrieve information from Usenet servers on and enables sharing news group public folders.	TCP 119 Using SSL, TCP 563
RPC	Used to establish an RPC connection (end point mapper) and also acts as an RPC client establishing sessions.	TCP 135 TCP 1024 and above (multiple ports are typically enabled)
DNS	When contacting Active Directory, a DNS server must be contacted for name resolution. The Exchange server uses DNS to find mail servers on the Internet	TCP and UDP 53
MTA	Used for X.400 connections or connections to Exchange 5.5 servers.	TCP 102
Kerberos	Used for communication and authentication with Windows 2003 servers.	TCP and UDP 88
IPSec	Used to secure server-to-server communications.	IP protocol 51 for AH IP protocol 50 for ESP UDP 500 for key exchange TCP and UDP 88 for Kerberos

Common Internet Configurations

By default, Exchange servers are enabled to communicate with other mail servers on the Internet.

Messages sent from users on your private network are routed through your Exchange servers to the appropriate Internet mail servers for external domains.
Messages sent from hosts on the Internet are sent to your Exchange servers where they can be retrieved by your network users.
Communication with other mail servers is controlled through properties set on the SMTP virtual servers or SMTP connectors.

The following table shows several methods for configuring and securing mail servers connected to the Internet.

Design	Description
Single Exchange Server	By default, every Exchange server is running an SMTP virtual server which is preconfigured to allow Internet access. You can quickly establish Internet mail service by adding a single Exchange server to your network. Use a single server configuration for small companies with a single Exchange server. The Exchange server is located behind the firewall on the private network. It has a single network connection. Public DNS servers must have an MX record pointing to this Exchange server. This record will be used by other mail servers to locate your mail server. When you install Exchange, it is already configured to accept incoming messages sent to your domain and to forward outgoing messages sent from authenticated users. Note: If your network had multiple Exchange servers, you can simply accept the default installation and all servers will have Internet connectivity as long as they have a physical connection to the Internet and the appropriate MX records have been configured. However, this configuration exposes multiple servers to Internet traffic.
Bridgehead Server	If your network has multiple Exchange servers, it is recommended that you use a bridgehead server to provide Internet messaging services. This method uses an SMTP connector to control which servers are allowed to send and receive mail through the Internet. The bridgehead server is located behind the firewall and has a single network connection. In the properties of the SMTP connector, designate one or more bridgehead servers. Configure * as the address space. This allows the connector to be used to send mail for all external domains. You can configure the SMTP connector to allow mail sent from within the entire organization to the Internet, or only from within the current routing group. When configured to send mail for the entire organization, the bridgehead server can be used by all servers, even servers in different routing groups. Configure MX records on public DNS servers to point to the bridgehead server.
SMTP Relay (Smart Host)	An SMTP relay host is any Windows Server 2003 running the SMTP services, a third-party server or hardware device that supports SMTP routing. Inbound and outbound messages move through the SMTP relay server. The SMTP relay is typically located inside a demilitarized zone (DMZ). A bridgehead server and SMTP connector is configured inside the private network. The SMTP connector is configured to point to the SMTP relay (set the Smart Host property of the connector). Note: Although you can configure the smart host on the SMTP virtual server, you should configure this setting on the connector to avoid problems. Configure the SMTP relay to only relay outbound messages from the bridgehead server. Configure the SMTP relay to only relay inbound messages that are sent to the private domain. Configure MX records on public DNS servers to point to the SMTP relay, not internal mail servers. Note: For fault tolerance, you might need to have multiple SMTP relay servers. In this case, add an MX record for each additional SMTP relay. Internal mail servers forward all outbound messages to the SMTP relay without performing DNS lookups for the destination mail servers. These lookups are performed by the SMTP relay. The SMTP relay does not need access to Active Directory for forwarding incoming mail. All incoming mail sent to the private domain is forwarded to the bridgehead server. This server then uses Active Directory to route the mail to the appropriate internal Exchange server. You can install anti-virus and anti-spam programs on the SMTP relay.

Be aware of the following considerations for connecting servers to the Internet:

The configurations shown above do not allow clients on the Internet to retrieve mail from your Exchange servers. They only permit incoming and outgoing server-to-server communications.
Internet mail servers are configured to use port 25 for SMTP. For the server configurations illustrated above, you only need to open port 25 in the firewall to enable server-to-server SMTP communications and port 53 to enable DNS name resolution. Internet mail servers are not configured to use secure SMTP.
Most Internet mail servers are not configured to use authentication. By default, SMTP virtual servers and connectors are configured to allow anonymous access. This enables your server to anonymously communicate with other mail servers.
To improve security on internal mail servers, you can require authentication or use TLS. However, disabling anonymous access on servers connected to the Internet will likely prevent that server from sending and receiving mail from Internet servers.
By default, SMTP virtual servers are configured to relay outbound messages sent from authenticated users and to relay incoming messages sent to the private domain. If you allow more open relaying, your server might be used as a spam relay where messages sent from the Internet are relayed through your server to other Internet hosts.

Securing Client Connections

By default, Exchange servers are configured to allow Outlook Web Access (OWA) connections. However, the default configuration does not provide secure client-to-server communications. Securing client communications is typically done using a front-end/back-end Exchange server configuration. The following links show two common ways of configuring a front-end server for Internet connectivity:

Front-end Server in the DMZ

Front-end Server Behind an ISA Server

When enabling client connections through the Internet, you need to take several steps to ensure secure connections.

Secure client connections to the front-end server.
Secure front-end server connections to other servers.
Open outer firewall ports.
Open inner firewall ports.

Securing Client-to-Server Communications

By default, e-mail client communications with Exchange servers is not secured. You can use the following methods to secure client communications:

Client(s)

Considerations

Outlook Web Access, POP3, and IMAP4

Outlook Web Access, POP3, and IMAP4 clients use Internet protocols to communicate with the front-end server. Use SSL to secure these connections.

Outlook 2003

The Outlook 2003 client uses RPC to communicate with the front-end server. Because RPC is not a secure protocol, use one of the following methods to provide security:

Configure a VPN connection to the Exchange server. RPC traffic is encapsulated in the VPN tunnel.
Configure an RPC over HTTP proxy server. RPC traffic is encapsulated in HTTP or HTTPS. Using RPC over HTTP requires fewer open firewall ports.

When using RPC over HTTP, be aware of the following requirements:

Clients using Outlook 2003 must be running Windows XP SP1 with a hot fix or SP2.
The RPC over HTTP proxy server must be running Windows Server 2003. It is recommended that this server be a front-end server. The front-end server must be running Exchange Server 2003.
All Exchange servers accessed by the RPC proxy server must be running Windows Server 2003 with Exchange Server 2003.
All global catalog servers accessed by the clients or the Exchange servers must be running Windows Server 2003.

When configuring SSL, be aware of the following considerations:

Consideration	Description
Adding SSL to the Server	You must add SSL to the appropriate protocols on the Exchange server based on the client protocols used. For POP3 and IMAP4, edit the properties of the virtual server and import a certificate. For HTTP (used by OWA and RPC over HTTP): In IIS, add a certificate to the Web site or virtual directory. In IIS on the Exchange virtual directory, select the Require secure channel (SSL) option. In Exchange System Manager, edit the HTTP virtual server and enable forms based authentication. In most cases you should not enable SSL for SMTP. Most Internet mail servers do not use secure SMTP.
SSL Accelerators	An SSL accelerator decreases the performance overhead created by SSL connections. There are two types of SSL accelerators: An SSL accelerator network card which you install in each front-end server. An external accelerator device that you put between the front-end server and the client. An SSL accelerator card offloads the encryption and decryption work and increases throughput by decreasing the workload of the server software. SSL accelerator cards work well in environments with a small number of front-end servers. In environments with a large number of front-end servers, the cost of a card for each server and the administrative overhead makes this solution prohibitive. In such a situation, an external accelerator is more appropriate. An external accelerator decrypts traffic coming from the client and sends it to the front-end server unencrypted. In the same manner, traffic from the front-end server is sent unencrypted, the accelerator device encrypts it, and forwards it to the client. When using an external accelerator, you must configure a special header, the Front-End-HTTPs: on header for OWA.
SSL Offloading	To gain the full benefits offloading SSL traffic to an external SSL accelerator device, the offloading device must support custom headers because it has to pass the Front-End-HTTPs: on header to the front-end server, which passes it to the back-end server. You can configure SSL between the accelerator device and the front-end server, but this defeats the purpose of offloading SSL.

Securing Server-to-Server Communications

The front-end server uses specific protocols to communicate with clients. The front-end server uses these same protocols to communicate with the back-end servers. However, the front-end server cannot use SSL to communicate with back-end servers. For example, a POP3 client uses POP3 with SSL to communicate with the front-end server. The front-end server would then use POP3 without SSL to communicate with the back-end servers.

Use IPSec to secure front-end/back-end communications, as well as communication between the front-end server and other servers. Be aware of the following facts when using IPSec:

IPSec is typically used when the front-end server is in a DMZ or on a different subnet than other servers. It is not needed when the front-end server is behind the intranet firewall.
The Authentication Header (AH) protocol provides authentication. The packet is not encrypted, but a checksum is added to verify data integrity.
The Encapsulating Security Payload (ESP) provides data encryption.
Use IPSec policies to control the communications allowed between servers. Use the Client (respond only) policy on back-end servers. This allows the backend server to use IPSec with the front-end server, while communicating normally with clients connected through the private network.

Opening Outer Firewall Ports

To enable communication with the front-end server, you need to open specific ports in the outer (Internet) firewall. The ports you need to open depend on the type of client connection that is used.

Client	Ports Required
Outlook Web Access	HTTPS (TCP 443) HTTP (TCP 80)
POP3	POP3 with SSL (TCP 995) POP3 w/o SSL (TCP 110) SMTP (TCP 25)
IMAP4	IMAP 4 with SSL (TCP 993) SMTP (TCP 25)
Outlook 2003 with RPC over HTTP	HTTPS (TCP 443)
Outlook 2003 with a VPN	You can use either PPTP or L2TP as the VPN tunneling protocol. PPTP (TCP 1723, 47) L2TP (UDP 500, 5500, 1701)

Opening Inner Firewall Ports

Depending on location of the front-end server, you will need to open ports on the inner (intranet) firewall to enable clients or the front-end server to communicate with servers on the private network. The following table describes the ports required:

Configuration	Description
Front-end Server in the DMZ	If the front-end server is inside the firewall, the front-end server must be able to communicate with back-end servers, DNS servers, and Active Directory through the inner firewall. Open the following ports: All ports used by the client applications (such as HTTP, POP3, IMAP4) except for SSL. Remember that the front-end server cannot use SSL to communicate with the back-end servers. TCP port 691 for the Exchange link state algorithm. TCP and UDP port 53 to enable the Exchange server to communicate with DNS servers on the private network to locate domain controllers and Exchange servers. TCP and UDP port 389 for LDAP communication with Active Directory. TCP port 3268 for LDAP communication with the Global Catalog Server. TCP and UDP port 88 for Kerberos authentication. If IPSec is used: IP protocol 51 for AH IP protocol 50 for ESP UDP port 500 for Internet Key Exchange (IKE) TCP and UDP port 88 for Kerberos If RPC over HTTP is used, the clients must be able to perform authentication through the front-end server. You have the following choices to enable authentication: Open TCP ports 135 and multiple ports starting at 1024 for authentication using RPC. Open TCP port 135 and 1600 for authentication using RPC. This solution opens the minimum number of RPC ports in the inner firewall. Configure pass-through authentication. With pass-through authentication, you do not need to open RPC ports. However, the front-end server does not perform client authentication. Instead, authentication is passed through to the back-end server.
Front-end Server in the Private Network	If the front-end server is behind the inner firewall using an ISA server, you need to configure ISA to allow mail traffic to pass to the front-end server. Take the following steps to configure the ISA server: Configure an SSL listener on the ISA server. Add a destination set to the Internet interface. Create a Web publishing rule. This rule redirects traffic to the front-end server. Open any necessary outbound ports. Enable Outlook Web Access on the ISA server.

S/MIME Facts

Secure Multi-purpose Internet Mail Extension (S/MIME) protects the integrity and confidentiality of e-mail messages. S/MIME protects the message itself, while other forms of protection, such as SSL, protect the transmission channel. S/MIME requires the use of certificates issued through a public key infrastructure (PKI).

Certificates are available through the Windows 2003 Certificate Authority or through a certificate authority on the Internet. The key management service offered by Exchange 2000 does not exist in Exchange 2003.
The certificate authority is responsible for validating identity and for issuing the certificate.
To obtain a certificate from an Internet certificate authority, you must request a certificate by answering a series of questions in order to validate your identity. To obtain a certificate from a Windows 2003 Certificate Authority, you must be a member of a domain with auto-enrollment or be approved by the certificate authority administrator.
Security using a PKI uses two mathematically-related values: a public key and a private key.

The public key is shared with other users.
The private key is known only by the certificate owner.

The certificate includes a public key and other information such as the certificate holder and an expiration date.
E-mail message content can be encrypted.

The sender encrypts the message using the receiver's public key.
The receiver decrypts the message using the private key. Because only the receiver has the private key, only that user can read the e-mail contents.

Adding a digital signature to the e-mail message verifies that the message came from the purported sender (proof of identity) and that the message has arrived unaltered (data integrity).

The digital signature is encrypted using the sender's private key.
The receiver uses the sender's public key to decrypt the digital signature. Because only the sender knows the private key, this guarantees the message came from the sender.

S/MIME is supported by Outlook, Outlook Web Access, or POP3 or IMAP4 clients. Use the following process to use S/MIME for secure e-mail.

Obtain a certificate for each user.

Use the Web enrollment feature or the MMC to request a certificate from the Windows Server 2003 certificate authority.
Configure Active Directory with certificate autoenrollment. All users will be automatically given a certificate.
Request a certificate from a third-party certificate authority.

Enable S/MIME in the e-mail client application.

For Outlook/POP3/IMAP4 clients, load the certificate into the client application.
For Outlook Web Access, add the S/MIME control.

Share and obtain public keys with other users. Users who will send you encrypted e-mail must have your public key. You must have the public key for all users to whom you will send encrypted or digitally signed e-mails.

If you are using Active Directory autoenrollment, certificates will be added to the user accounts in Active Directory. When connecting through an Outlook client, the necessary public keys will automatically be retrieved for all recipients.
Users and administrators can add certificates to Active Directory recipients.

Users who obtain a certificate from a third-part CA can use the Publish to GAL option in Outlook to add the certificate to their user account.
Administrators can manually add certificates to recipients. For example, adding the certificate to a Contact object makes the certificate available through the Global Address List.

With the certificates added to Active Directory recipients, the recipient's public key is automatically retrieved from Active Directory.

For users who do not exist in Active Directory, or if you are using a POP3 client:

Send each user your public key by sending a digitally signed message.
Have each user send their public key by sending a digitally signed message. When you receive their message, add their certificate to your address book. Note: The certificate is only added to your personal address book, not the Global Address List.
Add the certificate authorities to the Trusted Root Certification Authorities list on the local computer (when using POP3 or IMAP4) or the Exchange server (when using SMTP). This ensures that your computer trusts the certificate authority who issued the recipient's certificate.

Message Filtering Facts

Message filtering allows an organization to reduce the amount of unsolicited mail entering the organization by stopping the flow of messages at the mail server. Exchange supports the following types of filtering.

Filter Type	Description
Connection Filtering	Connection filtering blocks messages based on the IP address of the SMTP server. § You can configure accept and deny lists of servers. § You can configure a Realtime Block List (RBL). The RBL is a commercially available list of IP and IP subnet addresses of known junk mail sources. § When using an RBL, you can allow exceptions to the block list. § Using an RBL puts an additional load on the server.
Recipient Filtering	Recipient filtering blocks Internet messages sent to specific recipients within the organization. This prevents certain recipients in the organization from receiving mail from the Internet.
Sender Filtering	Sender filtering blocks messages sent from a specific e-mail address. § You can block messages from a specific address or an entire domain. § You can delete or archive blocked messages.
Intelligent Message Filtering	Intelligent Message Filtering blocks messages that have specific words or phrases in the message. Intelligent Message Filtering is an add-on product to Exchange. § Intelligent Message Filtering assigns a number referred to as a Spam Confidence Level (SCL) based on the analysis of the content. § Exchange uses the assigned number to determine whether to send the message to the recipient, send it to a junk mail folder, or delete the message.

In addition to the filtering done at the server level, the Outlook and Outlook Web Access clients allow recipients to establish Safe Senders, Safe Recipients, and Blocked Senders lists.
Filtering settings are configured on an Organization-wide basis but enabled on individual virtual servers. To configure message filtering, complete the following steps:

In the Global Settings, edit the Message Filtering properties to configure the filtering settings.
For each virtual server, enable connection, recipient, and/or sender filtering.

Typically you will enable filtering on servers connected to the Internet that forward messages to internal Exchange servers. You should not need to enable filtering on servers that are used only for internal communications.
Note: Exchange only applies filtering to mail that is received from external SMTP servers. It does not apply filtering to mail sent between Exchange servers in an organization.

Auditing Exchange Servers

Because Exchange uses Active Directory objects, you can use auditing in Active Directory for Exchange the same way you use it on regular servers. The table below describes the audit categories and events available through Active Directory.

Audit Category	Trigger Event(s)
Account logon	Audits logon through a user account (users must log on to the company's domain to access their mailboxes) Recorded by the local computer for the local account, recorded by domain controller for the AD account
Account management	Add, rename, disable/enable, delete, or change the password for a user account (creates entries when changes are made to Active Directory user objects)
Directory service access	Access an object that has its own system control access list (SACL) (includes mailboxes, folders, and messages in Exchange)
Logon	Log on or off of the local system Make a network connection to a local computer Writes entries to the security log only on the computer to which the user attempts access. For example, if a user is attempting to access a mailbox on an Exchange server, the Exchange server will record entries in its security log.
Object access	File, folder, printer access Adds an entry to the security log on the server where the mailbox resides when a user accesses a mailbox
Policy change	Change account password or logon settings, user rights, or audit policies (records entries whenever account policy configurations change)
Privilege use	User exercises user rights (records entries whenever user rights are enforced) An administrator takes ownership of an object
Process tracking	Records entries whenever applications perform certain actions, such as loading objects into memory or creating new threads This is used mainly for program debugging and tracking
System events	Shutdown, restart, service starts An event affects security or the security log

Note: For Exchange Server 2003, Microsoft recommends that you set Audit account logon events and Audit logon events to Failure to avoid filling the security logs with large numbers of successful logon events.
To enable auditing for a domain member, edit the appropriate Group Policy Object and enable either Success or Failure auditing (or both). When enabling object access auditing, you must also access the Security tab of the object and enable auditing for the actions you want to track. You can enable auditing on specific Exchange objects by first enabling the Object Access policy, then using Exchange System Manager to access the Security tab for specific objects and enabling audit events for specific users. For example, you can set auditing to occur at any of the following levels:

Administrative Group level
Server level
Storage Group level
Store level

Exchange-specific events you can audit include:

Create public folder, create top level public folder, modify public folder ACL, modify public folder replica list
Open mail send queue
Administer information store, view information store status
Receive As, Send As

Be aware that in Exchange System Manager the Security tab is not available on all objects by default. To make the Security tab available, you must use the following procedure to edit the registry (Warning: Editing the registry improperly can result in catastrophic system failure from which you cannot recover. Before editing the registry, back up all valuable data.):

In Registry Editor (regedit), open the HKEY_CURRENT_USER | Software | Microsoft | Exchange | ExAdmin.
Select Edit | New | DWORD Value. Use the following settings:

Value Name = ShowSecurityPage
Value = 1

Close the Registry Editor. Exchange System Manager displays the results of the change immediately.

The following steps explain one way to enable auditing on an object within Exchange System Manager:

In Exchange System Manager, open the properties dialog box of the object you wish to audit (i.e., the administrative group, the server, the storage group, or the mailbox store).
Select the Security tab and click the Advanced button.
Select the Auditing tab and click Add.
Enter Everyone and click OK.
In the Auditing entry for dialog box, select This object, sub-containers, and children objects in the Apply onto drop-down list.
Select all the boxes for both Success and Failure in the Access List.

In addition to auditing events, you can analyze the security of your systems by running the Microsoft Baseline Security Analyzer (MBSA). This tool analyzes current system settings and identifies potential security weaknesses. You should run this tool on each system periodically to ensure that unwanted changes are not introduced on your systems.

Server Management Tools

The following table identifies tools in Exchange Server 2003 and Windows Server 2003 that will help you with your management tasks.

Tool	Description
Event Viewer	When troubleshooting Exchange, one of first places to go is the Event Viewer. Keep in mind the following regarding events: Exchange-specific events are typically logged in the Application log and begin with MSExchange. Event properties run in real-time. By continuing to review events you may find that the problem resolves itself. Microsoft has an option on its Exchange server Website that allows you to perform a search using the source field and event ID from the Event Viewer to research a database for articles related to issues you may be experiencing. You can configure Exchange to log additional events in the Event Log. To do so, in Exchange System Manager edit the properties of the server and enable Diagnostic Logging for the types of events you want to track.
Performance Monitor	Within Performance Monitor you can use the System Monitor to view real-time Exchange server statistics. You can view this information in a chart, histogram or report. System Monitor uses performance objects (categories of information) and counters (specific pieces of information) to track server statistics. When you configure System Monitor, you identify the objects and counters you want to track. The following list represents some of the key values you should examine: Exchange-specific objects begin with MSExchange. MSExchangeIS objects show information about the information store. MSExchangeDS objects show information about directory service access. The MSExchange Web Mail object shows information about Outlook Web Access. The MSExchangeAL object shows events related to the service that addresses e-mail through address lists. The MSExchangeTransport object records information about SMTP message routing. SMTP objects give you information about SMTP processes. The PhysicalDisk object gives you information about disk performance. The Memory object gives you information about system memory. The Network Interface object gives you information about network performance. The Processor object gives you information about the CPUs on the server.
Performance Monitor	Use the Performance Logs and Alerts option to collect data over a period of time. This data is collected in log files. You can use this data to create a baseline of performance, forecast future needs and identify bottlenecks. You can also use Performance Logs and Alerts to send alerts based on thresholds (you can put the thresholds in counter logs).
Exchange System Manager	Enable diagnostic logging for a server in Exchange System Manager to send Exchange event information to the Event Viewer. Enable diagnostic logging to log events related to authentication, connections, and client actions. When troubleshooting, activate the category specific to the problem at a medium or maximum level. Use Event Viewer to view the logged information. Disable logging when not needed to improve performance and reduce the amount of information sent to the Event Viewer.
	Enable protocol logging for a virtual server to log information about the operation of a protocol instance. Logging tracks the commands the virtual server receives from clients over a network and the commands the virtual server sends out. You can view the client IP address and domain name, connection time, bytes sent, and commands issued to the server. Information is logged in a custom log file. You can choose the format for the log file. W3C extended is the default format. It saves information to an ASCII file. Another useful format is ODBC Logging which sends the information into a SQL database. When using W3C logging, the default is to create a new log file every day. Logging is only available for SMTP and NNTP protocols. Use IIS to configure logging for HTTP.
	Use the Message Tracking Center to view the flow of a message through the Exchange system. When using message tracking: Enable message tracking in the properties of each server the message will be routed through. Go to the Message Tracking Center to view details on the messages including the sender, recipient, message size, subject, and the route the message took. Tracking information is kept in log files. The log files are stored in the Drive:\Program Files\Exchsrvr\servername.log.
	Use Monitoring and Status tools to monitor servers and connectors and to create notifications for server processes and statuses. Configure the statistics you want to monitor from the server object in the Status node. Add thresholds and warning limits for the items you want to track. Configure notifications to send e-mail or run a script. Using this tool you can monitor and send notifications specifying such situations as: When available disk space goes below a certain level. The failure of an Exchange service. The failure of a supporting Windows service such as DNS. A threshold for memory or queue length has been exceeded.
	Beneath each server is a Queues folder. This folder holds messages that are waiting to be delivered. Be aware of the following facts regarding queues: If you have messages going out to the Internet from this server, you will have a queue for each outbound domain. You also have queues for the connectors and queues for the SMTP virtual servers that are on the Exchange server. The queue viewer shows the protocol, queue state, and the number of messages in the queue. Periodically review the number of messages in each queue to locate significant problems. A large number of SMTP queues may indicate that there is either a denial of service attack, a lot of spam that is leaving the server, or an Internet connection that may be down.
WinRoute	WinRoute is an additional tool that shows the link state table for Exchange. Use WinRoute to query a server and view its table, routing groups, connectors, master, address spaces, and member servers.
Isinteg.exe	Isinteg is a command-line tool that analyzes and makes some repairs to the Exchange databases. Use Isinteg for problems similar to the following: Users are continuously connecting to their mailboxes and keep getting disconnected. Users report corruption within their mailboxes. Users report error messages that are associated with the database not being able to be mounted. Keep in mind the following when using Isinteg: Before using Isinteg, dismount the stores you want to analyze. The Information Store must still be running. Common switches include: -s to specify the server name. -test to identify the tests to run. Use alltests to run all tests. -l to specify a logfile name. When you run the program, you then select the database you want to test. Isinteg cannot fix all problems. If necessary, you might need to use Eseutil to repair other problems. For example, Isinteg cannot repair database level or page level errors.
Eseutil.exe	Eseutil is more powerful than Isinteg for repairing problems in the database. When using Eseutil: Dismount the stores you want to analyze. The Information Store must still be running. Common options with Eseutil include: /d to perform an offline defragmentation. /r to perform a database recovery. /g to check database integrity. /p to repair a database. Because defragmentation copies the files to a temporary file and then copies the compressed file back to the original file, the process needs a great deal of disk space to do this. To run defragmentation, you need about 110% of your file size available on your disk. It is recommended that you always perform a backup of your data before running Eseutil.
Microsoft Baseline Security Analyzer (MBSA)	You can use MBSA to analyze the security settings of your system according to Microsoft recommended security guidelines. MBSA finds security misconfigurations and missing security updates on a system. MBSA also offers specific guidance for correcting security problems.

Establishing a Baseline

To ensure the optimization and availability of your server, the following maintenance should be done on a daily basis.

Review the Event Viewer for events with error or warning status.
Use Performance Console to review the status of the disks, memory, network cards and processor for Exchange and Windows servers.
Review the status of required services on the Exchange and Windows servers.
Monitor failovers using the Cluster Administrator.
Review the status of all queues.
Ensure that there is an adequate amount of disk space, especially for the database and log files.

You should also perform the following tasks periodically:

Check the mdbdata directory for log files. If this directory has a large number of log files, it means that backups are not being performed properly.
Check the contents of the Badmail directory. Badmail contains mail that could not be delivered locally. You can manually delete the contents of this directory or download a tool from Microsoft which cleans out the directory periodically. Note: With Exchange Server 2003 SP1, the Badmail directory is no longer used.

As part of normal server maintenance, you should create a baseline to identify normal values for various system processes. In that way, you will be able to identify unusual loads and pinpoint the source of server problems. The following table lists the minimum counters you should monitor to establish a baseline for Exchange servers.

Counter	Description
MSExchange IS Mailbox\Message Opens/sec	Identifies the rate of message open requests.
MSExchangeIS Mailbox\Folder Opens/sec	Identifies the rate of folder open requests.
MSExchangeIS Mailbox\Local Delivery Rate	Identifies the rate of message delivery.
MSExchangeIS\ RPC Operations /sec	Identifies the rate of RPC operations. An unusually high number could result in Outlook not being able to contact the Exchange server. On 4-processor systems, this value should be 0.
MSExchangeIS\RPC Requests	Identifies the number of RPC requests currently being processed. This value should not exceed 100.
PhysicalDisk(_Total)Disk Transfers/sec	Identifies disk utilization as a percentage. This value should be below 50. Higher values could indicate that the disk is becoming a bottleneck.
Process(store)\% Processor Time	Identifies the percentage of time the processor spends on non-idle threads for the store process. A value consistently over 75-80% indicates an overloaded processor.
Processor(_Total)\% Processor Time	Identifies the percentage of time the processor spends on non-idle threads (overall). A value consistently over 75-80% indicates an overloaded processor.
SMTP Server\Local Queue Length	Identifies the number of messages waiting in the SMTP queue.
SMTP Server\Messages Delivered/sec	Identifies the rate at which messages are delivered to local mailboxes.
SMTP Server\Messages Received/sec	Identifies the rate at which messages are being received.
SMTP Server\Messages Sent/sec	Identifies the rate at which messages are being sent.

Note: Unless otherwise indicated, normal value ranges depend on your organization. You must identify the normal ranges for your servers so that you can identify when unusual values occur.

Optimization Facts

The following table covers important facts for optimizing the hardware components of your Exchange system.

Component	Facts to Consider
Memory	The maximum amount of memory that an Exchange Server 2003 can use is 3 GB. Installing more than 4 GB of memory in an Exchange server does not provide much of a benefit. By default, Exchange uses only 1 GB of memory. To use 3 GB maximum you must add the /3GB parameter to the boot.ini file. If you are using Windows 2003, add the /userva=3030 parameter to the boot.ini file to reserve 3 GB of user virtual memory. Use these switches for servers: That host large mailbox or public folder stores. With a large number of MAPI connections. Do not use the switches for SMTP relay hosts.
CPU	Multiple processors are recommended. Faster processors provide better performance. To maximize performance gains, consider upgrading disks and monitor network traffic before upgrading CPUs.
Disk	Because of Exchange's heavy database usage, disk I/O is usually the area where bottlenecks will occur. Keep in mind the following facts regarding disk storage: The faster the disks and the more that you have, the better your performance It is better to have smaller, higher performing disks than to use fewer spindles with large capacity. Verify that your disk tracks are sector-aligned using DiskPar. Track sector alignment can increase disk performance by 20 percent. Use RAID, NAS, or SAN solutions to improve performance. Move database files to their own disks to improve performance. Improperly implemented or poorly designed disk subsystems are responsible for most Exchange performance problems. Latency is the term used to describe the time period that one component of a system is waiting on another. In an Exchange system, latency is a problem when average read and write latencies are over 20 ms or the system experiences latency spikes over 50 ms that last for more than a few seconds.
Network	Keep in mind the following facts regarding your network hardware. Use a fast network card with at least a 100 Mb connection. If the Exchange server is responsible for a great deal of HTTPS traffic, such as hosting Outlook Web Access or if it is a front-end server, it is recommended that you use network cards with SSL accelerators. SSL accelerators have a processor that does encryption and decryption of SSL Ensure that the available network bandwidth is at least 20 percent greater than the amount required for client/server and server/server communications. A general guideline to estimate bandwidth for MAPI clients is to multiply the number of concurrent users by 2.5 Kbps or 3 Kbps for very active MAPI users.

Additional points to consider for optimization are:

Ensure that you have the current updates applied for your browsers, drivers, firmware, and other system components.
Review how you use various machines in the system to determine if you can turn off services.
Ensure that access to the global catalog server is readily available to all users especially in larger environments.

For more information on improving the performance of your Exchange network, see the document Optimizing Storage for Exchange Server 2003 on the Microsoft Website. Microsoft also has a topology calculator on their Website to help you to evaluate your hardware needs.

Troubleshooting Performance

The best way to troubleshoot problems is to prevent them from occurring. When you implement Exchange, it is important to correctly configure your systems to handle the projected load. Use the following tools to load test your current systems to determine if they can handle projected loads.

Tool	Description
Load Simulator (LoadSim)	LoadSim simulates the performance load of MAPI clients. LoadSim allows you to determine whether your servers can handle the loads that you've planned for them. However, LoadSim does not measure the following factors that may affect server performance: Incoming spam (unsolicited commercial e-mail) Incoming SMTP mail Account access from non-MAPI protocols, like POP3 and IMAP4 Mobile device use Public folder use
Exchange Stress and Performance (ESP)	ESP allows you to simulate several client sessions concurrently accessing the Exchange servers in your system. ESP compensates for some of the factors that LoadSim fails to evaluate. ESP simulates client sessions from the following protocols or APIs: WebDAV (for OWA) IMAP4, POP3, SMTP, NNTP LDAP OLE DB Outlook Mobile Access Sync and Outlook Mobile Access Browse
Jetstress	Jetstress allows you to verify the performance of Exchange Server 2003 disk subsystems by simulating I/O operations from a specific number of users. You use Jetstress in conjunction with Performance Monitor, Event Viewer, and ESEUTIL to verify that the Exchange disk subsystem meets the performance criteria you establish for before deploying the system.

By monitoring key statistics, you can identify problems as they start, or you can identify the likely cause of performance problems. The following table lists key statistics and threshold values.

Category	Counter	Threshold Value
Disk	% Disk Time	Keep below 90% A high value may indicate a hard disk bottleneck.
Disk	Avg. Disk Queue Length	Keep below 2
Memory	Available Bytes	Keep above 4000 (4 MB)
	Pages/sec	Keep below 20 (5 is ideal) If it is over 10, the system may be doing a lot of disk thrashing.
	Pool Page Bytes	If you are using the /3GB switch, this value should not be larger than 200 MB, except during backups when increases are normal.
	Pool Nonpaged Bytes	If you are using the /3GB switch, this value should not be larger than 100 MB.
	Free System Page Table Entries	Keep below 3,000
	Private Bytes	Any steady increases from the baseline indicate a possible memory leak.
MSExchangeIS	SMTP Server\Local Queue Length	Keep below 1,000
	Mailbox\Send Queue Size	Should be less than 500
	RPC Requests	Keep below 30
	RPC Averaged Latency	Should be below 50 ms
Paging File	% Usage	Keep below 75% If high, adding more RAM might solve the problem.
Physical Disk	% Disk Time	Should be below 50%
	Avg. Disk sec/Transfer	A high value might mean a full queue or disk failure
	Disk Transfers/sec	Keep below 50%
Process Counters	% Processor Time	Keep below 75-80%
Processor	% Privileged Time	Keep below 75% A high value typically indicates a failing device
	% Processor Time	Keep below 75-80%
	% User time	Keep below 75%
Server Work Queues	Queue Length	Should be below 4 A high value indicates processor congestion

Because you cannot constantly monitor system statistics, Exchange Server 2003 allows you to configure notifications when your system reaches thresholds you define. To set notifications, open the Tools folder in Exchange System Manager, right-click the Notifications folder and select New | E-mail Notification. You can select any combination of the following variables Exchange uses in notifications:

%TargetInstance.Name% variable indicates the name of the server or connector that triggered the notification.
%TargetInstance.ServerStateString% indicates the type of alert, either warning or critical.
%TargetInstance.ServicesStateString% reports the status of the services running on the server.
%TargetInstance.CPUStateString% indicates the status of the server's CPU.
%TargetInstance.QueuesStateString% indicates the status of the queues on the server.
%TargetInstance.DisksStateString% reports the status of the server's hard drives.
%TargetInstance.MemoryStateString% indicates the status of the server's virtual memory.

Once you identify the symptoms of poor performance, you can isolate the components that cause it.

Cause	Solution
High disk space usage	To isolate disk problems, you should examine the following five disk subsystems: Temp disk Database disks Transaction log disks SMTP queue Page file disk For each group of disks that performs the above functions, you'll have to perform a separate analysis since each function demonstrates distinctive I/O patterns. You can do the following to improve disk usage: Enable caching on the array controller, particularly the write-back cache Increase log buffers by starting with the default value of 512 and increasing in increments of 512 until you reach the maximum of 9000 Increase the database cache Note: Increasing the database cache can cause the server to become memory fragmented or run out of memory. Align disk partitions with storage track boundaries Enforce message size and mailbox size limits
High memory usage	To alleviate physical memory problems, remove unnecessary software from your Exchange server and run your maintenance tasks when server use is low. While Exchange Server 2003 can use up to 3 GB of memory (Store.exe can use up to 1.5 GB itself), Exchange's ExIFS kernel driver can also use up enough kernel memory to cause sever performance problems. You can do the following to improve kernel memory use: Minimize queues (such as SMTP delivery queues) Use /VGA or a generic video driver to free up system page table entries Use the /Userva switch for Microsoft Windows Server 2003
Processor time conflicts	To alleviate processor conflicts, do the same things you would do for memory problems. Perform maintenance tasks (backups, particularly) outside of normal operating hours, and rather than having an Exchange server perform multiple roles (e.g., as a mail server and public folder server), offload tasks to dedicated servers.

For more information on troubleshooting Exchange Server 2003 performance, particularly for Performance Monitor counters and values, use the Troubleshooting Exchange Server 2003 Performance document from Microsoft.

Storage Design Facts

The design of your storage system allows you to optimize the system and protect your data. An effective design strategy considers file location, protection level for the files, and the necessary hardware to support it. The table below identifies one way to structure the Exchange system to ensure optimization and fault tolerance.

Drive	Contents	Recommended Configuration
C:\	Operating System	RAID 1 or RAID 5
D:\	Pagefile	The pagefile should be on a different physical disk from the operating system. No special protection for the pagefile is required.
E:\	Transaction Logs	RAID 1 or if using a SAN system RAID 0+1
F:\	Exchange Store Databases	RAID 5

When designing data storage, keep in mind the following recommendations:

Separate the transaction logs and databases on even the smallest of systems for fault tolerance and performance.
When using default logging, you can optimize your system by storing the saved log files on a disk other than the one used to store the current (E00.log) file.

Place the current file on a fast disk to improve performance.
Place saved log files on a large disk.

If you have multiple storage groups, each group should have their own RAID 5 set.
Use SAN/NAS solutions to increase performance and storage capabilities. Verify with the hardware vendor that the system is designed to work with Exchange Server 2003.
Use a separate disk for the SMTP queue for increased performance.
RAID 0+1 is becoming more common because it delivers better I/O performance and eliminates the need for a write-back cache.

In addition to designing disk locations, you can improve manageability and availability by creating multiple stores and storage groups. The following table describes the recommendations for working with each.

Unit

Design Considerations

Stores

By creating multiple stores, you divide the Exchange database into multiple smaller databases. You might create multiple stores for the following reasons:

To establish different store policies. For example, you can create different stores for groups who have different mail retention and deletion policies.
To reduce the effects of a store failure or store maintenance on other users. If a store database is lost due to disk failure or corruption, having multiple stores minimizes the effect and allows users with mailboxes in other stores to continue working. Having multiple smaller databases also decreases the time it takes to restore a single store.
To make e-mail communications more efficient. Your store organization could mimic the way e-mail communications are conducted in your organization. Identify groups of users who communicate most frequently with each other and create a store for each group.
To make the database structure match your organizational structure. For example, you could create different stores for different departments or sites.

Storage Groups

With Exchange Server 2003, Microsoft recommends that you create a storage group for each store until you have reached the maximum number of allowable storage groups. Doing so:

Improves virtual memory management.
Ensures that fewer stores share the same transaction logs. For example, if you have a single storage group with three stores, all three stores will share the same transaction logs. By placing each store in its own storage group, you ensure that each set of transaction logs is used by a single store. This simplifies restore procedures and decreases restore times.

You might also create multiple storage groups for the following reasons:

To add more stores when a current storage group is full.
To configure different circular logging settings.
To configure different backup schedules for different storage groups.

SMTP Facts

A virtual server identifies a protocol running on the Exchange server. You can have multiple different protocols running at the same time or multiple instances of the same protocol running on a single server. Each instance of a protocol is represented by a different virtual server.
Simple Mail Transfer Protocol (SMTP) is the default protocol for Exchange Server 2003. SMTP is used in an Exchange system to:

Transfer mail between servers within an Exchange organization
Transfer mail between an Exchange server and a mail server on the Internet
Send mail from some Outlook clients to an Exchange server

You should be aware of the following facts regarding Exchange servers and SMTP:

By default, SMTP is enabled on all Exchange servers.
Windows 2000 Server and Window Server 2003 support Extended SMTP (ESMTP) by default. ESMTP supports host authentication and encryption.
An ESMTP host reverts to SMTP when the receiving host does not support ESMTP.
Exchange Server 2003 communicates with other mail servers using standard SMTP commands and numerical reply codes over TCP port 25. Exchange uses an asymmetric request-response protocol. This means that one host sends a command, waits for a reply and then sends another command.

Exchange uses one of three methods to identify the destination mail server for each message.

Method	Description
Active Directory	For messages sent within an Exchange organization, the Exchange server uses information stored in Active Directory to locate the destination mail server. The destination mail server is the Exchange server that holds the mailbox store that contains the recipient's mailbox.
DNS	For mail sent outside of your organization, the virtual server can be configured to use DNS for locating mail servers. The Exchange server uses its TCP/IP properties to identify the DNS server(s) it should use for name resolution. The Exchange server requests the MX (mailbox) records for all mail servers in the destination domain (the destination domain is the part of the e-mail address following the @ symbol). The normal DNS name resolution process is used by the DNS server to locate the DNS server of the destination domain. The destination DNS server returns all MX records for its domain. MX records include a preference value that identifies which record (and therefore which server) should be contacted first for sending mail. The DNS server also retrieves the A (host) records for the target mail servers. The A record maps the destination mail server name to its IP address. The Exchange server must have the IP address to be able to contact the destination mail server. If the first mail server does not respond, Exchange will contact the next mail server indicated by the next highest-preference MX record.
Smart Host	For mail sent outside of your organization, you can configure the Exchange server to forward all mail to a smart host (also called an SMTP relay). When using a smart host, all mail for external domains is sent to the smart host. The Exchange server will not use DNS to locate the destination mail server. Instead, the smart host is responsible for locating destination mail servers and sending the mail accordingly.

SMTP Virtual Server Facts

Keep in mind the following facts about managing SMTP virtual servers:

An SMTP virtual server is installed and enabled by default. Virtual servers for POP3, IMAP4, and NNTP are disabled by default on a new install, but enabled for an upgrade from Exchange Server 2000 (if they were enabled on the Exchange 2000 system).
To run multiple SMTP virtual servers on a single Exchange server, you need to assign a different IP address and port combination for each.
By default, the SMTP virtual server uses port 25. You can also configure an outbound port on which the server will try to communicate with other servers.
For internal mail servers, you can choose a custom port to prevent communication with servers on the Internet.
With Anonymous access disabled, Internet servers will not be able to communicate with your Exchange server.
Basic authentication sends credentials in plain text. Use TLS to encrypt authentication credentials. When using TLS, you will need to import a certificate.
An SMTP relay accepts mail from a client or server and relays it to other servers. By default, the Exchange server will only relay mail for internal users.
An open SMTP relay accepts inbound connections and relays messages from outside your organization. For security purposes, do not allow this type of relay. If necessary, add only specific hosts that are allowed to relay through the Exchange server.
You can configure message size limits on the virtual server. The message sizes enforced depend also on the global settings and the mailbox settings.
The Send copy of Non-Delivery Report to setting identifies an e-mail address where undeliverable mail is forwarded.
The Badmail directory receives messages that cannot be delivered. You should periodically review this directory and delete messages. The Badmail directory is not used with Exchange 2003 SP1--all bad mail is automatically deleted.
The Queue directory receives messages that are waiting to be delivered.
The Delay notification period identifies when a message is sent to the user indicating that there might be a problem sending the mail. The Expiration timeout is the amount of time after which an NDR is returned and the server stops trying to contact the destination mail server.
The Masquerade domain is a domain name that is used externally. Configuring the masquerade domain replaces internal SMTP addresses as they are used externally. This makes sent messages appear as if they have come from a different domain.
Use the Smart host setting to identify an SMTP server to which Internet mail will be forwarded. When you use a smart host, the Exchange server will no longer use DNS to locate other SMTP servers. Note: Typically you configure this at the connector, not on the virtual server itself.
When using the IP address to identify the smart host, enclose the address in brackets. For example: [192.168.1.1].
When you configure reverse DNS lookups, mail is not blocked. Instead, failed lookups are simply logged and the mail is allowed to be delivered.

Exchange Routing Facts

Routing in Exchange is the process of identifying how messages are sent within and outside of the Exchange organization. Routing is controlled by the following components.

Component	Description
Routing Group	A routing group is a group of Exchange servers that are connected by constant, high-speed links. The routing group topology typically mirrors sites in your organization that are connected by WAN links. Routing groups identify the physical routes that messages take. For communication within a routing group: All Exchange servers can send messages directly to each other. Messages are sent immediately. For this reason, the links between servers within the routing group should be constantly available and high-speed. SMTP is used as the protocol. For communication between routing groups or with external systems: You can control which servers are allowed to send messages between routing groups. You can block messages or schedule message delivery. You can customize the protocol used (SMTP, RPC, or X.400).
Connectors	Connectors identify paths between routing groups, to the Internet, or to external mail systems. By default there are no connectors. As soon as you create separate routing groups, the servers in the different groups cannot communicate with each other until connectors are created. Connectors are one-way paths between routing groups. To enable two-way communications, you must create a connector in both routing groups. When you create one connector, the Exchange System Manager asks you if you want to automatically create the connector on the other routing group. The connector defines the protocol used between the routing groups. Configure the connector properties to enforce message restrictions or delivery times.
Link State Information	Link state information is information about routing groups and connectors that the routing process uses to make routing decisions. Each routing group has a master server that maintains the link state information. By default, the first server in a routing group is the master.
Internal Routing Components	Various software processes within Exchange are used to make routing decisions. Internal components include the following: The routing engine is responsible for determining the message delivery path. The advanced queuing engine retrieves messages, categorizes them, and identifies the message destination. The message categorizer is a component of the advanced queuing engine that sends LDAP queries to the global catalog to retrieve the following information from Active Directory: The recipient's e-mail address The mailbox store where the user's mailbox is located The Exchange server that hosts the corresponding mailbox store

Connector Type	Description
Routing group connector	Use a routing group connector to connect two Exchange routing groups. Routing group connectors use SMTP for message delivery between routing groups or RPC to connect a routing group to an Exchange 5.5 routing group that uses a site connector. You can control which servers within the routing group are able to send messages using the connector by designating bridgehead servers. The bridgehead server is the server in charge of sending messages to other routing groups. You can designate one or multiple sending bridgehead servers. You can also identify the servers in the remote routing group to which messages will be sent by configuring remote bridgehead servers. Although you can connect routing groups using one of the other connector types, routing group connectors are the preferred method of connecting two routing groups.
SMTP connector	Use an SMTP connector to connect a routing group to an external mail system, the Internet, or a non-Exchange system. SMTP connectors identify SMTP virtual servers that are used to connect to external mail systems. You can control which servers within the routing group are able to send messages using the connector by designating bridgehead servers. Messages are sent to destination mail systems using either DNS to locate the remote mail system or by forwarding messages to a smart host.
X.400 connector	Use an X.400 connector to connect to X.400 systems or to Exchange 5.5 mail servers that are external to your organization. When using the X.400 connector, you can have only one originating server and one destination server. To configure multiple source or destination servers, you must create additional X.400 connectors X.400 connectors are only available in Exchange Server 2003 Enterprise Edition.

Routing Group and Connector Facts

Create new routing groups and rename existing ones.
Move servers to the appropriate routing group.
- In mixed mode, you can only move servers to routing groups in the same administrative group.
- You cannot move a server that is a bridgehead server for a connector in the current routing group. Remove the connectors from the server first, then move the server.
Create connectors. Without a connector, communication between routing groups is not possible.
- You must create a connector between the groups from each group. When you create the first connector, you will be prompted if you want to create a corresponding connector on the other routing group.
- Before you can create a connector, you will need to define a virtual server if it does not already exist.

The following table describes some important configuration settings for the routing group connector and the SMTP connector.

Connector Type	Setting Considerations
Routing Group Connector	For routing group connectors, You can specify local and remote bridgehead servers. Select These servers can send mail over this connector to identify local bridgehead servers. Use the Remote Bridgehead tab to identify remote bridgehead servers. The bridgehead server links to a virtual server on the Exchange server. You can configure mail restrictions on the connector that restrict the users, message priorities, and message sizes that are allowed to use the connector. Use the Delivery Options tab to configure a schedule when messages of certain types are allowed.
SMTP Connector	For the SMTP connector, You can choose to use DNS for mail server resolution, or identify a smart host to which all mail will be forwarded. Add local bridgeheads to identify the local bridgehead servers that will send mail through the connector. Use the Address Space tab to identify the destination mail domains that will be sent over the connector. To connect to other mail systems (such as GroupWise or Lotus Notes), select the corresponding address type. Use * to identify all destination domains. If you identify * as the accepted destination domains, do not check the Allow messages to be relayed to these domains checkbox. This configures the connector as an open SMTP relay. The Connector scope setting identifies the replication scope for the connector (either within the routing group or the entire organization). Select Entire organization to allow all servers to use the connector, such as when you are configuring an Internet connection. You can configure mail restrictions on the connector that restrict the users, message priorities, and message sizes that are allowed to use the connector. Use the Delivery Options tab to identify a schedule for when messages are sent. Specifically, use the settings on this tab if you do not have a persistent connection to the Internet. On the Advanced tab, you can configure the STMP commands that the connector will issue: The EHLO command opens an ESMTP session. By default, Exchange sends an EHLO command. The HELO command opens a standard client SMTP session. Configure the connector to send an HELO command if the other server does not support ESMTP. The ETRN command requests that the server send any mail in its queue for the specified domain. You can customize how the SMTP connector accepts ETRN commands. The TURN command switches the communication roles, allowing the client to become the server without establishing a new session.

Communication Troubleshooting Facts

In a organization with different routing groups, there might be multiple routes between any two routing groups. The following table lists the criteria used to select the route.

Factor	Criteria
Schedule restrictions	Is the connector available now?
Size restrictions	Is the size of the message under the maximum specified?
Message priority restrictions	Does the message qualify given its priority?
Permission of user	Does the user have permission to use this connector?
Cost of the route	Which route has the lowest cost?

An Exchanger server selects one route over another in the following way.

The server identifies all routes that meet the first four conditions.
If multiple routes can be used to send the message, the route cost is then used to select the route.
The cost is cumulative for each connector on the route. This means that the total cost is the sum of the costs for all connectors on the route.
The route with the lowest cost will be the one selected among the available routes.
In situations where the routes have the same costs, the route is selected at random.

To use message tracking, you must enable message tracking in the properties of each server the message will be routed through.
The Message Tracking Center allows you to see the whole flow process for each message.
Tracking information is kept in log files. The log files are stored in the Drive:\Program Files\Exchsrvr\servername.log.
You can specific the number of days that log files will be kept.
When troubleshooting message flow, use the Message Tracking Center. The Message Tracking Center allows you to track messages:
- Using the message id
- Based on the message sender or recipient
- That have flowed through a specific server

Exchange Client Facts

Client	Description
Outlook 2003 (MAPI) client	The Outlook 2003 client is the recommended client for Exchange Server 2003. Outlook 2003 takes advantage of newer Exchange Server 2003 features. The Outlook 2003 client: Use RPC or RPC over HTTP Communicates with the Exchange server using the MAPI interface through a DLL
Outlook Web Access (OWA)	Outlook Web Access connects to the Exchange server through the Internet. Outlook Web Access provides the same look and feel as Outlook 2003 and many of the same features. Outlook Web Access: Uses HTTP or HTTP with SSL Communicates through the HTTP virtual server to the Exchange virtual directory
Outlook Express	Outlook Express is a generic e-mail client that can be used to connect to Exchange and non-Exchange e-mail servers. Outlook Express: Uses POP3 or IMAP4 for receiving e-mail Uses SMTP for sending e-mail Communicates with the Exchange server through POP3, IMAP4, or SMTP virtual servers Note: You can also connect to an Exchange server using various other clients
Outlook Mobile Access (OMA)	Outlook Mobile Access is used with WAP-enabled browsers such as a cell phone or other portable device and is only available through Exchange 2003 servers. Outlook Mobile Access: Uses HTTP for mail access Communicates with the Exchange server using an HTTP virtual server with a special virtual directory
Non-Outlook Clients	Non-Outlook clients use POP3, IIMAP3, or SMTP for sending and receiving e-mail. To enable non-Outlook client support, you must configure the corresponding virtual servers on your Exchange server.

Note: Outlook and Outlook Web Access gives users the ability to create their own public folders.
Outlook 2003 provides users access to more features of the Exchange environment than other clients and even previous versions of Outlook. The following table identifies some of the Outlook 2003 enhancements and their benefits.

Enhancement	Benefit
Cache mode	Allows a copy of the Exchange mailbox to be stored offline on the Outlook client. Allows a background connection with the server while the client uses an offline copy of the mailbox. Allows a user to access the mailbox even when the Exchanger server is not available. Eliminates the need for a constant connection to the server. Reduces required bandwidth between the client and the server. Increases the number of users the network can support. Eliminates problems with slow connections. Note: Cache mode is different than the offline files used in previous versions. Outlook 2003 users do not have to select between working in cache mode offline or working with an online copy.
RPC over HTTP or HTTPS	Allows the client to establish an RPC connection over any Internet link Allows the RPC message encapsulated with HTTP to pass through standard ports that are typically open in firewalls Eliminates the need for Outlook and other MAPI clients to be connected remotely using a virtual private network (VPN) session. A virtual private network is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. Note: When you install Exchange Server 2003, support is automatically enabled for Outlook 2003 and Outlook Web Access clients. To enable support for other clients, start the corresponding virtual servers (POP3 or IMAP4). When you upgrade to Exchange Server 2003 from Exchange Server 2000, POP3 and IMAP4 virtual servers are already started.

Front-end Server Facts

When you create a front-end/back-end server configuration, clients connect to the front-end server. The front-end server then routes all requests to the Exchange server where the mailbox resides.

The primary benefit for using a front-end/back-end server configuration is to provide a single point of access for clients. For example, you can have a single URL for all Outlook Web Access users in your organization even though mailboxes might be located on multiple Exchange servers in the organization.
Using a front-end server also creates a single point of access to e-mail within the organization. This simplifies security administration and control, and allows you to disable various protocols that must be supported on each server.

When you use a front-end/back-end server configuration, one server is designated as the front-end server. All other servers are back-end servers.

Server	Description
Front-end server	The front-end server is the point of communication between the clients and the back-end servers. The front-end server: Communicates with clients using the following protocols: HTTP HTTPS POP3 IMAP4 SMTP RCP over HTTP to allow Outlook 2003 clients to connect to the front-end server using HTTP Communicates with back-end servers using the same protocols. However, when HTTPS is used by the client, the front-end server uses HTTP to communicate with back-end clients. In this case, use IPSec to secure front-end to back-end communications. No longer hosts mailboxes or public folders. Is typically accessible through the Internet (although you can also use a front-end server internally). Contacts Active Directory to determine the home server for each client (the server where the mailbox is stored). You must specifically configure a front-end server by editing the properties of the server object in Exchange System Manager.
Back-end server	Back-end servers host mailboxes and process client requests. By definition, all Exchange Server 2003 computers are back-end servers. When you configure a front-end server, you do not need to complete any additional tasks to configure the back-end servers.

The following Exchange versions support front-end servers:

Exchange Server 2000, Enterprise Edition
Exchange Server 2003, Standard Edition
Exchange Server 2003, Enterprise Edition

Note: Front-end servers are not supported in a Windows cluster. To provide fault tolerance and improve performance, configure multiple front-end servers using Network Load Balancing.
To configure a front-end server, complete the following steps:

Edit the properties of the server object in Exchange System Manager to designate the server as a front-end server. Restart all necessary services.
On the front-end server, move any mailboxes to other servers. Delete all public folder stores. If using SMTP, delete all mailbox stores except for one, otherwise delete all mailbox stores.
If necessary, configure additional virtual servers to support necessary clients (POP3, IMAP4). By default, HTTP and SMTP virtual servers are already configured on an Exchange Server 2003 system.
Disable any unneeded services and protocols.
Enable SSL to use HTTPS. To secure front-end and back-end server communications, use IPSec between the front-end and back-end servers.
Open required firewall ports to enable communication with the front-end server. Close unnecessary ports.

Public Folder Facts

Public folders are a shared storage location for any type of electronic documents.

Public folders can hold contacts, calendars, tasks, e-mail messages, and other documents.
Public folders, and the data they contain, are accessed through a client such as Outlook 2003, Outlook Web Access, IMAP clients, or NNTP applications.
Public folders exist in the public folder store on an Exchange server. Like a mailbox store, the public folder store is composed of two database files: .edb and .stm.
Public folders are organized in a public folder tree. The tree is the hierarchy of public folders.
The public folder organization is automatically replicated between Exchange servers in the organization. Content within a public folder (the data) is stored on a server and is not replicated automatically.
Each public store on the server is associated with a public folder tree. Only one public store per server can be associated for each tree, although a single tree may have multiple public stores associated with it as long as each store is on a different server.
Each organization has a single public folder tree. You can create additional public folder trees (called general purpose trees). One reason to use additional trees is for hosting news groups. Additional trees:
- Are not replicated automatically.
- Are not accessible through Outlook.
- Are accessible only to NNTP and HTTP clients.
- Require an HTTP virtual server for users to access from a Web browser.
To create a new public store on a server, there must be a public folder tree in the organization that is not associated with an existing store on that server. This means that to create a second public store on the server in a default environment, you will need to create a new public folder tree.
Public folders have an Active Directory entry with associated properties.
You can configure a public folder as a recipient. Public folders appear as objects in the global address list if they are mail-enabled.
- In a mixed mode Exchange environment, public folders are mail-enabled by default.
- In a native mode Exchange environment, public folders are not mail-enabled.
If you have the appropriate permissions, you can create public folders in the Exchange System Manager or in Outlook. Note: The tool you use determines some of the features available for managing public folders. For example, in Outlook (but not in Exchange System Manager) you can identify the type of data held in a public folder.
Properties for the public folder store are similar to properties for the mailbox store.
To create additional public folder stores for non-default public folder trees, you must create the public folder tree first.
To allow clients to access additional public folder trees, you must create an associated virtual directory beneath the HTTP virtual server.
You can configure storage limits and deleted item limits on the public store or on the public folder itself.
You can apply system policies to public stores to centrally control settings such as the maintenance interval, replication interval, store limits and deletion settings, and indexing.

Public Folder Permissions

Public folder permissions control what users can do to both the folder and its contents. Public folder permission types include:

Permission Type	Description
Client Permissions	Client permissions identify the actions that users can take on the contents of the public folder, such as posting or reading folder contents.
Directory Rights	Directory rights identify actions that can be performed on the Active Directory objects and properties associated with public folders. Note: The Directory rights option will be disabled if the public folder is not mail-enabled.
Administrative Rights	Administrative rights identify the actions that users can take on the public folder itself through an administrative tool (such as Exchange System Manager), modifying properties such as replication settings or modifying folder permissions.

Client permissions are configured either through Outlook or the Exchange System Manager. With two exceptions, client permissions are either granted or denied. Client permissions are:

Create items
Read items
Create subfolders
Folder owner (the folder owner can assign client permissions to the folder)
Folder contact
Folder visible
Edit items (options are None, Own, or All)
Delete items (options are None, Own, or All)

To assign permissions, add users or groups to the permission list, then give the user a role. Each role has an associated combination of client permissions.

Role	Permissions
Owner	All permissions (including Folder owner and Folder contact), Edit and Delete all items
Publishing Editor	Create items, Read items, Create subfolders, Folder visible, Edit and Delete all items
Editor	Same as Publishing Editor except without Create subfolders
Publishing Author	Create items, Read items, Create subfolders, Folder visible, Edit and Delete Own items
Author	Same as Publishing Author except without Create subfolders
Nonediting Author	Create items, Read items, Folder visible, Edit None and Delete Own
Reviewer	Read items, Folder visible, Edit and Delete None
Contributor	Create items, Folder visible, Edit and Delete None
None	Folder visible, Edit and Delete None

Note: If you manually choose a permission combination not represented by a role, the role is listed as Custom.
Keep in mind the following regarding managing client permissions:

By default, the Anonymous user is configured with Contributor permissions. This means that anyone can add content to a public folder.
When you create a child folder, permissions from the parent folder are copied to the child folder.
Changes made to the parent folder permissions are not automatically propagated to the child folders.
To copy parent folder permissions to child folders, use the Exchange System Manager to push the changes to child folders. When you propagate permissions to the child folder, existing permissions are deleted and replaced with the permissions from the parent folder.

Open the registry.
Browse to HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin\.
Create the following DWORD value: ShowSecurityPage = 1
In Exchange System Manager, edit the properties of the organization or administrative group. Use the Security tab to grant the Create public folder and Create top level public folder rights.

Public Folder Replication Facts

Replication of the various public folder components takes place as described in the following table.

Component	Replication method
Hierarchy	The hierarchy is the public folder tree or organization. The hierarchy for the default public folder tree is replicated automatically to other Exchange servers within the organization by the Information Store.
Content	Public folder data or contents are not replicated automatically. You must configure public folder content replication manually between servers. When you configure replication, you can configure the schedule and frequency that replication occurs.
Directory entry	The directory entry is the Active Directory object and its properties. Directory entries are replicated automatically through Active Directory replication.

Increases the fault tolerance of the public folder data.
Places copies of the data on local servers. Access data from local can reduce WAN link usage and improve access times.

Keep in mind the following facts about public folder data replication:

Replicating public folder data can decrease the WAN traffic associated with data access. However, it does cause an increase in WAN traffic due to replication traffic. Depending on the number of users, replication traffic might be less than data access traffic.
Only new information going into the original public folder is replicated.
When configuring replication, you specify the public folder store that will host a replica of the public folder.
The amount of time data in two replicas is different is called replication latency. Replication latency is dependent on the replication schedule. It is also associated with the amount of time it takes to replicate.
Determine the importance of current data being available in the replicated public folder, then adjust the replication schedule to reflect that level of importance.
When a user connects to a public folder store and the store does not contain a copy of the content the user is requesting, Exchange Server 2003 automatically redirects the user to a server that does contain the content. This is known as public folder referral.
To disable public folder referrals, edit the properties of the connector and check Do not allow public folder referrals. With this setting disabled, clients will only access local copies of public folder content.

When a client needs to access data in a public folder, Exchange uses replicas in the following order:

The public folder held on the mailbox server for the recipient.
A public folder held on another server in the local routing group.
If public folder referrals are allowed, a public folder in a remote routing group. The client chooses the routing group with the lowest cost. If two routing groups with the same cost exist, the location is chosen at random.

Exchange Firewall Ports

The following table lists various protocols and their associated ports that might be used in an Exchange implementation.

Protocol	Description	Ports
Protocol	Description	Ports
SMTP	Used to communicate with mail servers and by POP3 and IMAP4 clients to send mail. Note: SMTP with SSL is rarely used.	TCP 25 Using SSL, TCP 26
SMTP		TCP 25 Using SSL, TCP 26
POP3	Used to retrieve mail from an Exchange Server. Disabled on the Exchange server by default.	TCP 110 Using SSL, TCP 995
IMAP4	Used to retrieve mail and other directories from an Exchange Server. Disabled on the Exchange server by default.	TCP 143 Using SSL, TCP 993
HTTP	Used by Outlook Web Access for mail access.	TCP 80 Using SSL, TCP 443
LDAP	Used to access information from Active Directory.	TCP and UDP 389 for Active Directory access TCP 3268 for Global Catalog access
NNTP	Used to retrieve information from Usenet servers on and enables sharing news group public folders.	TCP 119 Using SSL, TCP 563
RPC	Used to establish an RPC connection (end point mapper) and also acts as an RPC client establishing sessions.	TCP 135 TCP 1024 and above (multiple ports are typically enabled)
DNS	When contacting Active Directory, a DNS server must be contacted for name resolution. The Exchange server uses DNS to find mail servers on the Internet	TCP and UDP 53
MTA	Used for X.400 connections or connections to Exchange 5.5 servers.	TCP 102
Kerberos	Used for communication and authentication with Windows 2003 servers.	TCP and UDP 88
IPSec	Used to secure server-to-server communications.	IP protocol 51 for AH IP protocol 50 for ESP UDP 500 for key exchange TCP and UDP 88 for Kerberos

Common Internet Configurations

By default, Exchange servers are enabled to communicate with other mail servers on the Internet.

Messages sent from users on your private network are routed through your Exchange servers to the appropriate Internet mail servers for external domains.
Messages sent from hosts on the Internet are sent to your Exchange servers where they can be retrieved by your network users.
Communication with other mail servers is controlled through properties set on the SMTP virtual servers or SMTP connectors.

The following table shows several methods for configuring and securing mail servers connected to the Internet.

Design	Description
Single Exchange Server	By default, every Exchange server is running an SMTP virtual server which is preconfigured to allow Internet access. You can quickly establish Internet mail service by adding a single Exchange server to your network. Use a single server configuration for small companies with a single Exchange server. The Exchange server is located behind the firewall on the private network. It has a single network connection. Public DNS servers must have an MX record pointing to this Exchange server. This record will be used by other mail servers to locate your mail server. When you install Exchange, it is already configured to accept incoming messages sent to your domain and to forward outgoing messages sent from authenticated users. Note: If your network had multiple Exchange servers, you can simply accept the default installation and all servers will have Internet connectivity as long as they have a physical connection to the Internet and the appropriate MX records have been configured. However, this configuration exposes multiple servers to Internet traffic.
Bridgehead Server	If your network has multiple Exchange servers, it is recommended that you use a bridgehead server to provide Internet messaging services. This method uses an SMTP connector to control which servers are allowed to send and receive mail through the Internet. The bridgehead server is located behind the firewall and has a single network connection. In the properties of the SMTP connector, designate one or more bridgehead servers. Configure * as the address space. This allows the connector to be used to send mail for all external domains. You can configure the SMTP connector to allow mail sent from within the entire organization to the Internet, or only from within the current routing group. When configured to send mail for the entire organization, the bridgehead server can be used by all servers, even servers in different routing groups. Configure MX records on public DNS servers to point to the bridgehead server.
SMTP Relay (Smart Host)	An SMTP relay host is any Windows Server 2003 running the SMTP services, a third-party server or hardware device that supports SMTP routing. Inbound and outbound messages move through the SMTP relay server. The SMTP relay is typically located inside a demilitarized zone (DMZ). A bridgehead server and SMTP connector is configured inside the private network. The SMTP connector is configured to point to the SMTP relay (set the Smart Host property of the connector). Note: Although you can configure the smart host on the SMTP virtual server, you should configure this setting on the connector to avoid problems. Configure the SMTP relay to only relay outbound messages from the bridgehead server. Configure the SMTP relay to only relay inbound messages that are sent to the private domain. Configure MX records on public DNS servers to point to the SMTP relay, not internal mail servers. Note: For fault tolerance, you might need to have multiple SMTP relay servers. In this case, add an MX record for each additional SMTP relay. Internal mail servers forward all outbound messages to the SMTP relay without performing DNS lookups for the destination mail servers. These lookups are performed by the SMTP relay. The SMTP relay does not need access to Active Directory for forwarding incoming mail. All incoming mail sent to the private domain is forwarded to the bridgehead server. This server then uses Active Directory to route the mail to the appropriate internal Exchange server. You can install anti-virus and anti-spam programs on the SMTP relay.

Be aware of the following considerations for connecting servers to the Internet:

The configurations shown above do not allow clients on the Internet to retrieve mail from your Exchange servers. They only permit incoming and outgoing server-to-server communications.
Internet mail servers are configured to use port 25 for SMTP. For the server configurations illustrated above, you only need to open port 25 in the firewall to enable server-to-server SMTP communications and port 53 to enable DNS name resolution. Internet mail servers are not configured to use secure SMTP.
Most Internet mail servers are not configured to use authentication. By default, SMTP virtual servers and connectors are configured to allow anonymous access. This enables your server to anonymously communicate with other mail servers.
To improve security on internal mail servers, you can require authentication or use TLS. However, disabling anonymous access on servers connected to the Internet will likely prevent that server from sending and receiving mail from Internet servers.
By default, SMTP virtual servers are configured to relay outbound messages sent from authenticated users and to relay incoming messages sent to the private domain. If you allow more open relaying, your server might be used as a spam relay where messages sent from the Internet are relayed through your server to other Internet hosts.

Securing Client Connections

Front-end Server in the DMZ
Front-end Server Behind an ISA Server

When enabling client connections through the Internet, you need to take several steps to ensure secure connections.

Secure client connections to the front-end server.
Secure front-end server connections to other servers.
Open outer firewall ports.
Open inner firewall ports.

Securing Client-to-Server Communications
By default, e-mail client communications with Exchange servers is not secured. You can use the following methods to secure client communications:

Outlook Web Access, POP3, and IMAP4

Outlook Web Access, POP3, and IMAP4 clients use Internet protocols to communicate with the front-end server. Use SSL to secure these connections.

Outlook 2003

The Outlook 2003 client uses RPC to communicate with the front-end server. Because RPC is not a secure protocol, use one of the following methods to provide security:

Configure a VPN connection to the Exchange server. RPC traffic is encapsulated in the VPN tunnel.
Configure an RPC over HTTP proxy server. RPC traffic is encapsulated in HTTP or HTTPS. Using RPC over HTTP requires fewer open firewall ports.

When using RPC over HTTP, be aware of the following requirements:

Clients using Outlook 2003 must be running Windows XP SP1 with a hot fix or SP2.
The RPC over HTTP proxy server must be running Windows Server 2003. It is recommended that this server be a front-end server. The front-end server must be running Exchange Server 2003.
All Exchange servers accessed by the RPC proxy server must be running Windows Server 2003 with Exchange Server 2003.
All global catalog servers accessed by the clients or the Exchange servers must be running Windows Server 2003.

When configuring SSL, be aware of the following considerations:

Consideration	Description
Adding SSL to the Server	You must add SSL to the appropriate protocols on the Exchange server based on the client protocols used. For POP3 and IMAP4, edit the properties of the virtual server and import a certificate. For HTTP (used by OWA and RPC over HTTP): In IIS, add a certificate to the Web site or virtual directory. In IIS on the Exchange virtual directory, select the Require secure channel (SSL) option. In Exchange System Manager, edit the HTTP virtual server and enable forms based authentication. In most cases you should not enable SSL for SMTP. Most Internet mail servers do not use secure SMTP.
SSL Accelerators	An SSL accelerator decreases the performance overhead created by SSL connections. There are two types of SSL accelerators: An SSL accelerator network card which you install in each front-end server. An external accelerator device that you put between the front-end server and the client. An SSL accelerator card offloads the encryption and decryption work and increases throughput by decreasing the workload of the server software. SSL accelerator cards work well in environments with a small number of front-end servers. In environments with a large number of front-end servers, the cost of a card for each server and the administrative overhead makes this solution prohibitive. In such a situation, an external accelerator is more appropriate. An external accelerator decrypts traffic coming from the client and sends it to the front-end server unencrypted. In the same manner, traffic from the front-end server is sent unencrypted, the accelerator device encrypts it, and forwards it to the client. When using an external accelerator, you must configure a special header, the Front-End-HTTPs: on header for OWA.
SSL Offloading	To gain the full benefits offloading SSL traffic to an external SSL accelerator device, the offloading device must support custom headers because it has to pass the Front-End-HTTPs: on header to the front-end server, which passes it to the back-end server. You can configure SSL between the accelerator device and the front-end server, but this defeats the purpose of offloading SSL.

Securing Server-to-Server Communications
The front-end server uses specific protocols to communicate with clients. The front-end server uses these same protocols to communicate with the back-end servers. However, the front-end server cannot use SSL to communicate with back-end servers. For example, a POP3 client uses POP3 with SSL to communicate with the front-end server. The front-end server would then use POP3 without SSL to communicate with the back-end servers.
Use IPSec to secure front-end/back-end communications, as well as communication between the front-end server and other servers. Be aware of the following facts when using IPSec:

IPSec is typically used when the front-end server is in a DMZ or on a different subnet than other servers. It is not needed when the front-end server is behind the intranet firewall.
The Authentication Header (AH) protocol provides authentication. The packet is not encrypted, but a checksum is added to verify data integrity.
The Encapsulating Security Payload (ESP) provides data encryption.
Use IPSec policies to control the communications allowed between servers. Use the Client (respond only) policy on back-end servers. This allows the backend server to use IPSec with the front-end server, while communicating normally with clients connected through the private network.

Opening Outer Firewall Ports
To enable communication with the front-end server, you need to open specific ports in the outer (Internet) firewall. The ports you need to open depend on the type of client connection that is used.

Client	Ports Required
Outlook Web Access	HTTPS (TCP 443) HTTP (TCP 80)
POP3	POP3 with SSL (TCP 995) POP3 w/o SSL (TCP 110) SMTP (TCP 25)
IMAP4	IMAP 4 with SSL (TCP 993) SMTP (TCP 25)
Outlook 2003 with RPC over HTTP	HTTPS (TCP 443)
Outlook 2003 with a VPN	You can use either PPTP or L2TP as the VPN tunneling protocol. PPTP (TCP 1723, 47) L2TP (UDP 500, 5500, 1701)

Note: The ports listed here are the only ports required for client-to-server communications. However, your firewall might need other ports open depending on the other services provided (such as a Web server or a DNS server).
Opening Inner Firewall Ports
Depending on location of the front-end server, you will need to open ports on the inner (intranet) firewall to enable clients or the front-end server to communicate with servers on the private network. The following table describes the ports required:

Configuration	Description
Front-end Server in the DMZ	If the front-end server is inside the firewall, the front-end server must be able to communicate with back-end servers, DNS servers, and Active Directory through the inner firewall. Open the following ports: All ports used by the client applications (such as HTTP, POP3, IMAP4) except for SSL. Remember that the front-end server cannot use SSL to communicate with the back-end servers. TCP port 691 for the Exchange link state algorithm. TCP and UDP port 53 to enable the Exchange server to communicate with DNS servers on the private network to locate domain controllers and Exchange servers. TCP and UDP port 389 for LDAP communication with Active Directory. TCP port 3268 for LDAP communication with the Global Catalog Server. TCP and UDP port 88 for Kerberos authentication. If IPSec is used: IP protocol 51 for AH IP protocol 50 for ESP UDP port 500 for Internet Key Exchange (IKE) TCP and UDP port 88 for Kerberos If RPC over HTTP is used, the clients must be able to perform authentication through the front-end server. You have the following choices to enable authentication: Open TCP ports 135 and multiple ports starting at 1024 for authentication using RPC. Open TCP port 135 and 1600 for authentication using RPC. This solution opens the minimum number of RPC ports in the inner firewall. Configure pass-through authentication. With pass-through authentication, you do not need to open RPC ports. However, the front-end server does not perform client authentication. Instead, authentication is passed through to the back-end server.
Front-end Server in the Private Network	If the front-end server is behind the inner firewall using an ISA server, you need to configure ISA to allow mail traffic to pass to the front-end server. Take the following steps to configure the ISA server: Configure an SSL listener on the ISA server. Add a destination set to the Internet interface. Create a Web publishing rule. This rule redirects traffic to the front-end server. Open any necessary outbound ports. Enable Outlook Web Access on the ISA server.

S/MIME Facts

Certificates are available through the Windows 2003 Certificate Authority or through a certificate authority on the Internet. The key management service offered by Exchange 2000 does not exist in Exchange 2003.
The certificate authority is responsible for validating identity and for issuing the certificate.
To obtain a certificate from an Internet certificate authority, you must request a certificate by answering a series of questions in order to validate your identity. To obtain a certificate from a Windows 2003 Certificate Authority, you must be a member of a domain with auto-enrollment or be approved by the certificate authority administrator.
Security using a PKI uses two mathematically-related values: a public key and a private key.
- The public key is shared with other users.
- The private key is known only by the certificate owner.
The certificate includes a public key and other information such as the certificate holder and an expiration date.
E-mail message content can be encrypted.
- The sender encrypts the message using the receiver's public key.
- The receiver decrypts the message using the private key. Because only the receiver has the private key, only that user can read the e-mail contents.
Adding a digital signature to the e-mail message verifies that the message came from the purported sender (proof of identity) and that the message has arrived unaltered (data integrity).
- The digital signature is encrypted using the sender's private key.
- The receiver uses the sender's public key to decrypt the digital signature. Because only the sender knows the private key, this guarantees the message came from the sender.

S/MIME is supported by Outlook, Outlook Web Access, or POP3 or IMAP4 clients. Use the following process to use S/MIME for secure e-mail.

Obtain a certificate for each user.
- Use the Web enrollment feature or the MMC to request a certificate from the Windows Server 2003 certificate authority.
- Configure Active Directory with certificate autoenrollment. All users will be automatically given a certificate.
- Request a certificate from a third-party certificate authority.
Enable S/MIME in the e-mail client application.
- For Outlook/POP3/IMAP4 clients, load the certificate into the client application.
- For Outlook Web Access, add the S/MIME control.

Share and obtain public keys with other users. Users who will send you encrypted e-mail must have your public key. You must have the public key for all users to whom you will send encrypted or digitally signed e-mails.

If you are using Active Directory autoenrollment, certificates will be added to the user accounts in Active Directory. When connecting through an Outlook client, the necessary public keys will automatically be retrieved for all recipients.
Users and administrators can add certificates to Active Directory recipients.
- Users who obtain a certificate from a third-part CA can use the Publish to GAL option in Outlook to add the certificate to their user account.
- Administrators can manually add certificates to recipients. For example, adding the certificate to a Contact object makes the certificate available through the Global Address List.
With the certificates added to Active Directory recipients, the recipient's public key is automatically retrieved from Active Directory.

For users who do not exist in Active Directory, or if you are using a POP3 client:

Send each user your public key by sending a digitally signed message.
Have each user send their public key by sending a digitally signed message. When you receive their message, add their certificate to your address book. Note: The certificate is only added to your personal address book, not the Global Address List.
Add the certificate authorities to the Trusted Root Certification Authorities list on the local computer (when using POP3 or IMAP4) or the Exchange server (when using SMTP). This ensures that your computer trusts the certificate authority who issued the recipient's certificate.

Message Filtering Facts

Filter Type	Description
Connection Filtering	Connection filtering blocks messages based on the IP address of the SMTP server. You can configure accept and deny lists of servers. You can configure a Realtime Block List (RBL). The RBL is a commercially available list of IP and IP subnet addresses of known junk mail sources. When using an RBL, you can allow exceptions to the block list. Using an RBL puts an additional load on the server.
Recipient Filtering	Recipient filtering blocks Internet messages sent to specific recipients within the organization. This prevents certain recipients in the organization from receiving mail from the Internet.
Sender Filtering	Sender filtering blocks messages sent from a specific e-mail address. You can block messages from a specific address or an entire domain. You can delete or archive blocked messages.
Intelligent Message Filtering	Intelligent Message Filtering blocks messages that have specific words or phrases in the message. Intelligent Message Filtering is an add-on product to Exchange. Intelligent Message Filtering assigns a number referred to as a Spam Confidence Level (SCL) based on the analysis of the content. Exchange uses the assigned number to determine whether to send the message to the recipient, send it to a junk mail folder, or delete the message.

In the Global Settings, edit the Message Filtering properties to configure the filtering settings.
For each virtual server, enable connection, recipient, and/or sender filtering.

Auditing Exchange Servers

Audit Category	Trigger Event(s)
Account logon	Audits logon through a user account (users must log on to the company's domain to access their mailboxes) Recorded by the local computer for the local account, recorded by domain controller for the AD account
Account management	Add, rename, disable/enable, delete, or change the password for a user account (creates entries when changes are made to Active Directory user objects)
Directory service access	Access an object that has its own system control access list (SACL) (includes mailboxes, folders, and messages in Exchange)
Logon	Log on or off of the local system Make a network connection to a local computer Writes entries to the security log only on the computer to which the user attempts access. For example, if a user is attempting to access a mailbox on an Exchange server, the Exchange server will record entries in its security log.
Object access	File, folder, printer access Adds an entry to the security log on the server where the mailbox resides when a user accesses a mailbox
Policy change	Change account password or logon settings, user rights, or audit policies (records entries whenever account policy configurations change)
Privilege use	User exercises user rights (records entries whenever user rights are enforced) An administrator takes ownership of an object
Process tracking	Records entries whenever applications perform certain actions, such as loading objects into memory or creating new threads This is used mainly for program debugging and tracking
System events	Shutdown, restart, service starts An event affects security or the security log

Administrative Group level
Server level
Storage Group level
Store level

Exchange-specific events you can audit include:

Create public folder, create top level public folder, modify public folder ACL, modify public folder replica list
Open mail send queue
Administer information store, view information store status
Receive As, Send As

In Registry Editor (regedit), open the HKEY_CURRENT_USER | Software | Microsoft | Exchange | ExAdmin.
Select Edit | New | DWORD Value. Use the following settings:
- Value Name = ShowSecurityPage
- Value = 1
Close the Registry Editor. Exchange System Manager displays the results of the change immediately.

The following steps explain one way to enable auditing on an object within Exchange System Manager:

In Exchange System Manager, open the properties dialog box of the object you wish to audit (i.e., the administrative group, the server, the storage group, or the mailbox store).
Select the Security tab and click the Advanced button.
Select the Auditing tab and click Add.
Enter Everyone and click OK.
In the Auditing entry for dialog box, select This object, sub-containers, and children objects in the Apply onto drop-down list.
Select all the boxes for both Success and Failure in the Access List.

Server Management Tools

The following table identifies tools in Exchange Server 2003 and Windows Server 2003 that will help you with your management tasks.

Tool	Description
Event Viewer	When troubleshooting Exchange, one of first places to go is the Event Viewer. Keep in mind the following regarding events: Exchange-specific events are typically logged in the Application log and begin with MSExchange. Event properties run in real-time. By continuing to review events you may find that the problem resolves itself. Microsoft has an option on its Exchange server Website that allows you to perform a search using the source field and event ID from the Event Viewer to research a database for articles related to issues you may be experiencing. You can configure Exchange to log additional events in the Event Log. To do so, in Exchange System Manager edit the properties of the server and enable Diagnostic Logging for the types of events you want to track.
Performance Monitor	Within Performance Monitor you can use the System Monitor to view real-time Exchange server statistics. You can view this information in a chart, histogram or report. System Monitor uses performance objects (categories of information) and counters (specific pieces of information) to track server statistics. When you configure System Monitor, you identify the objects and counters you want to track. The following list represents some of the key values you should examine: Exchange-specific objects begin with MSExchange. MSExchangeIS objects show information about the information store. MSExchangeDS objects show information about directory service access. The MSExchange Web Mail object shows information about Outlook Web Access. The MSExchangeAL object shows events related to the service that addresses e-mail through address lists. The MSExchangeTransport object records information about SMTP message routing. SMTP objects give you information about SMTP processes. The PhysicalDisk object gives you information about disk performance. The Memory object gives you information about system memory. The Network Interface object gives you information about network performance. The Processor object gives you information about the CPUs on the server.
Performance Monitor	Use the Performance Logs and Alerts option to collect data over a period of time. This data is collected in log files. You can use this data to create a baseline of performance, forecast future needs and identify bottlenecks. You can also use Performance Logs and Alerts to send alerts based on thresholds (you can put the thresholds in counter logs).
Exchange System Manager	Enable diagnostic logging for a server in Exchange System Manager to send Exchange event information to the Event Viewer. Enable diagnostic logging to log events related to authentication, connections, and client actions. When troubleshooting, activate the category specific to the problem at a medium or maximum level. Use Event Viewer to view the logged information. Disable logging when not needed to improve performance and reduce the amount of information sent to the Event Viewer.
	Enable protocol logging for a virtual server to log information about the operation of a protocol instance. Logging tracks the commands the virtual server receives from clients over a network and the commands the virtual server sends out. You can view the client IP address and domain name, connection time, bytes sent, and commands issued to the server. Information is logged in a custom log file. You can choose the format for the log file. W3C extended is the default format. It saves information to an ASCII file. Another useful format is ODBC Logging which sends the information into a SQL database. When using W3C logging, the default is to create a new log file every day. Logging is only available for SMTP and NNTP protocols. Use IIS to configure logging for HTTP.
	Use the Message Tracking Center to view the flow of a message through the Exchange system. When using message tracking: Enable message tracking in the properties of each server the message will be routed through. Go to the Message Tracking Center to view details on the messages including the sender, recipient, message size, subject, and the route the message took. Tracking information is kept in log files. The log files are stored in the Drive:\Program Files\Exchsrvr\servername.log.
	Use Monitoring and Status tools to monitor servers and connectors and to create notifications for server processes and statuses. Configure the statistics you want to monitor from the server object in the Status node. Add thresholds and warning limits for the items you want to track. Configure notifications to send e-mail or run a script. Using this tool you can monitor and send notifications specifying such situations as: When available disk space goes below a certain level. The failure of an Exchange service. The failure of a supporting Windows service such as DNS. A threshold for memory or queue length has been exceeded.
	Beneath each server is a Queues folder. This folder holds messages that are waiting to be delivered. Be aware of the following facts regarding queues: If you have messages going out to the Internet from this server, you will have a queue for each outbound domain. You also have queues for the connectors and queues for the SMTP virtual servers that are on the Exchange server. The queue viewer shows the protocol, queue state, and the number of messages in the queue. Periodically review the number of messages in each queue to locate significant problems. A large number of SMTP queues may indicate that there is either a denial of service attack, a lot of spam that is leaving the server, or an Internet connection that may be down.
WinRoute	WinRoute is an additional tool that shows the link state table for Exchange. Use WinRoute to query a server and view its table, routing groups, connectors, master, address spaces, and member servers.
Isinteg.exe	Isinteg is a command-line tool that analyzes and makes some repairs to the Exchange databases. Use Isinteg for problems similar to the following: Users are continuously connecting to their mailboxes and keep getting disconnected. Users report corruption within their mailboxes. Users report error messages that are associated with the database not being able to be mounted. Keep in mind the following when using Isinteg: Before using Isinteg, dismount the stores you want to analyze. The Information Store must still be running. Common switches include: -s to specify the server name. -test to identify the tests to run. Use alltests to run all tests. -l to specify a logfile name. When you run the program, you then select the database you want to test. Isinteg cannot fix all problems. If necessary, you might need to use Eseutil to repair other problems. For example, Isinteg cannot repair database level or page level errors.
Eseutil.exe	Eseutil is more powerful than Isinteg for repairing problems in the database. When using Eseutil: Dismount the stores you want to analyze. The Information Store must still be running. Common options with Eseutil include: /d to perform an offline defragmentation. /r to perform a database recovery. /g to check database integrity. /p to repair a database. Because defragmentation copies the files to a temporary file and then copies the compressed file back to the original file, the process needs a great deal of disk space to do this. To run defragmentation, you need about 110% of your file size available on your disk. It is recommended that you always perform a backup of your data before running Eseutil.
Microsoft Baseline Security Analyzer (MBSA)	You can use MBSA to analyze the security settings of your system according to Microsoft recommended security guidelines. MBSA finds security misconfigurations and missing security updates on a system. MBSA also offers specific guidance for correcting security problems.

Establishing a Baseline

To ensure the optimization and availability of your server, the following maintenance should be done on a daily basis.

Review the Event Viewer for events with error or warning status.
Use Performance Console to review the status of the disks, memory, network cards and processor for Exchange and Windows servers.
Review the status of required services on the Exchange and Windows servers.
Monitor failovers using the Cluster Administrator.
Review the status of all queues.
Ensure that there is an adequate amount of disk space, especially for the database and log files.

You should also perform the following tasks periodically:

Check the mdbdata directory for log files. If this directory has a large number of log files, it means that backups are not being performed properly.
Check the contents of the Badmail directory. Badmail contains mail that could not be delivered locally. You can manually delete the contents of this directory or download a tool from Microsoft which cleans out the directory periodically. Note: With Exchange Server 2003 SP1, the Badmail directory is no longer used.

Counter	Description
MSExchange IS Mailbox\Message Opens/sec	Identifies the rate of message open requests.
MSExchangeIS Mailbox\Folder Opens/sec	Identifies the rate of folder open requests.
MSExchangeIS Mailbox\Local Delivery Rate	Identifies the rate of message delivery.
MSExchangeIS\ RPC Operations /sec	Identifies the rate of RPC operations. An unusually high number could result in Outlook not being able to contact the Exchange server. On 4-processor systems, this value should be 0.
MSExchangeIS\RPC Requests	Identifies the number of RPC requests currently being processed. This value should not exceed 100.
PhysicalDisk(_Total)Disk Transfers/sec	Identifies disk utilization as a percentage. This value should be below 50. Higher values could indicate that the disk is becoming a bottleneck.
Process(store)\% Processor Time	Identifies the percentage of time the processor spends on non-idle threads for the store process. A value consistently over 75-80% indicates an overloaded processor.
Processor(_Total)\% Processor Time	Identifies the percentage of time the processor spends on non-idle threads (overall). A value consistently over 75-80% indicates an overloaded processor.
SMTP Server\Local Queue Length	Identifies the number of messages waiting in the SMTP queue.
SMTP Server\Messages Delivered/sec	Identifies the rate at which messages are delivered to local mailboxes.
SMTP Server\Messages Received/sec	Identifies the rate at which messages are being received.
SMTP Server\Messages Sent/sec	Identifies the rate at which messages are being sent.

Note: Unless otherwise indicated, normal value ranges depend on your organization. You must identify the normal ranges for your servers so that you can identify when unusual values occur.

Optimization Facts

The following table covers important facts for optimizing the hardware components of your Exchange system.

Component	Facts to Consider
Memory	The maximum amount of memory that an Exchange Server 2003 can use is 3 GB. Installing more than 4 GB of memory in an Exchange server does not provide much of a benefit. By default, Exchange uses only 1 GB of memory. To use 3 GB maximum you must add the /3GB parameter to the boot.ini file. If you are using Windows 2003, add the /userva=3030 parameter to the boot.ini file to reserve 3 GB of user virtual memory. Use these switches for servers: That host large mailbox or public folder stores. With a large number of MAPI connections. Do not use the switches for SMTP relay hosts.
CPU	Multiple processors are recommended. Faster processors provide better performance. To maximize performance gains, consider upgrading disks and monitor network traffic before upgrading CPUs.
Disk	Because of Exchange's heavy database usage, disk I/O is usually the area where bottlenecks will occur. Keep in mind the following facts regarding disk storage: The faster the disks and the more that you have, the better your performance It is better to have smaller, higher performing disks than to use fewer spindles with large capacity. Verify that your disk tracks are sector-aligned using DiskPar. Track sector alignment can increase disk performance by 20 percent. Use RAID, NAS, or SAN solutions to improve performance. Move database files to their own disks to improve performance. Improperly implemented or poorly designed disk subsystems are responsible for most Exchange performance problems. Latency is the term used to describe the time period that one component of a system is waiting on another. In an Exchange system, latency is a problem when average read and write latencies are over 20 ms or the system experiences latency spikes over 50 ms that last for more than a few seconds.
Network	Keep in mind the following facts regarding your network hardware. Use a fast network card with at least a 100 Mb connection. If the Exchange server is responsible for a great deal of HTTPS traffic, such as hosting Outlook Web Access or if it is a front-end server, it is recommended that you use network cards with SSL accelerators. SSL accelerators have a processor that does encryption and decryption of SSL Ensure that the available network bandwidth is at least 20 percent greater than the amount required for client/server and server/server communications. A general guideline to estimate bandwidth for MAPI clients is to multiply the number of concurrent users by 2.5 Kbps or 3 Kbps for very active MAPI users.

Additional points to consider for optimization are:

Ensure that you have the current updates applied for your browsers, drivers, firmware, and other system components.
Review how you use various machines in the system to determine if you can turn off services.
Ensure that access to the global catalog server is readily available to all users especially in larger environments.

Troubleshooting Performance

Tool	Description
Load Simulator (LoadSim)	LoadSim simulates the performance load of MAPI clients. LoadSim allows you to determine whether your servers can handle the loads that you've planned for them. However, LoadSim does not measure the following factors that may affect server performance: Incoming spam (unsolicited commercial e-mail) Incoming SMTP mail Account access from non-MAPI protocols, like POP3 and IMAP4 Mobile device use Public folder use
Exchange Stress and Performance (ESP)	ESP allows you to simulate several client sessions concurrently accessing the Exchange servers in your system. ESP compensates for some of the factors that LoadSim fails to evaluate. ESP simulates client sessions from the following protocols or APIs: WebDAV (for OWA) IMAP4, POP3, SMTP, NNTP LDAP OLE DB Outlook Mobile Access Sync and Outlook Mobile Access Browse
Jetstress	Jetstress allows you to verify the performance of Exchange Server 2003 disk subsystems by simulating I/O operations from a specific number of users. You use Jetstress in conjunction with Performance Monitor, Event Viewer, and ESEUTIL to verify that the Exchange disk subsystem meets the performance criteria you establish for before deploying the system.

By monitoring key statistics, you can identify problems as they start, or you can identify the likely cause of performance problems. The following table lists key statistics and threshold values.

Category	Counter	Threshold Value
Disk	% Disk Time	Keep below 90% A high value may indicate a hard disk bottleneck.
Disk	Avg. Disk Queue Length	Keep below 2
Memory	Available Bytes	Keep above 4000 (4 MB)
	Pages/sec	Keep below 20 (5 is ideal) If it is over 10, the system may be doing a lot of disk thrashing.
	Pool Page Bytes	If you are using the /3GB switch, this value should not be larger than 200 MB, except during backups when increases are normal.
	Pool Nonpaged Bytes	If you are using the /3GB switch, this value should not be larger than 100 MB.
	Free System Page Table Entries	Keep below 3,000
	Private Bytes	Any steady increases from the baseline indicate a possible memory leak.
MSExchangeIS	SMTP Server\Local Queue Length	Keep below 1,000
	Mailbox\Send Queue Size	Should be less than 500
	RPC Requests	Keep below 30
	RPC Averaged Latency	Should be below 50 ms
Paging File	% Usage	Keep below 75% If high, adding more RAM might solve the problem.
Physical Disk	% Disk Time	Should be below 50%
	Avg. Disk sec/Transfer	A high value might mean a full queue or disk failure
	Disk Transfers/sec	Keep below 50%
Process Counters	% Processor Time	Keep below 75-80%
Processor	% Privileged Time	Keep below 75% A high value typically indicates a failing device
	% Processor Time	Keep below 75-80%
	% User time	Keep below 75%
Server Work Queues	Queue Length	Should be below 4 A high value indicates processor congestion

%TargetInstance.Name% variable indicates the name of the server or connector that triggered the notification.
%TargetInstance.ServerStateString% indicates the type of alert, either warning or critical.
%TargetInstance.ServicesStateString% reports the status of the services running on the server.
%TargetInstance.CPUStateString% indicates the status of the server's CPU.
%TargetInstance.QueuesStateString% indicates the status of the queues on the server.
%TargetInstance.DisksStateString% reports the status of the server's hard drives.
%TargetInstance.MemoryStateString% indicates the status of the server's virtual memory.

Once you identify the symptoms of poor performance, you can isolate the components that cause it.

Cause	Solution
High disk space usage	To isolate disk problems, you should examine the following five disk subsystems: Temp disk Database disks Transaction log disks SMTP queue Page file disk For each group of disks that performs the above functions, you'll have to perform a separate analysis since each function demonstrates distinctive I/O patterns. You can do the following to improve disk usage: Enable caching on the array controller, particularly the write-back cache Increase log buffers by starting with the default value of 512 and increasing in increments of 512 until you reach the maximum of 9000 Increase the database cache Note: Increasing the database cache can cause the server to become memory fragmented or run out of memory. Align disk partitions with storage track boundaries Enforce message size and mailbox size limits
High memory usage	To alleviate physical memory problems, remove unnecessary software from your Exchange server and run your maintenance tasks when server use is low. While Exchange Server 2003 can use up to 3 GB of memory (Store.exe can use up to 1.5 GB itself), Exchange's ExIFS kernel driver can also use up enough kernel memory to cause sever performance problems. You can do the following to improve kernel memory use: Minimize queues (such as SMTP delivery queues) Use /VGA or a generic video driver to free up system page table entries Use the /Userva switch for Microsoft Windows Server 2003
Processor time conflicts	To alleviate processor conflicts, do the same things you would do for memory problems. Perform maintenance tasks (backups, particularly) outside of normal operating hours, and rather than having an Exchange server perform multiple roles (e.g., as a mail server and public folder server), offload tasks to dedicated servers.

Storage Design Facts

Drive	Contents	Recommended Configuration
C:\	Operating System	RAID 1 or RAID 5
D:\	Pagefile	The pagefile should be on a different physical disk from the operating system. No special protection for the pagefile is required.
E:\	Transaction Logs	RAID 1 or if using a SAN system RAID 0+1
F:\	Exchange Store Databases	RAID 5

When designing data storage, keep in mind the following recommendations:

Separate the transaction logs and databases on even the smallest of systems for fault tolerance and performance.
When using default logging, you can optimize your system by storing the saved log files on a disk other than the one used to store the current (E00.log) file.
- Place the current file on a fast disk to improve performance.
- Place saved log files on a large disk.
If you have multiple storage groups, each group should have their own RAID 5 set.
Use SAN/NAS solutions to increase performance and storage capabilities. Verify with the hardware vendor that the system is designed to work with Exchange Server 2003.
Use a separate disk for the SMTP queue for increased performance.
RAID 0+1 is becoming more common because it delivers better I/O performance and eliminates the need for a write-back cache.

Stores

By creating multiple stores, you divide the Exchange database into multiple smaller databases. You might create multiple stores for the following reasons:

To establish different store policies. For example, you can create different stores for groups who have different mail retention and deletion policies.
To reduce the effects of a store failure or store maintenance on other users. If a store database is lost due to disk failure or corruption, having multiple stores minimizes the effect and allows users with mailboxes in other stores to continue working. Having multiple smaller databases also decreases the time it takes to restore a single store.
To make e-mail communications more efficient. Your store organization could mimic the way e-mail communications are conducted in your organization. Identify groups of users who communicate most frequently with each other and create a store for each group.
To make the database structure match your organizational structure. For example, you could create different stores for different departments or sites.

Storage Groups

With Exchange Server 2003, Microsoft recommends that you create a storage group for each store until you have reached the maximum number of allowable storage groups. Doing so:

Improves virtual memory management.
Ensures that fewer stores share the same transaction logs. For example, if you have a single storage group with three stores, all three stores will share the same transaction logs. By placing each store in its own storage group, you ensure that each set of transaction logs is used by a single store. This simplifies restore procedures and decreases restore times.

You might also create multiple storage groups for the following reasons:

To add more stores when a current storage group is full.
To configure different circular logging settings.
To configure different backup schedules for different storage groups.

Windows Clustering Facts

Windows Clustering is a service that increases the availability and fault tolerance of network servers. With clustering, servers are grouped together into a cluster, with all servers sharing storage resources. Clusters provide high availability by migrating services on failed servers to available servers in the cluster.

Failover is the process of moving services from a failed server to another available server.
Failback is the process of moving those services back to the original server when it comes back online.

The following diagram illustrates a simple clustering configuration.

Notice that each server in the cluster has the following connections:

A connection to the regular network. This connection is used by clients to communicate with servers in the cluster.
A connection to a private network. This network allows the clusters to communicate with each other. This connection is used to detect new nodes and to coordinate failover.
A fiber channel connection to shared disk storage. Shared disks used by Windows Clustering:
- Must communicate using SCSI protocols. IDE, USB, or Firewire disks are not supported.
- Must be basic (not dynamic) disks.
- Must be formatted with NTFS.

Note: All IP addresses should be statically assigned.
Windows Clustering uses the following objects to control the clustering configuration and operation.

Object	Description
Cluster	A cluster is a group of servers operating as one unit that share common storage resources. The cluster itself has a name and an IP address that identifies the cluster as a single administrative unit.
Resource	Resources are physical or logical components that can be started or stopped and which are managed by the cluster service. Common resources include: The IP address The network name Physical disks When you create a resource, you are prompted to identify the following: Dependencies are resources that must be started before the current resource. Some resources cannot be defined until their dependent resources have been defined. Possible owners are the servers that can run or manage the resource. By default, all servers in the cluster are possible owners of all resources. One special resource is the quorum resource. The quorum resource is a storage disk that contains configuration information for the entire cluster.
Group	A group is a collection of resources that are managed as a single unit. Often, resources within a group are dependent upon each other. A group is owned by a server within the cluster. This server manages the resources associated with the group. Groups ensure that related resources are kept together on the same server. If one resource within the group must be moved to another server, all resources are moved together by assigning a new owner for the entire group. When you configure a cluster, the Cluster Group is created automatically. This group identifies the IP address, name, and quorum resources used by the entire cluster.
Virtual Server	A virtual server is a cluster group that identifies the set of resources needed to run applications normally associated with a physical server. The virtual server includes resources such as: The IP address The network name Physical disks Applications running on the server In the event of a failure, the resources managed by the physical server can be moved to another server in the cluster.
Node	A node is a server that is a member of a cluster. Active nodes are owners of a group and run or manage the resources associated with that group. Passive nodes are nodes that are available for failover (transfer of a virtual server or group). If the active node fails, the resources associated with that node can be moved to the passive node (at which time the passive node becomes an active node).

Windows Clustering is available on the Enterprise or Datacenter versions of Windows Server 2000 or Windows Server 2003.

Exchange Clustering Facts

To configure clustering for Exchange, you create Exchange Virtual Servers (EVS) in Cluster Administrator. An Exchange virtual server is a cluster group that has the Exchange System Attendant resource. These virtual servers then run on a physical Exchange server that is a cluster node. Each virtual server represents a different instance of Exchange server.
Note: Configuring clustering for Exchange does not provide load balancing. In other words, multiple physical servers do not share the same IP address and run the same Exchange virtual server. Instead, each physical server runs a different virtual server. This means that client requests to a specific virtual server are directed only to the physical server that is currently running the Exchange virtual server. The advantage of clustering is that the cluster provides additional nodes in the cluster that can be used for failover in the event that an active node fails.
When you configure clustering for Exchange, you have two options for configuring the relationship between the clustered servers. The various configurations are defined by which servers run an instance of an Exchange virtual server.

Configuration	Description
Active/Passive	In an active/passive configuration: Active nodes run an Exchange virtual server. Passive nodes are backup nodes for failover (and do not run an Exchange virtual server). One node must be passive. Exchange supports a maximum of 8 cluster nodes. The maximum number of active virtual servers is n-1. For example, if you have a 4-node cluster, you can only have 3 active nodes (with a total of 3 virtual servers running).
Active/Active	In an active/active configuration: There are two active nodes, both running a virtual server. The configuration is limited to a maximum of two nodes. There is no passive node. If a node failure occurs, the failed virtual server is moved to the other node. This leaves one server running two Exchange virtual servers. Note: Microsoft does not recommend an active/active configuration. When failover occurs, the remaining active node will have to take on the load of the failed server, degrading performance for both virtual servers.

Configuring a clustered environment has the following requirements:

An Advanced or Datacenter version of the Windows operating system:
- Windows 2000 Advanced Server supports up to 2 nodes
- Windows 2000 Datacenter Server supports up to 4 nodes
- Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition supports up to 8 nodes
Microsoft Clustering Services
Server nodes running the Cluster Service are required to be members of a domain.
Exchange Server 2003 Enterprise Edition installed on each node in the cluster.
Clustering is not supported on front-end servers. To provide fault-tolerance for front-end servers, use Network Load Balancing or some other service.
When configuring a front-end server connected to a back-end cluster, make sure the HTTP virtual directories on the front-end server and the back-end cluster are identical.
All servers in the cluster must be in the same administrative group and the same routing group.
Microsoft recommends that each server has identical hardware.
Microsoft recommends that clustered servers run only Exchange and not other services on the same system.
You cannot configure clustering on Exchange servers running connectors (such as Lotus Notes, GroupWise, Active Directory Connectors, or Calendar Connectors), Site Replication Services (SRS), or NNTP. Note: NNTP is required to install Exchange. Following installation, it will not function on the clustered server.

The following table identifies the permissions required to perform clustering tasks:

Task	Permission Required
Create an Exchange Server 2003 cluster	Member of local Administrators group member on each server node
Create an Exchange Server 2003 virtual server	Exchange Full Administrator at the organizational level
Create additional Exchange Server 2003 virtual servers	Exchange Full Administrator at the administrative group level of the server nodes

To set up a clustered Exchange Server 2003 environment, perform the following tasks:

Install the operating system on each node.
Create a cluster and add cluster nodes.
- For Windows 2000, you must manually install clustering. During the cluster installation, you will define the cluster or add each node to an existing cluster.
- For Windows 2003, clustering is installed during the operating system installation. Run the Cluster Administrator to create a new cluster and add each node to the cluster.
Create a Microsoft Distributed Transaction Coordinator (MSDTC) resource for Exchange Server 2003.
- It is recommended that you create a separate group in the cluster for this resource. Otherwise, you can create this resource in the Cluster Group group.
- On Windows 2000, you must install MSDTC on each cluster node. This installation also creates the resource in the cluster.
- On Windows 2003, use Cluster Administrator to create the resource. You do not need to install MSDTC on each node.
Install Exchange Server 2003 on each node. The setup program detects that clustering has been enabled and installs a cluster-aware version of Exchange.
- Install Exchange into the same directory location on each server.
- Do not install Exchange on more than one server at the same time.
- Note: If you install Exchange 2003 before configuring clustering, you must uninstall Exchange, configure clustering, then reinstall Exchange.

Create one or more Exchange Virtual Servers (EVS). To define a virtual server, create a cluster group and add the following resources:

Resource	Description
IP address	Clients connect to the Exchange server using the IP address and name associated with the virtual server, not the server's physical IP address.
Network name	When you create the network name resource, you must identify the IP address resource as a dependency.
Physical disk	The shared physical disk used to store the Exchange database files.
Microsoft Exchange System Attendant	The Exchange System Attendant is the main service that runs Exchange. When you create the system attendant: You must identify the Network name and Physical disk resources as dependencies. For the first system attendant resource in the cluster, you also identify the administrative group and routing group where the server resides. You specify the shared disk location for the database files. When you bring the System Attendant resource online, it will create additional cluster resources corresponding with other necessary services (such as those for the Exchange store, and protocols such as SMTP, POP3, and IMAP4).

Create additional Exchange Virtual Servers for each active node in the cluster. For example:
- For an active/passive configuration with two nodes, you will create a single virtual server.
- For an active/passive configuration with four nodes, you will create three virtual servers.
- For an active/active configuration, you will create two virtual servers.

To upgrade to Exchange Server 2003 on an existing cluster, use a method known as a rolling upgrade. A rolling upgrade uses the following process:

Fail one node. The passive node takes over for the failed node.
Upgrade the failed node to Exchange Server 2003.
Fail the original node back to the upgraded node.
Repeat the process for each node in the cluster.

Managing Exchange Clusters

Listed below are several tasks you might need to complete as you manage clustered Exchange servers.

Management Task	Description
Exchange Virtual Server Preferred Owner	Each virtual server has a preferred owners list. Use this list to customize how the cluster service identifies which physical server will be used to run the Exchange virtual server. By default, no preferred owners are set. The cluster service finds all Exchange servers in the cluster and chooses the physical server that will run the virtual server. You can configure one or more preferred servers. With preferred servers listed, the cluster service uses the following process to start the virtual server: The first server in the preferred list is tried. If the virtual server cannot be started, the cluster service tries the next server in the list. This process continues through all listed servers. If the end of the list is reached and the virtual server still can't be started, the cluster service tries other Exchange servers in the cluster. Configuring preferred servers is optional. Microsoft recommends that you list only a single server in the list. If you list multiple servers as preferred owners, make sure that a specific server does not appear at the top of the preferred owner list for multiple virtual servers.
Resource Possible Owners	Each resource has a possible owners list. This list identifies which servers can own a resource. By default, all cluster nodes are possible owners. If a node is not listed as a possible owner, it will not be able to manage or run the resource. For a server to be able to run an Exchange virtual server, it must be a possible owner for all resources in the group. The passive node must be identified as a possible owner of all resources for failover of a virtual server to occur.
Creating POP3 and IMAP4 Resources	When the System Attendant resource for a virtual server starts, it automatically creates resources for all corresponding services (such as SMTP) that are running on the Exchange server. If the POP3 or IMAP4 resources are not created automatically, start these services on the Exchange server, then restart the System Attendant service in Cluster Administrator.
Failover	Failover is the process of moving a virtual server from a failed node to another node. In an active/passive configuration, the virtual server is moved from the failed node to the passive node. Like all other nodes, the passive node can only run one Exchange virtual server at a time. If the passive node is already running an Exchange virtual server, failover won't take place. This means that a configuration with a single passive node can only handle failure of one active node. In an active/active configuration, the virtual server in the failed node is moved to the other active node. This means that the remaining active node is handling the load of both servers. For active/active failover to take place, the total number of storage groups and stores on the physical server must remain under the limits that exist on a single Exchange server. For example, both virtual servers have three storage groups and one node fails, failover will not take place because the remaining node must be able to run a total of six storage groups. For the virtual server, you can configure the following properties related to failover: The failover threshold identifies the maximum number of times that a virtual server can fail. The failover period identifies the timeframe for the virtual server failures. If the threshold value is reached within the failover period, the cluster service assumes the virtual server is corrupt and will no longer perform failover.
Failback	Failback is the process of moving the virtual server back to the original server following failover when the original server comes back online. By default, failback is disabled. This means that when failover occurs, the virtual server will continue to run on the passive node until you manually move it back to the restored node. This allows you to move the virtual server when it will least impact network users. To manually move a virtual server, select the cluster group and choose Move Group from the popup menu. You can edit the properties of the Exchange virtual server to enable failback. You can configure failback to happen immediately or between specific hours. For failback to occur, you must also list one or more preferred owners for the Exchange virtual server. If no preferred owners are listed, failback will not take place.
Performance Issues	Clustered Exchange servers have the following performance considerations: MAPI client connections per server should remain under 1900 active connections per server. CPU load should be under 40%. If these numbers are consistently high, the only solution is to reduce the load on the Exchange server. Do this by: Moving mailboxes from the overloaded server to another server in the cluster with spare capacity. Adding a new server to the cluster and moving some mailboxes from the overloaded server to the new server. Note: Simply adding a new node to the cluster improves fault tolerance by providing an additional passive node, but will not improve performance or reduce the load on overloaded servers.

Verifying Connectivity

If you are experiencing problems communicating with your Exchange server, one of the first places to start is to verify network connectivity. A good first test is to use Telnet to determine whether the server can be contacted and whether the SMTP service is running on the server. To use Telnet:

From a command prompt, type telnet.
Open a session by typing open servername port. For example, type open mail1 25 to open a connection to the mail1 server using port 25 (the default SMTP port number).

A successful connection verifies that you have network connectivity and that the service is listening on port 25. With the Telnet session open, you can also issue specific SMTP commands to verify server functionality:

The HELO command opens a standard client SMTP session.
The EHLO command opens an ESMTP session.
The ETRN command requests that the server send any mail in its queue for the specified domain.
The TURN command switches the communication roles, allowing the client to become the server without establishing a new session.
The VRFY command verifies that a mailbox is available for message delivery.
The QUIT command ends the session.

If a Telnet session cannot be opened, test network connectivity by:

Verifying the network path to the destination server. For example, you can use Ping or Tracert to verify that the server can be reached.
Verifying that the SMTP service is running on the server and with the correct port.
Verifying the TCP/IP configuration of the Exchange server such as the IP address, subnet mask, default gateway, and IP routing information. For example, you can use Ipconfig to view the current IP configuration of the server, or use NetDiag to verify IP connectivity including the TCP/IP configuration, verify that configured DNS or WINS servers can be contacted, show the routing table, or list available domain controllers,
Making sure that there are not any firewall or other restrictions preventing communications.

Verifying Name Resolution

Name resolution is used by both clients and servers to contact mail servers for sending and receiving mail. If you have network connectivity between hosts, but cannot establish a session, the problem might be related to name resolution. The following table lists several methods used by clients or servers to locate mail servers.

Method	Description
Active Directory	Exchange servers within an organization use Active Directory to locate other Exchange servers. If the Active Directory configuration is not valid, Exchange servers will not be able to forward mail to the destination mailboxes.
DNS Servers	Exchange servers can use DNS to locate external mail servers. In addition, clients use DNS to connect to mail servers to retrieve mail. DNS uses the following records for locating mail servers. One or more MX records identify the mail servers for a domain. Mail servers contact the DNS server to retrieve the name of all mail servers for the domain. For example, you might have three mail servers listed for the westsim.com domain. Priority numbers on the MX records identifies which servers should be contacted first. A records identify the IP address of a given DNS name. For example, MX records typically include the name of the destination mail server. The source mail server must then retrieve the A record to find the IP address of the destination mail server. CNAME records provide alternate names for Internet hosts. Occasionally, MX records point to CNAME records. CNAME records must be resolved by locating the corresponding A name record to identify the IP address. You can configure DNS server addresses as a property on the SMTP virtual server. The Exchange server will use these listed servers to try and locate other mail servers. If the virtual server is not configured with specific DNS server addresses, the Exchange server will contact the DNS servers listed in the TCP/IP properties for the network connection.
Smart Hosts	You can configure servers to use smart hosts instead of DNS servers when forwarding mail to external mail servers. All external mail is sent to the smart host. The smart host then uses DNS to locate the destination mail server.
NetBIOS Name Resolution	Most clients use DNS to locate mail servers. However, Windows NT and 9x clients might also use NetBIOS in some circumstances to find internal mail servers. If legacy clients cannot locate mail servers, the problem might be due to NetBIOS name resolution. Keep in mind the following facts about NetBIOS name resolution: NetBIOS uses broadcasts to locate other hosts. On a multi-subnet network, broadcasts are typically not forwarded through routers. To enable NetBIOS name resolution on multiple subnets, enable broadcast forwarding on routers, configure a WINS proxy, or use WINS servers.

To troubleshoot DNS name resolution use the following tools:

Tool	Description
Nslookup	Use Nslookup to test name resolution and retrieve DNS records. From a command prompt, type nslookup. Identify the record types you want to retrieve by typing set type=mx. The requests the MX records from the DNS server. Type the destination domain name. The DNS server will return the MX records for that domain.
Ipconfig	Use Ipconfig to perform automatic DNS name registration tasks: Use Ipconfig /registerdns on an Exchange server to update the A record on your DNS server. Use Ipconfig /flushdns on clients to purge the DNS cache and retrieve updated information from the DNS server.
Dcdiag	Use Dcdiag to perform several DNS-related features including: Testing connectivity to DNS servers Testing the functionality of forwarders Testing dynamic updates and current name registrations Performing a simple name resolution test to verify DNS functionality

Verifying Active Directory

Active Directory plays a major role in an Exchange 2003 organization including locating Exchange servers and identifying mail recipients. Issues related to Active Directory might include the inability to contact Exchange servers within the organization, delay or non-delivery of mail, or unsynchronized recipient information. Be aware of the following issues related to Active Directory.

Issue	Description
Global Catalog Servers	Global catalog servers are used for logon, for identifying group membership, and during Global Address List (GAL) access. Keep in mind the following recommendations for using global catalog servers: Exchange must be able to contact a global catalog server in its domain when the Exchange service starts. If your Exchange server is also a domain controller, make it a global catalog server as well. To reduce latency from Active Directory object access, place a global catalog server in each site. To provide fault tolerance, place two global catalog servers in each site. You should have one global catalog process for every four Exchange processes.
Expansion Servers	An expansion server is an Exchange server that is responsible for resolving recipient addresses, identifying members of distribution groups, and choosing Exchange routing. By default, the first server to process mail is the expansion server for that mail. For distribution groups, you can designate a specific expansion server that will identify group members and forward the mail to those members. Well-connected networks should not need specially-designated expansion servers for distribution group membership. Edit the properties of the distribution group to identify an expansion server. If an expansion server is listed and it cannot be contacted, mail will not be delivered to group members. To reduce the likelihood of this problem happening, keep the setting at its default of any available server.
Recipient Update Service	The Recipient Update Service updates Active Directory objects with Exchange-specific information. For example, when you mailbox enable a user, the Recipient Update Service modifies the user account to add mailbox properties. The Recipient Update Service update is scheduled to run at regular intervals (the default is every 60 seconds). You can administratively change this interval. New users will not be able to log on to their mailboxes and changes will not appear until after the update service runs. An instance of the Recipient Update Service is required in every domain where there are recipients or Exchange servers. RUS is added automatically when you install Exchange server. You must add RUS manually for domains where there is not an Exchange server.
Active Directory Replication	Active Directory replication replicates data that exists in Active Directory between domain controllers. Inaccessible objects or outdated information are two common symptoms of Active Directory replication issues. Be aware of the following issues that might be caused by Active Directory replication problems: Outdated recipient information. The Recipient Update Service is responsible for populating changes to recipients with one domain controller. However, Active Directory replication is then responsible for populating those changes with other domain controllers. If you find that correct recipient information does not yet exist on any domain controller, check the Recipient Update Service. If you find that only some domain controllers have the correct information, check Active Directory replication. Inaccessible or outdated Global Address List information. The following information is not replicated with Active Directory replication: Public folder data. Public folder data replication is controlled independently of Active Directory. If you have outdated public folder content, check public folder replication. Calendaring information is not replicated in Active Directory.

One tool you can use to test a host of Active Directory-related issues is Dcdiag. Some of the tests performed by Dcdiag include:

Verifying connectivity with domain controllers.
Verifying Active Directory replication status.
Verifying the availability of the logon service.
Performing DNS tests including DNS server connectivity and performing simple name resolution tests.

Backup Facts

Regular backups protect your system from database corruption, disk failure, and system failure. As you plan a backup strategy, you will need to make the following decisions:

Should I perform an online or offline backup?
What data needs to be backed up?
Which backup tool should I use?
Which type of backup operation should I perform?

Online and Offline Backups
The following table differentiates online and offline backups.

Backup Type	Description
Online backup	The backup is performed while the server is running and servicing clients. Online backup backs up the databases. Performance is impacted by the backup, but users will still be able to access the server and mail can still come into your Exchange server.
Offline backup	The backup is performed when the database is dismounted and not available to clients. During an offline backup, the transaction logs written to the database are not purged and the database is not checked for corruption.

In most cases, you can perform an online backup of the Exchange data.
Selecting the Data to Back Up
The type of data you choose to back up depends on the type of restore operations you expect to perform. The frequency with which you back up data also depends on the type of data that is being backed up. The following table lists three types of data that you can choose to back up.

Backup Data	Description
Windows Backup Set	The Windows Backup Set includes all of the necessary information to restore Windows, but does not include applications or application data. To create a Windows Backup Set: Back up the boot partition, the system partition, and the system state data. Do not back up application directories (such as the Exchsrvr directory). Do not back up application data directories (such as the Exchsrvr/MDBDATA folder). Keep in mind the following when performing a Windows Backup Set: Perform this backup weekly or whenever the system configuration changes. For full system protection, you must perform an additional backup of application data. When you restore from a Windows Backup Set, you will need to restore the operating system from the backup, reinstall all applications, then restore the application data. Backups are only good for 60 days, after which time the backup cannot be used to restore the system. Note: Backing up the system state data backs up the registry and the Active Directory database (if the computer is a domain controller).
Full Computer Backup	A Full Computer Backup backs up the operating system, applications, and some or most application data. To create a Full Computer Backup: Back up the boot partition, the system partition, and the system state data. Back up application directories (such as the Exchsrvr directory). Do not back up application data directories (such as the Exchsrvr/MDBDATA folder). Keep in mind the following when performing a Full Computer Backup: For full system protection, you must perform an additional backup of application data. When you restore from a Full Computer Backup, you restore the computer from the backup, then restore the application data. One way to create a Full Computer Backup is to use disk imaging tools that image and archive the entire disk.
Exchange Data	When you back up Exchange data, you back up the database files on the Exchange server. Keep in mind the following facts about backing up Exchange data: One reason for backing up Exchange data separate from system state data is because Exchange data changes frequently and should be backed up daily. Using Windows Backup, you can only back up data at the mailbox store level. You cannot back up individual mailboxes. Because all mailbox stores in a storage group share the same log files, you should back up the entire storage group at once. When you do not back up all of the stores in the storage group, the log files may not get deleted properly.

Selecting the Backup Tool
The following table lists several tools you can use to back up Exchange data.

Product	Description
Windows Backup	Windows Backup is integrated with Exchange. Use Windows Backup to: Create a Windows Backup Set and Full Computer Backup. Back up Exchange data. Windows Backup is integrated with Exchange and efficiently uses the log files to backup and restore the Exchange database.
Mailbox Merge Wizard (Exmerge)	The Mailbox Merge Wizard is a Microsoft tool that extracts data from a mailbox store. Exmerge saves mailbox information in personal store (.pst) files. You can copy the .pst file to a client computer and import it into Outlook. Then you can move messages or merge the entire database with an existing mailbox. Using Exmerge, you can perform brick backups (backups of individual mailboxes). You can also use Exmerge to copy all mailboxes in a mailbox store as a backup. Use this approach for small organizations.
Third-part tools	Use third-party tools to provide functionality not provided by Windows Backup. For example, third-party tools use the Exchange APIs to extract data for the following types of backups: Brick level backups. Shadow Copy backups. Volume Shadow Copy Service (VSS) is a Microsoft Windows Server 2003 service that enables backup software to create a snapshot of data at a specific point in time and back up from that snapshot. Windows Backup does not support shadow copy backups for Exchange data. Third-party tools that support shadow copy use the Exchange Volume Shadow Copy APIs.

Selecting the Backup Type
The following table identifies the types of backup with Windows Backup. The backup types you implement determine the type of data that is backed up and what is done with the Exchange log files.

Backup Type	Description
Full	Backs up the entire database. Purges the log files. When restoring from a full backup, restore only the last full backup. Reduces the amount of restore time, but requires the longest amount of time for each backup. Most backup strategies combine periodic full backups with incremental or differential backups (but never with both at the same time).
Incremental	Backs up only the log files. Purges the log files. This means that each incremental backup only backs up information that has been changed since the last full or incremental backup. When restoring from an incremental backup, you restore the last full backup and each incremental backup made since the full backup. Combining full with incremental backups gives you the quickest backup strategy.
Differential	Backs up the log files since the last full backup. Does not delete the log files. When restoring from a differential backup, you restore the last full back up and then the last differential backup. Differential backups take a little longer to back up than incremental backups, but restoration is faster.
Copy	Backs up the entire database. Does not delete the log files. Perform a copy backup to get a copy of the current data without interrupting the backup schedule. For example, you might perform a copy backup before a restore or before you are making significant changes to your system such as installing a service pack.

Note: When using third-party backup tools, the interaction of the backup software with the log files might differ from the backup types described here.
Additional Backup Details
Keep in mind the following facts about working with Exchange backups:

Backup scheduling occurs at the storage group level.
In Windows Backup, the smallest unit you can back up and restore is the mailbox store. However, you should back up and restore an entire storage group together.
A good way to determine if your backups have been running properly is to look at your log files. If your backups have been running properly, you will not have old log files.
Circular logging can have an impact on backup. When circular logging flushes the log files, they are not available for backing up. This means that you cannot do a differential or an incremental backup of your data when you implement circular logging. When using circular logging, perform only full backups.
Place transaction logs on a fault tolerant drive to ensure that the most current transaction logs can be salvaged. If the transaction logs are lost, the best restore you can perform is to restore from the last backup. Mail received since the last backup will be lost.
Permissions required for backup are:

Task Minimum permissions

Exchange backups Domain backup operator

Exchange restore operations Full Exchange administrator

Windows backups Local backup operator

Windows restore operations Local administrator rights

Using VSS for Backup

Volume Shadow Copy Service (VSS) is a component of the backup system that takes a point-in-time snapshot of files on the disk. By enabling VSS, you can quickly back up and restore files.
Note: While Exchange Server 2003 has a native VSS Writer, the Windows Server 2003 backup application does not have an Exchange-aware VSS Requestor. To use VSS with Exchange Server 2003, you must use a third-party backup application that is Exchange compliant.
An Exchange Server 2003 backup with Volume Shadow Copy services uses the following process:

The backup program runs according to the established schedule.
The backup program uses a VSS Requestor to command VSS to make a shadow copy of the designated Exchange Server 2003 storage group(s).
To prepare to make the shadow copy, VSS communicates with the Exchange Server 2003 Writer. Exchange Server 2003 performs the following actions:
- It prohibits administrative actions against the designated storage groups.
- It checks volume dependencies and prohibits write operations to database and transaction log files (but it does allow read-only access).
VSS contacts the appropriate storage provider to make the shadow copy of the volume(s) that contain the Exchange Server 2003 storage group(s).
After completing the shadow copy, VSS contacts the Exchange Server 2003 Writer and Exchange returns to its normal operational state.
The VSS Requestor verifies the shadow copy before it confirms a successful backup operation to Exchange.

You should know the following facts about using VSS with Exchange Server 2003:

You can only use VSS with Exchange Server 2003 running on Windows Server 2003.
You can only back up an entire storage group, but you can restore an individual database.
Shadow copy backups must be restored to the same drive and directory where the backup was made.
You cannot restore a shadow copy backup to the Recovery storage group.
Exchange suspends all operations during VSS backup/restore procedures. The Exchange Writer coordinates with the Exchange store to freeze and dismount the storage group prior to a backup/restore.

Exchange Recovery Methods

The following table lists several operations you can perform to retrieve lost data in Exchange Server 2003.

Feature	Description
Deleted Item Retention	When a user deletes a mail message from the Deleted Items folder, the message is retained according to the Deleted Item Retention setting. The setting can be configured on the individual mailbox or the mailbox store (for all mailboxes in the store). Settings on the mailbox can be more restrictive, but not less restrictive, than set on the store. By default, the mailbox store retains deleted items for 7 days. Users can restore deleted items using Outlook or Outlook Web Access. In Outlook, select the Deleted Items folder, then choose Tools/Recover Deleted Items... In Outlook Web Access, click the Options button. In the Recover Deleted Items section, click the View Items button. When the item retention period is reached, the item is permanently deleted from the system. After this time, you will need to restore the mailbox store from a backup and extract the messages you need.
Mailbox Retention	When the administrator deletes a mailbox for a user, the mailbox is retained according to the Mailbox Retention setting. The mailbox retention setting is configured on the mailbox store. By default, mailboxes are retained for 30 days. Use the Exchange System Manager to reconnect a deleted mailbox to a user account. You can reconnect the mailbox to the same user account or a different user account. Mailboxes are purged when the retention interval is up. You can also manually purge mailboxes you know that you will not need. To recover purged mailboxes, you will need to restore When you Purge the mailbox, the mailbox is permanently removed and can no longer be reconnected. After the mailbox is purged, you will need to restore the mailbox store from a backup and extract the mailbox you need.
Restore the Mailbox Store	If you cannot recover deleted items or deleted mailboxes, you will need to restore the mailbox store from your latest backup. Keep in mind the following facts for restoring mailbox stores using Windows Backup: You can only restore an entire storage group or selected mailbox stores. You cannot restore individual mailboxes or messages. Restoring a mailbox store overwrites any changes that have taken place since the last backup. Before restoring a mailbox store, select the This database can be overwritten by a restore option on the required mailbox stores. If this setting is not selected, the restore will fail. You must select this option prior to performing each restore operation. For example, if you have one full backup and two incremental backups, you must enable this setting prior to all three restore operations. Be sure to restore the last full backup and any incremental or differential backups that were performed. When you restore the Exchange data, the backup software "replays" the transaction logs to restore the data that has been saved since the last time the transaction logs were deleted. Transaction logs in a directory may be deleted when a full storage group is restored. Remember that transaction logs are shared between all mailbox stores in the storage group. For this reason, when you restore a single mailbox store, you could lose some data in other stores. If possible, restore all mailbox stores in a storage group. To restore a database, you can use Windows Backup.
Recovery Storage Group	Restoring a database overwrites any change made or messages sent since the last backup. If you are restoring to recover a single mailbox or message, you will not want to overwrite existing mailboxes. To restore individual mailboxes or messages, you can use the Recovery Storage Group. The Recovery Storage Group is available on Exchange Server 2000 SP3 and later systems. It is a storage group in addition to the mailbox and public folder storage groups you can create on an Exchange server. The Recovery Storage Group runs on the same Exchange server. When you restore a mailbox store to a recovery storage group, you have two instances of the same mailbox running on that server. You can only use recovery storage group with mailboxes, you cannot use it with public folder stores. After restoring the mailbox store to the Recovery Storage Group, you can restore individual mailboxes and then extract individual messages. Note: To reconnect a mailbox to a user, the user must still exist in Active Directory. Use the following process to restore items: Create the Recovery Storage Group. Restore the mailbox store. Use Exmerge to merge mailboxes or messages.
Recovery Forest and Server	A recovery server is a separate Exchange server that is used for restoring mailbox stores. When using a recovery server, you configure a duplicate Exchange organization. Data is restored to the duplicate organization, keeping your original organization and data intact. When using a recovery server: The server must be installed in a separate forest from the original Exchange server. The Exchange organization, administrative group, server, storage group, and mailbox store names must match the original Exchange organization. Note: Exchange uses the legacyExchangeDN value to identify these object names in Active Directory. When you configure a recovery server, you can simply modify this property value rather than re-install Exchange each time you need to restore a mailbox store. Use the following general process to configure a recovery server: Identify the names of the organization, administrative group, server, storage group, and mailbox stores for the data you need to restore. Configure a new Active Directory forest. Configure DNS for the new forest. Install Exchange on a domain member in the new forest. Configure administrative groups, storage groups, and mailbox stores on the new server. If necessary, change the legacyExchangeDN value for each object to match the values of the original Exchange organization. Restore the storage group and mailbox stores from backup. Reconnect mailboxes to Active Directory accounts. If necessary, you will need to create user accounts in the new domain. For a large number of accounts, you can import data from the original domain into the recovery domain. Use Exmerge to export mailbox information for specific users.

Restore from Backup Facts

If you cannot recover deleted items or deleted mailboxes, you will need to restore the mailbox store from your latest backup. Restoring mailboxes from backup consists of two processes:

Restore is the process of putting database and log files back into place on a server.
Recovery is the process of replaying transaction logs into the restored database. There are two types of recovery:
- Soft recovery occurs when transaction logs are replayed into a database that is re-mounted after an unexpected stop or into an offline file copy backup of a database.
- Hard recovery occurs when a transaction log is replayed into a database that has been restored from an online backup.

Keep in mind the following facts for restoring mailbox stores using Windows Backup:

You can only restore an entire storage group or selected mailbox stores. You cannot restore individual mailboxes or messages.
Restoring a mailbox store overwrites any changes that have taken place since the last backup.
Before restoring a mailbox store, select the This database can be overwritten by a restore option on the required mailbox stores.
- If this setting is not selected, the restore will fail.
- You must select this option prior to performing each restore operation. For example, if you have one full backup and two incremental backups, you must enable this setting prior to all three restore operations.
Be sure to restore the last full backup and any incremental or differential backups that were performed. You must run the full backup first to create the Restore.env file. Incremental and differential backups only update the Restore.env file; they do not create it. Incremental and differential backups cannot run without Restore.env.
The Restore.env file contains the following information:
- The storage group the database belongs to
- The paths for the database files from the time they were backed up
- The path to the database from the time it was restored
- The log files that were restored
When you perform a restore operation of an online backup of an Exchange database, the database is in an inconsistent state. To bring it to a consistent state, the system performs a hard recovery in which the Extensible Storage Engine (ESE) uses log and patch files to bring the database current to the time it was lost if all the files are available.
When you restore the Exchange data, the backup software replays the transaction logs to restore the data that has been saved since the last time the transaction logs were deleted. During the backup, check the Last Backup Set check box to indicate that all backups have been performed. Windows Backup will then replay the log files after the last backup is restored.
If you don't select Last Backup Set, you can run a hard recovery manually using the following command:
eseutil /cc path to directory containing the Restore.env file
Note: If you fail to run a hard recovery, you will not be able to mount the database after the restore operation.
Transaction logs in a directory may be deleted when a full storage group is restored. Remember that transaction logs are shared between all mailbox stores in the storage group. For this reason, when you restore a single mailbox store, you could lose some data in other stores. If possible, restore all mailbox stores in a storage group.
If you need to restore deleted Active Directory objects, perform an authoritative restore of those objects. An authoritative restore forces all domain controllers to use the restored data. A non-authoritative restore adds data to one domain controller, but the data might be overwritten by other domain controllers during Active Directory replication.

To perform a restore operation, use the following steps:

Dismount the database you wish to restore.
In the Backup utility, click the Restore tab.
Select the objects you wish to restore. (Note: When you work with an online backup, you don't see the actual database files and log files in the Backup program; you only see the logical names of stores and transaction logs.)
Select an option in the Restore files to list (by default, it is set to Original Location). Click Start Restore.
Enter the server name in the Restore to box by browsing to it or typing it. Also, enter a path in the Temporary location for log and patch files box. This temporary location should be different from the location where log and patch files are permanently stored. Also, you should have a temporary location for each database you wish to restore so that the Restore.env files for each operation do not overwrite one another.
After doing the full backup restore and all differential or incremental backup restores, select the Last Backup Set check box. This allows the system to perform a hard recovery. You can also select the Mount Database After Restore check box.
Enter the full path and file name of the backup file you want to restore in the Restore from backup file box by browsing to the file or typing in the information. Click OK.
Click OK when the restore process is complete.

A soft recovery is best performed by mounting any database in a storage group. Because the databases in a storage group share a single stream of log files, soft recovery occurs at the storage group level, not the individual database level. However, you may want to perform a soft recover manually under the conditions described in the table below.

Condition	Description
Recover a storage group that is missing a database	Use the following command under this condition: Eseutil /r enn /i The /i switch tells the Eseutil command to ignore missing databases. After the restore operation, you'll have to mount the database, which will be empty. Restore the old database to the recovery group, and use ExMerge to combine the two databases.
Recover a database "out of place" without affecting the other databases or the storage group's log files	To recover a database "out of place," move the database files you want to recover and the transaction log files you want to replay to an empty folder (this folder must not contain any other database files). Run the following command from that location: Eseutil /r enn /i /d The /d switch with no path designation overrides the database path in the log files. Run from the location where you placed the database files, the database files on the server are protected from this recovery process.

A soft recovery can be a complex process. To understand it fully, refer to the Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003 document on the Microsoft Web site.
It is always best to restore from a backup, but the occasion may arise when this is not possible. In such a case, you can attempt a hard repair. The hard repair runs through the database to find errors in system tables, attachment tables, damaged database pages, among other things. As it fixes damage, the likelihood of data loss is extremely high, so you should run this only as a last resort. To run a hard repair, use the following process:

Run Eseutil /p or Edbutil /d /r.
Defragment the database by running Eseutil /d.
Check the database consistency by running Isinteg -fix. Run the command until the summary report returns no errors.

Exchange Server Restore Facts

If the entire Exchange server fails and cannot be booted due to a hardware failure or configuration corruption, you can either restore or reinstall the server to correct the problem. The following table describes three methods you can use to recover from a failed server.

Method	Description
Restoring the Exchange Server	When you restore the Exchange server, you use existing backups to restore the operating system, Exchange, and the data to the same system. Use the following general process to restore the Exchange server: Use your latest backups to restore the entire computer. This will include the operating system and Exchange. Reapply service packs and updates. Restore the Exchange data.
Rebuilding the Exchange Server	When you rebuild a server, you reinstall a fresh copy of the operating system and Exchange, but configure the computer as if it were the original Exchange server. To rebuild the Exchange server: Install the operating system. Restore the system state data. Reinstall operating system service packs and hotfixes. Install Exchange using Setup.exe /disasterrecovery. This option re-installs Exchange but uses configuration information in Active Directory to configure the new install exactly the same as the failed server. Install Exchange service packs and hotfixes. Restore the Exchange data.
Using a Standby Recovery Server	A standby recovery server is a partially-configured server with the exact same hardware and with the operating system already installed. The process for using a standby server is similar to the process of rebuilding the server, except that the operating system is already installed. To rebuild using a standby server: Shut down the failed server and remove it from the network. Move the hard drives to the standby server. Connect the standby server to the network. Restore the system state data from the failed computer to the standby server. Reinstall operating system service packs and hotfixes. Install Exchange using Setup.exe /disasterrecovery. Install Exchange service packs and hotfixes. Restore the Exchange data.

Keep in mind the following recommendations for working with failed Exchange servers.

If possible, copy the Exchange data from the failed server. As the last step in the process, recopy the data to the restored or rebuilt server instead of restoring the data from backup. This gives you the latest version of the Exchange database.
If restoring the Exchange server does not work (if the restored server is still unstable), try reinstalling the server. By reinstalling, you get clean installs of the operating system and Exchange.
If the Exchange server is the only domain controller on your network, you will need to restore Active Directory before restoring or reinstalling Exchange. If the Exchange server is one of other domain controllers, make the server a domain controller prior to installing Exchange. Wait for Active Directory replication to replicate domain information to the restored server.
If you install Exchange without the /disasterrecovery switch, information in Active Directory for that server will be deleted. Using the /disasterrecovery switch retrieves the configuration information for that server object and reapplies it to that Exchange server.

External System Migration Facts

Migration is the process of moving mailboxes, public folder, and other content from an external messaging system (such as GroupWise or Lotus Notes) to Exchange. Depending on the size and complexity of the migration, you might be able to perform the migration in a single step, possibly over a weekend, or you might need a period of time where Exchange co-exists with the other messaging system. The following table describes the general process for migration.

Migration Type	Description
Single-phase migration	In a single-phase migration, information from the external system is moved all at once. Use a single-phase migration for small migrations that can be performed quickly. To perform a single-phase migration: Install Exchange and configure the organization. Run the Migration Wizard to connect to the external system and extract data about users, mailboxes, and other objects. During this step, you must connect to the external system using an account with privileges to the mailboxes to be migrated. Perform additional clean-up operations in Exchange. For example, you might need to merge duplicate user accounts or manually create objects that could not be migrated automatically. Decommission the other messaging system.
Multi-phase migration	Use a multi-phase migration if the implementation is too large or too complex to migrate all at once. During a multi-phase migration, you will have a period of coexistence where Exchange must interact with the external messaging system. To perform a multi-phase migration: Install Exchange with the connector that corresponds to the external messaging system. A connector is a special component that enables communication between the two messaging systems. Connectors support not only mail delivery between systems, but also directory synchronization. When using a connector, user, mailbox, and other information is contained in both Exchange and the other system. Exchange includes the following connectors: Connector for Lotus Notes (supporting versions 5 and 6) Connector for Novell GroupWise (supporting versions 4.x and 5.x) Calendar Connector In addition, there are third-party connectors which allow you to synchronize data with other messaging systems. Configure the connector to connect to the external system. As part of the configuration process, you identify how information will be migrated into Exchange. Exchange then synchronizes with the external messaging system. Install Outlook on client systems. Train users to use Outlook to access the external messaging system. According to your migration strategy, completely move data from the external system to Exchange. During this period, you will have a mix of data that exists on both systems. As necessary, manually create objects that were not synchronized automatically. When the migration of all data is complete, decommission the other messaging system.

Keep in mind the following facts about migration:

Connectors used for migration are added during Exchange install. You can select the required connectors during install, or rerun the installation to add the connector.
Use the Calendar Connector to synchronize GroupWise and Lotus Notes Calendars with Exchange.
When migrating from Novell GroupWise:
- The Exchange connector only supports GroupWise 4.x and 5.x. For GroupWise 6.x, use third-party migration tools.
- The Exchange server must have the Novell Client and the GroupWise Client installed. This allows the Exchange server to connect to the Novell system.
- The NetWare server must have the Novell GroupWise API Gateway installed and configured to connect with Exchange.
When migrating from Lotus Domino:
- On the Lotus Notes system,
  - Create a user ID (user account) that will be used by the Exchange connector.
  - Grant the Lotus user the appropriate permissions in Lotus to access mailboxes. You can have each Lotus user grant the administrator account access to the mailbox, or create a link to the Lotus database.
  - Identify Exchange as a foreign system.
- The Exchange server must have the Lotus Notes Client installed and be running the Lotus Notes Connector.
- Configure the Lotus Notes Connector with the server name, Notes INI file location, connector mailbox, and Notes or SMTP address space.
- Before performing the migration, stop the Lotus Connector. This prevents the connector from deleting user accounts on both systems during the migration.
For systems without a special connector, configure a regular SMTP or X.400 connector to establish communication. You will have to manually synchronize the directories on each system. For example, you can use the Exchange Migration Wizard to use LDAP to extract the data from the other system.
When using the Migration Wizard or connectors, be aware that not all data from the other systems can be migrated automatically. In most cases, you will need to manually create items on Exchange that provide the same functionality as non-migratable objects on the other system.

Upgrading to Exchange 2003

Keep in mind the following facts about upgrading to Exchange 2003:

You can upgrade directly from Exchange 2000 to Exchange 2003 in the following ways:
- Perform an in-place upgrade by running the Exchange 2003 setup program on the Exchange 2000 server.
- Perform a migration by installing Exchange 2003 on a new server, then moving mailboxes and public folders from the other Exchange server to the new server.
There is not an in-place upgrade method for upgrading from Exchange 5.5 to Exchange 2003. In this case, you will have to perform a migration. Migration from Exchange 5.5 is more complex than migrating from Exchange 2000.
The Exchange 2000 server must have service pack 3 (SP3) installed prior to the upgrade.
Exchange Server 2003 must be the same language version as Exchange 2000 Server.
You must upgrade any ADCs (Active Directory Connectors) to Exchange Server 2003 before upgrading the Exchange 2000 servers.
Certain services or features of Exchange Server 2003 do not function the same if the system was upgraded versus a new hardware installation.
- On a new install, IMAP, POP3, and NNTP virtual servers are disabled. With an upgrade, the virtual servers are enabled if they are enabled on the original system.
- If any of the following components are installed and still required on the Exchange 2000 Server computer you are going to upgrade, you must first move them to other severs and then remove them from the server being upgraded.
  - Instant Messaging Service
  - Microsoft Chat Server
  - Key Management Service
  - Microsoft Exchange Connector for Lotus cc:Mail
  - Microsoft Mail Connector
  - Mobile Information Server Exchange 2000 Event Source component
To select any additional components or customize the installation, wait until Setup completes and then run it again, adding components or customizing as necessary.
You must upgrade the front-end server before upgrading the corresponding back-end servers.

Exchange 5.5 Migration Facts

Because Exchange 5.5 does not support a direct upgrade to Exchange Server 2003, if you want to move from Exchange 5.5 to Exchange Server 2003, you will need to perform a migration. In addition, you can configure Exchange Server 2003 to coexist with an Exchange 5.5 implementation.
Note: You can perform an in-place upgrade of Exchange 5.5 to Exchange 2000, and then an in-place upgrade from Exchange 2000 to Exchange 2003. However, the processes outlined here are the preferred methods for migrating from Exchange 5.5 to Exchange 2003.
The following table lists the migration methods.

Migration Type	Description
Intra-organization (standard) migration	With an intra-organization migration, you add one or more Exchange Server 2003 servers to the existing Exchange 5.5 organization. During the migration, Exchange 5.5 and Exchange Server 2003 coexist in the same organization. To perform an intra-organization migration, complete the following steps: Add Active Directory to the existing network in one of the following ways: Install Active Directory on a new server. Use ADMT to clone data from the NT 4 domain. Upgrade the NT 4 Primary Domain Controller (PDC) to Active Directory. User accounts and other data are automatically migrated during the upgrade. Install and configure an Active Directory Connector (ADC) to connect the Exchange 5.5 organization to Active Directory. Install an Exchange Server 2003 server. During installation, join the server to the existing Exchange 5.5 organization. Use the Exchange Tasks Wizard to move mailboxes from Exchange 5.5 servers to Exchange Server 2003 servers. Move distribution lists, rehome custom recipients, and migrate public folders. Decommission the Exchange 5.5 servers. (Optional) Switch Exchange to native mode. Use Sidhist.vbs to remove the SID history from Active Directory objects. Note: This is the recommended method for migrating to Exchange 2003.
Inter-organization (external) migration	With an inter-organization migration, you create a new organization for the Exchange 2003 structure and migrate data from the Exchange 5.5 organization. To perform an inter-organization migration, complete the following steps: Install Active Directory. Install Exchange Server 2003 into a new organization (do not join the existing Exchange 5.5 organization). Use the Active Directory Migration Tool (ADMT) to clone users from the NT 4 domain into Active Directory. (Optional) Add an Active Directory Connector (ADC) to establish coexistence between the Exchange 5.5 organization and Active Directory. For long-term coexistence, configure a two-way inter-organizational connection agreements. To simply populate data from Exchange 5.5 to the Exchange 2003 organization, establish a one-way connection agreement. Note: The Exchange Server Migration Wizard does not migrate public folders, distribution lists, or custom recipients. Use an ADC to synchronize this information with Exchange 2003. Use the Exchange Server Migration Wizard to migrate data into the Exchange 2003 organization. Note: Make sure that Active Directory is in Windows 2000 native mode or higher before migrating mailboxes. Decommission the Exchange 5.5 and NT 4 network. Use an inter-organizational migration for small migrations and one-step migrations.
Long-term coexistence	You can have long-term coexistence between Exchange 5.5 and Exchange Server 2003. Simply perform the migration steps outlined above for either inter- or intra-organization migration. Move data from Exchange 5.5 to Exchange Server 2003 if desired, keeping necessary Exchange 5.5 servers intact. Note: For long-term coexistence, you will need to install an Active Directory Connector to synchronize data between the Exchange 5.5 servers and Active Directory.

The following table summarizes the tools you might use during an Exchange 5.5 migration.

Tool	Use to...
Active Directory Migration Tool (ADMT)	Use ADMT to clone (copy) NT 4 data into Active Directory. Note: You do not need to use ADMT when upgrading an NT 4 domain to Active Directory.
Exchange Tasks Wizard	Use the Exchange Tasks Wizard during an intra-organization migration to move mailboxes from an Exchange 5.5 server to an Exchange Server 2003 server.
Exchange Server Migration Wizard	Use the Migration Wizard during an inter-organization migration to export Exchange data from the Exchange 5.5 organization to Exchange 2003. Note: The Exchange Server Migration Wizard only moves mailboxes. It does not export distribution lists, custom recipients, or public folders.
Active Directory Connector (ADC) Tools	Install the Active Directory Connector (ADC) Tools prior to performing either migration. Configure an Active Directory Connector during the migration to establish communication between Exchange 5.5 and Exchange Server 2003 for coexistence. Configure an ADC to migrate distribution list, custom recipient, and public folder data from Exchange 5.5.
Object Rehome Tool	Download the object rehome tool from Microsoft to update distribution list and custom recipient distinguished names.
Sidhist.vbs	Run Sidhist.vbs following the migration to remove the SIDHistory attributes for objects in Active Directory.
PFMigrate	Use PFMigrate to rehome public folders.

Keep in mind the following facts about migrating from Exchange 5.5:

You cannot install Exchange Server 2003 on the same server that is running Exchange 5.5.
Before the migration, Active Directory must be running on Windows 2000 Server SP3 (or higher) or Windows Server 2003.
You must have at least one Exchange 5.5 server running SP3 (or higher) in each Exchange 5.5 site.
When running the Server Migration Wizard, choose to migrate security identifiers (SIDs).
- SIDs are used to match mailboxes to new accounts and to convert these accounts to mailbox-enabled user accounts.
- SID migration uses the SIDHistory attribute in Active Directory. To preserve SID history during user account migration, Active Directory must be running in Windows 2000 native mode or higher.
- If SID history is not preserved, or if the mailbox cannot be matched to an existing user account, the wizard creates a disabled user account and associates it with the mailbox.
Run the Server Migration Wizard in clone mode to preserve the offline folder store file in Outlook.
The Exchange Server Migration Wizard does not migrate public folders, distribution lists, or custom recipients. Use an ADC to synchronize this information with Exchange 2003.
Using the Migration Wizard, you can perform a two-step migration: export Exchange 5.5 data to .pst files, then import that file later into the Exchange 2003 organization.
In Exchange 5.5, you can have multiple mailboxes per user account. However, in Exchange Server 2003, you can only have a single primary mailbox for each user. Prior to the migration, use the Resource Mailbox Wizard in the ADC Tools to exclude these duplicate mailboxes from being matched to existing users.
You must create a connection agreement between each Exchange 5.5 site and Active Directory.

Note: You can also perform a migration from Exchange 2000 to Exchange 2003. To do this:

Install an Exchange Server 2003 server into the organization.
Move mailboxes and public folders from the Exchange 2000 server.
Decommission the Exchange 2000 server.

ADC Facts

An Active Directory Connector (ADC) establishes communication between an Exchange 5.5 site and Active Directory. Use an Active Directory Connector to transfer recipient information to Active Directory during a migration or to establish coexistence between Exchange 5.5 and Exchange Server 2003.
When you create an Active Directory Connector, you establish a connection agreement. Connection agreements are the links between the recipient containers in Exchange 5.5 and the OUs in Active Directory. You must create a connection agreement between each Exchange 5.5 site and Active Directory. Connection agreements can be one of three types:

In a one way agreement from Exchange 5.5 to the organization unit, the recipients are cloned and synchronized in the organizational unit.
In a one way agreement from the organization unit to Exchange 5.5, the recipients from the organizational unit are cloned and synchronized in Exchange 5.5.
A two-way replication agreement means that the replication is going both ways.

Note: Deletion of mailboxes after migration can be a source of trouble. If you delete a mailbox in Exchange 5.5, by default the user account in Active Directory is deleted. The reverse is true also, if you delete a user account in Active Directory the corresponding mailbox in Exchange 5.5 is deleted. This can especially be a problem if you create a test environment in which you are using real users and mailboxes. When you delete the test environment, users and mailboxes will be deleted. To resolve this problem, configure the connection agreement to not delete users when the corresponding mailbox is deleted.
When configuring a connection agreement, you specify the objects that will be synchronized by defining the agreement type. The following table describes the agreement types.

Agreement Type	Use to
Recipient Connection Agreement	Create a recipient agreement to synchronize for mailboxes, distribution lists, and custom recipients. You can choose the types of information to synchronize. Selecting Mailboxes links Exchange 5.5 mailboxes to Active Directory recipients. Selecting Distribution Lists creates a universal distribution group in Active Directory. Selecting Custom Recipients creates mail-enabled contacts in Active Directory.
Public Folder Connection Agreement	Create a public folder agreement to replicate public folder information in Active Directory. Public folder agreements are automatically two-way with deletion enabled. These settings cannot be changed. Note: Access to public folders in Exchange 5.5 is controlled through distribution lists. When you synchronize data with Active Directory, distribution lists are synchronized to universal distribution groups. When a public folder is first accessed, Active Directory converts the distribution group to a security group. However, this conversion will fail if Active Directory is running in Windows 2000 mixed mode because mixed mode does not support universal security groups. To prevent this problem and ensure proper functioning of public folder access, ensure that Active Directory is running in Windows 2000 native mode or is at a Windows Server 2003 functional level.
Configuration Connection Agreement	The configuration agreement is created automatically when you install an Exchange Server 2003 server into the site. The configuration connection agreement allows the configuration information to be shared between Exchange 5.5 and Exchange 2003. Also at the time of the Exchange 2003 installation a site replication service (SRS) is created in the Exchange 2003 Administrative Console. The SRS maintains its own database for replication with Exchange 5.5.

To create an Active Directory Connector, install the Active Directory Connector Services tools. Use the following tools to help in the migration process and to ensure that connectors are created properly.

Tool	Description
Tool Settings	Modify the tool settings to identify the Exchange 5.5 server you will connect to.
Data Collection	Run data collection to analyze the Exchange 5.5 organization. You must have proper permissions on the Exchange 5.5 site before collecting data. If this process does not complete, you will be unable to use the remaining wizards.
Resource Mailbox Wizard	Run the Resource Mailbox Wizard to prepare mailboxes in Exchange 5.5 for migration. In Exchange 5.5, a user may have multiple mailboxes. This is a problem if the user is the principle account for more than one mailbox. The migration will fail because Exchange 2003 cannot link these multiple mailboxes to the same user account. The Resource Mailbox Wizard looks for users with multiple mailboxes. The NTDSnomatch value is set on extra mailboxes. During the migration, mailboxes with this attribute are linked to a new disabled user account.
Connection Agreement Wizard	Use the Connection Agreement Wizard to help you establish connection agreements between Exchange 5.5 and Active Directory. Click the Verify button to check Active Directory synchronization with the Exchange 5.5 site.

Coexistence Methods

Long-term coexistence is essentially a migration without end, where at least part of the external system continues to function and is not decommissioned. Continued coexistence requires that you maintain multiple systems and may also require users to use multiple client applications. Although not the optimal choice, long-term coexistence might be required to support legacy applications or because of administrative policies at your organization.
The process for establishing coexistence is similar to the process used to migrate from one system to another, but without the moving of resources and decommissioning of servers. Configuring coexistence typically involves the following processes:

Establish connectivity between the two systems
Synchronize recipient databases
Synchronize calendaring information

Establishing Connectivity
When you establish connectivity between systems, you typically create a trusted means of communication that allows the two systems to exchange information beyond the simple sending and receiving of mail that happens between two mail servers on the Internet. In most cases, the connectivity must be bi-directional to allow the proper flow of information.
In Exchange, connectivity between systems is configured through a connector.

Connector Type	Description
Active Directory Connector	An Active Directory Connector (ADC) is used to establish connectivity between an Exchange 5.5 system and Active Directory. If you have Exchange 5.5 servers within your organization, you will need an Active Directory Connector to provide synchronization between the Exchange 5.5 database and Active Directory.
System-specific Connectors	Use mail system-specific connectors, such as X.400 connectors, Connector for Lotus Notes, or Connector for Novell GroupWise to establish connectivity with these systems. The Lotus and GroupWise connectors also include features that enable directory synchronization.
SMTP connector	Because all modern messaging systems use SMTP, you can use an SMTP connector to establish connectivity to other systems for which there is not a specific connector. For example, you use an SMTP connector to connect to all generic mail servers on the Internet. When you configure an SMTP connector for coexistence with other systems, you will typically configure the following settings: Define the address space of the other system. When configuring the SMTP connector for the entire Internet, use * as the address space. When configuring coexistence with another system, identify the SMTP domain of the other system. Configure the connector to use an e-mail server in the other system as a smart host. To allow the other system to relay through the Exchange server (if necessary), on the SMTP virtual server add the other system to the list of allowed hosts or configure authentication between the other system and the Exchange server. For example, if you configure an SMTP connector pointing to the abccorp.com domain using the mail.abccorp.com server as a smart host, all mail from your organization to that domain will be forwarded directly to the other mail server. Mail for other domains will use a different connector, and can have different forwarding rules. Note: The SMTP connector does not provide features for database synchronization.

Note: A routing group connector is used to establish connectivity between Exchange servers in the same organization but different routing groups. The routing group connector is not used to configure coexistence with other mail systems.
Synchronizing Recipient Databases
Synchronizing databases involves duplicating data that exists in one mail system into the directory or database of the other system. Depending on the implementation, this could be either a one-way or a two-way synchronization. For example, you might retrieve user account information from one directory and create corresponding contact objects in Active Directory, thereby making information about external recipients available in the Global Address List. (and the other way around).
Directory synchronization can be performed in one of the following ways:

Automatic synchronization uses specialized tools to retrieve data from other systems. When changes are made, those changes are updated in the other directory system automatically.
Manual synchronization must be done by adding information directly into Active Directory (such as creating contacts), or using tools to export and then import the data. With a manual method, a big concern is out of data (unsynchronized) information.
Semi-automatic synchronization uses special scripts or programming tools to export and import information. The import/export process must be manually initiated or scheduled to run periodically.

When synchronizing databases with Active Directory, you can use the following tools:

Tool	Description
Connectors	Custom connectors (such as the Lotus Notes or Novell GroupWise connector) provide automatic directory synchronization. Synchronizing the directories is as simple as installing and configuring the appropriate connector.
Microsoft Identity Integration Server (MIIS)	The Microsoft Identity Integration Server (MIIS) (previously called Microsoft Metadirectory Services (MMS)) is an automatic directory synchronization tool that can be used with a wide variety of directories. For Exchange, you can use the GAL management agent to pull information from the other directory and automatically create users, groups, and contacts that will appear in the Global Address List. MIIS also keeps object configuration information synchronized. Changes made in one system are automatically populated to the other system.
Exchange Server Migration Wizard	The Exchange Server Migration Wizard gives you a manual method of exporting and importing directory information. When you run the wizard, you specify the type of system you want to connect to, supply the necessary credentials, and the wizard then extracts relevant information from the other database system. You can then use the wizard to import the data into Active Directory. Directories supported by the Migration Wizard include: Other Exchange organizations Lotus Notes Novell GroupWise (versions 4.x and 5.x) LDAP-compliant directories IMAP4 servers
Csvde, Ldifde	Use Csvde or Ldifde to perform manual export and import of directory data.
Scripting and Programming APIs	You can build a custom database synchronization solution using programming tools and accessing the necessary Windows APIs or other programming interfaces to extract data, import data, and periodically refresh data.

Note: When directory replication occurs between systems, most solutions create contact objects in Active Directory for groups and distribution lists in the other system. This means that Exchange users will not be able to view group membership of the groups on the other system. In addition, when mail is sent to the contact, a single message is sent to the group on the other system. This system must then identify group membership and forward the message on to each group member.
Synchronizing Calendars
Calendar synchronization allows users of different systems to schedule meetings and check availability for other users. Calendar synchronization is done separately from recipient database synchronization. You can use the following methods for calendar synchronization:

Method	Description
Calendar Connector	The Exchange Calendar Connector provides calendar synchronization with supported calendaring systems such as those used by Lotus Notes or Novell GroupWise. The Calendar Connector works by retrieving calendaring information from the other system and putting it into a hidden public folder called SCHEDULE+ FREE BUSY. This folder is used by the Outlook client to find schedule and availability information.
Outlook Internet Free/Busy (IFB) Publishing	Using Outlook, you can publish your calendar information to a shared public folder. Users of other systems can then view this information through the public folder. When using Free/Busy publishing: Outlook must be configured for mail only. Calendar information is published using the IETF standard iCal. For this reason, calendaring information might be available to users of mail clients besides Outlook.
Custom Solution	You can also provide others with access to your calendar information using a custom Web publishing or scripting solution. With this method, you develop tools that pull calendar information from the SCHEDULE+ FREE BUSY folder and make it available through a Web page or other application.

Coexisting with Other Systems

The exact methods you use to establish connectivity and directory synchronization depends on the type of mail system that you need to integrate with. The following table describes the processes for coexistence with various systems.

Method	Description
Coexistence with Exchange 5.5 in the Same Organization	To coexist with an Exchange 5.5 organization, perform the first several steps of an intra-organization migration. Add Active Directory to the network, add an Active Directory Connector (ADC) to synchronize the Exchange 5.5 data with Active Directory, and install Exchange 2003 servers into the Exchange 5.5 organization.
Coexistence with Other Exchange Organizations	All Exchange servers in the same forest are in the same Exchange organization. If your network has multiple forests because of business requirements or security requirements, you might also need multiple Exchange organizations. Use the following methods to enable cross-forest coexistence: Dedicated Exchange Forest Exchange in Multiple Forests with Security Access Exchange in Multiple Forests without Security Access
Coexistence with Lotus or Novell Mail Systems	To provide long-term coexistence with Lotus Notes or Novell GroupWise, use the corresponding connector objects to establish connectivity, directory synchronization, and calendar synchronization. Note: For full synchronization, you must use both the mail-specific connector and the calendar connector. For example, to coexist with a Novell GroupWise system, add the Connector for Novell GroupWise and the Calendar Connector. Note: When coexisting with Lotus Notes, use an Exchange server to handle inbound mail from the Internet. If inbound mail goes first to the Lotus Notes server and then to Exchange, an additional domain will be appended to the return addresses from the Internet.
Coexistence with POP3 Mail Servers	You can configure your Exchange server to forward mail to a POP3 server that holds e-mail accounts for your users. You might need to establish coexistence during a period of migration from a POP3 server to Exchange, or to enable users of one department to continue using a POP3 server that is already configured. The following links describe two ways to establish coexistence with a Microsoft POP3 server. Coexistence with a Different Domain Coexistence with a Shared Domain
Coexistence with Other Systems	To establish coexistence with all other systems, use the following process. Create a connector pointing to the other system. Use an X.400 connector for X.400 systems, or an SMTP connector for all other systems. Configure the smart host setting to point to the other mail system. Configure the destination SMTP domain as the address space. Allow messages to be relayed to the listed domain To allow the other system to relay through your Exchange server, take one of the following actions: For the SMTP virtual server, add the other e-mail system to the list of allowed servers. Configure the other server to authenticate with the Exchange server. Keep the default SMTP virtual server setting of allowing authenticated systems to relay. Manually replicate data from the other system into Exchange. You can create contacts manually, or if possible export objects from the other system and import them into Active Directory using Csvde or Ldifde. Manually integrate calendar information. In many instances, you will have no good solution for calendar synchronization. One possibility is to manually export calendar information from the other system and publish it to a shared location so your Exchange users can reference it.

Removing an Exchange Server

To remove an Exchange server, use the Exchange setup program. Before running setup to remove Exchange, take the following actions:

Move all mailboxes on the server to another server.
Replicate all public folders to other servers. Remove public folder replicas from the server.
Rehome any Offline Address Book folders and the Schedule+ Free Busy folder to other servers.
If the server is the routing group master for a routing group that has other servers, move the master to another server. Be aware that the first server installed into a routing group is designated as the master.
Rehome the Recipient Update Service. By default, the first Exchange server installed hosts the recipient update service. Move this service to another server.
Create another Site Replication Service instance on another server. The Site Replication Service is used in a mixed Exchange 5.5/2000 or 2003 environment.
Remove the server as a bridgehead server for any connectors.

Before running the setup program to uninstall Exchange, you must have the following permissions:

Exchange Full Administrator permissions to the administrative group where the server exists.
Exchange Full Administrator permissions to the administrative group that holds the routing group where the server exists.
Exchange Full Administrator to the organization and local computer Administrator role to uninstall the last Exchange server in the organization.

Task	Minimum permissions
Exchange backups	Domain backup operator
Exchange restore operations	Full Exchange administrator
Windows backups	Local backup operator
Windows restore operations	Local administrator rights

MS Exchange 2003 ( Howto & Info )

SMTP Facts

SMTP Virtual Server Facts

Exchange Routing Facts

Routing Group and Connector Facts

Communication Troubleshooting Facts

Exchange Client Facts

Front-end Server Facts

Public Folder Facts

Public Folder Permissions

Public Folder Replication Facts

Exchange Firewall Ports

Common Internet Configurations

Securing Client Connections

S/MIME Facts

Message Filtering Facts

Auditing Exchange Servers

Server Management Tools

Establishing a Baseline

Optimization Facts

Troubleshooting Performance

Storage Design Facts

Windows Clustering Facts

Exchange Clustering Facts

Managing Exchange Clusters

Verifying Connectivity

Verifying Name Resolution

Verifying Active Directory

Backup Facts

Using VSS for Backup

Exchange Recovery Methods

Restore from Backup Facts

Exchange Server Restore Facts

External System Migration Facts

Upgrading to Exchange 2003

Exchange 5.5 Migration Facts

ADC Facts

Coexistence Methods

Coexisting with Other Systems

Removing an Exchange Server

No comments:

Post a Comment