Features of Exchange 2003

Active Directory Integration Scalable Database Architechture o Upto 16 tb per mailbox database and upto 20 mailbox database per server. Coexistance with earlier version of exchange Enhance Security Enhance Administrative tools for mailbox management Outlook Web Access Integrated Support for mobile devices Integration with Outlook 2003 High availability support for 8 node cluster Faster Deployment Overcome from 26-drive letter. Interoperate with multiple clients

What Features have been removed from Exchange 2003

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

New Features in Exchange 2003

Cached Exchange Mode in Outlook 2003 Kerberos authentication protocol for Outlook 2003 Synchronization Improvements for Outlook 2003 Outlook Performance Monitoring RPC over HTTP for Outlook 2003 OWA improvemens with two versions OWA Premium and OWA Basic

Mobile Service for Exchange Outlook Mobile Access Enhanced Recipient management with Tasks Wizards in System Manager Visibility to more message queues in Exchange 2003 Public Folder Migration with PFMigrate Mailbox Recovery Center Message Tracking Center Exchdump.exe utility Query based distribution groups Improved ability to restrict submission to Users and Distribution lists Enhance Exchange Features on Users Properties Moving mailboxes in Exchange System Manager Link State Improvement Virtual Address Space Improvement Changing X.400 (MTA) file location using system manager Changing SMTP root directory location using system manager Improved Virtual Memory Blocks Support upto 8 node cluster Improved dependencies hierarchy for exchange services Cross Forest collaboration Internet mail wizard for SMTP server Improved DSN (Delivery Status Notification) Diaganostic Logging and codes Improved Ability to Restrict Submissions to an SMTP Virtual Server Improved Ability to Restrict Relaying on an SMTP Virtual Server Shadow copy backup Recovery Storage Group New Exchange Server Deployment Tools for Public Folder New Exchange Server Deployment Tools for ADC Exchange Server 2003 Setup Improvements

Compatibility of Exchange with Operating System

W2K Member Windows 2003 W2K in W2K in Windows NT 4.0 Domain Domain 2003 Domain Exchange 2003 Exchange 2000 Exchange 5.5

???

Hardware Requirements
Intel Pentium or compatible 133 MHz or faster processor 256 MB of RAM recommended minimum; 128 MB supported minimum 500 MB of available disk space on the drive on which you install Exchange 200 MB of available disk space on the system drive CD-ROM drive VGA or higher-resolution monitor

File Format Requirements

To install Exchange Server 2003, disk partitions must be formatted for NTFS and not FAT. System Partition Partition that stores Exchange binaries Partitions containing transaction log files Partitions containing database files Partitions containing other Exchange files.

Exchange Server 2003 Setup Improvements

Identical schema files in ADC and Exchange In Exchange 2000, ADC schema files were a subset of the Exchange 2000 core schema files. In Exchange 2003, the schema files that are imported during the upgrade of Active Directory Connector are identical to the core Exchange Server 2003 schema; therefore, you only need to update the schema once. Exchange Setup does not require full organization permissions In Exchange 2000, the user account that was used to run Setup was required to have Exchange Full Administrator rights at the organization level. In Exchange 2003, although a user who has Exchange Full administrator rights at the organization level must install the first server in a domain, you can now install additional servers if you have Exchange Full Administrator rights at the administrative group level. Exchange Setup no longer contacts the schema FSMO role In Exchange 2000, the Setup or Update program contacted the schema Flexible Single Master Operations (FSMO) role each time it ran. In Exchange Server 2003, Setup does not attempt to contact the schema FSMO role. ChooseDC Switch in Setup Exchange 2003 Setup includes the new /ChooseDC switch. You can enter the fully qualified domain name of an Active Directory domain controller to force Setup to read and write all data from the specified domain controller. When installing multiple Exchange 2003 servers simultaneously, forcing each server to communicate with the same Active Directory domain controller ensures that replication latencies do not interfere with Setup and cause installation failures. Default permissions at the organization level are only stamped once Exchange 2003 Setup stamps default permissions on the Exchange Organization object once (during the first server installation or upgrade) and does not re-stamp permissions during subsequent installations. Previously, Exchange 2000 Setup re-stamped Exchange Organization permissions during each server installation. This action overwrote any custom changes to the permissions structure; for example, if you allowed all users to create top-level public folders, these permissions were removed. Warning message appears if Exchange Groups are moved, deleted, or renamed

Exchange 2003 Setup ensures that the Exchange Domain Servers and Exchange Enterprise Servers groups are intact. If the administrator moves, deletes, or renames these groups, Setup stops, and a warning message appears. Permissions to access mailboxes Exchange 2003 Setup locks down security on the database objects; therefore Exchange administrators cannot open other user's mailboxes. Outlook Mobile Access and Microsoft Exchange Server ActiveSync components installed by Setup By default, Exchange 2003 includes support for mobile devices. The services that enable these devices are called Outlook Mobile Access and Exchange ActiveSync. Previously, to use these services, you had to install Microsoft Mobile Information Server. Now, the built-in mobile device support in Exchange 2003 supersedes the Mobile Information Server product. Automatic installation of required Windows Server 2003 services on Microsoft Windows 2000 If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup automatically installs and enables .NET Framework and ASP.NET. Automatic configuration of Internet Information Services (IIS) 6.0 In Windows Server 2003, IIS 6.0 introduces a new "worker process isolation mode," which offers greater reliability and security to Web servers. Worker process isolation mode ensures that all of the authentication, authorization, Web application processes, and ISAPI extensions that are associated with a particular application are isolated from all other applications. To take advantage of these benefits, when you install Exchange Server 2003 on Windows Server 2003, Exchange Setup automatically sets IIS 6.0 to worker process isolation mode. Exchange Setup also enables certain ISAPI extensions. By default, during Windows Server 2003 installation, ISAPI extensions are not allowed to load. However, Exchange 2003 requires certain ISAPI extensions for features such as Microsoft Outlook Web Access, WebDAV, and Exchange Web Forms; therefore, Exchange 2003 enables the required ISAPI extensions during setup. No action is necessary; Exchange Setup automatically configures the ISAPI extensions. The IsapiRestrictionList metabase key controls the ISAPI extension behavior. Exchange Setup sets the metabase key appropriately so that the ISAPI extensions can load; however, if the key is modified after Exchange is installed, certain parts of Exchange may not function correctly. Automatic IIS 6.0 Configuration during Windows 2000 to Windows Server 2003 upgrade If you install Exchange 2003 on Windows 2000 and subsequently upgrade to Windows Server 2003, Exchange System Attendant automatically sets the IIS 6.0 mode to worker process isolation mode. Event Viewer will contain an event indicating that this mode change has occurred. After the upgrade, you may find that some of the ISAPI extensions for other applications do not function properly in worker process isolation mode. Although you can set the IIS 6.0 mode to "IIS 5 isolation mode" to ensure compatibility with your ISAPI extensions, it is recommended that you continue to run IIS 6.0 in worker process isolation mode; Exchange 2003 features such as Outlook Web Access, WebDAV, and Web forms, will not work in IIS 5 isolation mode. Installing Exchange System Management Tools Only To administer Exchange servers from a computer running Windows XP, Windows Server 2003, or Windows 2000 Server SP3, you can use Exchange Setup to install only Microsoft Exchange System Management Tools.

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

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

Microsoft Exchange Server 2003 - Migration Strategy

Introduction to Microsoft Exchange Server 2003 Migration Strategy
The golden rule for a successful migration is - set a clear goal. For example, 'Our goal is to install Exchange 2003 and migrate all mailboxes from Exchange 5.5 in 6 months. Of all Microsoft upgrades, Exchange is by far the most complex. The reasons that make an Exchange 2003 migration so difficult are, the sheer number of different components, coupled with need to keep the email flowing during the migration. It may surprise you when I say the key role for a successful Exchange 2003 migration is not a technical expert but experienced project manager.

Role of Active Directory in Exchange Migration

An important point to always keep in mind is that Exchange 2003 absolutely relies on Active Directory. This means that Exchange Server gets information about users either from Windows Server 2003 (best), or from Windows 2000. What Active Directory provides is integrated user authentication and mailbox security. Another way of looking at Active Directory is as a replacement for Exchange 5.5's Dir.edb. As well as integrating with logon security, Active Directory is designed around the object / property / attribute model. In practical terms, this means that each user object has Exchange properties such as mailbox. You probably realise that Active Directory holds user's password, logon id and group membership; also remember that when you install Exchange 2003, email address and mailbox are also properties of the user and not stored separately as they were in Exchange 5.5. In addition to creating users with their mailboxes, Active Directory is also your vehicle for building distribution groups and contacts. It is also Active Directory that provides the search mechanism so that users can locate recipients in the address book. When you install Exchange Server 2003 you need to be aware of the schema. We have seen that Active Directory holds definitions for the properties of the user object, for example, password, group membership and department. Now when you install Exchange the user's schema is extended to hold properties like mailbox, email address and mail server. Exchange 2003 can prepare Active Directory through the commands setup /forestprep and setup /domainprep. These setup switches add over 100 Exchange attributes to the schema.

Importance of naming
The first point on your migration checklist should be naming. What will be the name of your Microsoft Exchange 2003 organization? Is this the same name as the existing Exchange 5.5, or are you restructuring and creating a new organization? How does the Window Server 2003 domain name compare with the NT 4.0 domain name? Perhaps the most difficult naming system to master is DNS, nevertheless DNS is essential for locating Active Directory logon services, sites, and Global Catalog servers. The extra DNS factor with exchange is creating MX records so that SMTP can route mail to the correct server.

Phase one - Move user accounts from NT 4.0 and Dir.edb to Active Directory
The Exchange 2003 migration project will become easier when you divide the project into two distinct phases. The first phase is to get the directory information from Exchange 5.5 into Active Directory - preferably Windows Server 2003. Only when you have migrated that user account information should you consider moving the actual mailboxes with email to your new Exchange 2003 server.

Exchange Migration Tactics - ADC or ADMT

The ADC (Active Directory Connector) is a service that allows you to create 'agreements'. These agreements will dictate how the user information is transferred to Active Directory. Alternatively, use the ADMT (Active Directory Migration Tool) wizard to copy user information and 'paste' it into Windows Server 2003 Active Directory. The benefit of ADC is that you also migrate public folder information. However, ADMT gives better rollback because users will still be able to logon to NT 4.0. Active Directory Connector ADC is the service that replicates information between the Exchange Server 5.5 directory and Active Directory. Replicated information includes

mailboxes, custom recipients, and distribution lists. The ADC uses Connection Agreements to define individual configurations for replication. Two versions of the ADC exist; one for Windows 2003 and one for Exchange 2003. When you migrate, you need some way to move your directory objects from the Exchange Server 5.5 directory into Active Directory. Active Directory Connector (ADC) is the solution. The ADC is what will synchronize the Exchange Server 5.5 directory with Active Directory. This is done through the use of Connection Agreements. There are three types of Connection Agreements that the ADC for Exchange 2000 Server and later supports:

1. Recipient Connection Agreement (RCA), responsible for replication of

mailboxes, distribution lists, and Custom Recipient directory objects from the Exchange Server 5.5 directory to Active Directory and back. Again, this replicates directory objects only, so this does not have anything to do with the moving of actual mailbox content. Public Folder Connection Agreement (PFCA), responsible for replication of public folder directory objects between Exchange Server 5.5 and Active Directory. Public folder directory objects are used when sending an e-mail message to a public folder and when administering a folder, especially on Exchange Server 5.5. So again, this is not for replication of actual public folder content between servers. Configuration Connection Agreement (Config_CA), responsible for replication of organization and site configuration information such as servers and connectors.

2.

3.

Note:Always use the most recent version of the Exchange Server ADC and not a Microsoft Windows ADC, which was released on the Windows 2000 CD, because the Windows 2000 ADC is not capable of doing many things that the Exchange 2000 Server ADC can do and it has not been updated since its release.

Phase two - Move the accounts from Exchange 5.5 to Exchange 2003.
Now that the mailbox owner and security information has been added to Active Directory, you can turn your attention to moving the email stores from Exchange 5.5 to Exchange 2003. Unlike an Exchange 2000 migration, when you upgrade Exchange 5.5 you have to use the move mailbox strategy, an in-place upgrade is not an option.

Why ADC creates disabled Accounts during migration?

ADC creates disabled accounts during migration in following conditions: The ADC cannot find a user account in Active Directory that is associated with the Exchange Server 5.5 mailbox. The mailbox in Exchange Server 5.5 is marked as a resource mailbox. The user account in Active Directory that the ADC tried to match the mailbox with already has mail attributes. The legacyExchangeDN attribute of the user also does not match the Exchange Server 5.5 distinguished name of the mailbox that matched to the user. This issue may occur if you have multiple mailboxes associated with the same Windows NT account, or if some mail attributes were manually populated to the users in Active Directory. In this case, the ADC creates a new disabled user. The ADC creates these disabled users for the following reasons:

To make sure that all of the mailboxes in the Exchange Server 5.5 directory are represented in Active Directory, along with all of the mail attributes that are associated with the mailboxes. This ensures that the Exchange 2000 Global Address List is complete, even if the Windows NT migration to move all of the user accounts from Windows NT 4.0 to Active Directory is not 100 percent complete. To allow an administrator to move a user's mailbox from an Exchange Server 5.5 computer to an Exchange 2000 server, even if the user's logon account is not migrated to Active Directory yet and is still in a Windows NT 4.0 domain.

If you enable these disabled accounts, and then users use these accounts (without additional modification) to log on, issues will occur with public folders and delegation in Exchange. Enabling and Removing ADC-Created Disabled Accounts Microsoft does not recommend that you enable the disabled accounts that are generated by the ADC. However, if there is a critical business requirement that requires you to enable them, follow these instructions to enable and to use the ADC-created disabled accounts: Use a Windows NT migration tool to merge the SID of the Windows NT 4.0 account into the Active Directory account as the sIDHistory value to preserve the permissions. Enable the account. Remove the msExchMasterAccountSID attribute.

ExDeploy - from the Exchange 2003 Server CD

This wonderful wizard leads you through the nine steps needed for a successful upgrade from Exchange 5.5 to Exchange 2003. If you have not created the Active Directory Connection agreements (ADC), the wizard will even do that for you. It is also possible to use the same wizard to guide you through an upgrade from Exchange 2000 to Exchange 2003. (See Diagram) Note: ExDeploy is new in Exchange 2003 (not available for Exchange 2000). Check out the Exchange 2003 Server CD for ExDeploy

Summary of Exchange Migration Strategies

Break down your Exchange migration into stages. Stage one, transfer all the directory services information from NT 4.0 to Active Directory. Stage two, move the mailbox data from Dir.edb in Exchange 5.5, to Active Directory. Microsoft supply a wonderful tool called ExDeploy. Give this wizard a chance, you may be pleasantly surprised how ExDeploy guides you through each stage. My final advice is pay special attention to the names of your: Exchange organization, dns, and Active Directory domain.

Active Directory
The Windows 2000 directory service replaces the Security Accounts Manager (SAM) in Microsoft Windows NT version 4.0. Active Directory consists of a forest, domain(s), organization units, containers, and objects. Different classes of objects can be represented within Active Directory including users, groups, computers, printers, and applications. The use of Active Directory is governed by its schema.

Active Directory Services Interfaces ADSI

A directory service abstraction interface that allows programming languages those are compatible with the Component Object Model (COM), such as Visual Basic, VBScript, JavaScript, C, and C+ + to make common directory calls to an underlying directory service. ADSI providers include Lightweight Directory Access Protocol (LDAP), NDS, Bindery, and Windows NT (SAM). Programmers and system administrators normally use ADSI to automate or script the bulk manipulation of directory entries.

ADSI Edit
A Microsoft Management Console (MMC) snap-in used to view all objects in the directory (including schema and configuration information), modify objects, and set access control lists on objects.

Connection Agreement CA
The configuration of information to be replicated using the Active Directory Connector. This configuration information includes the servers that participate in the replication, which object classes (mailbox, custom recipient, distribution list, user, contact, and group) to replicate, containers and organizational units to use for object placement, and the activity time schedule.

Domain Mode Native and Mixed Mode

An Active Directory domain can be in either mixed mode or native mode. In mixed mode, the domain is restricted to limitations (such as 40,000 objects) imposed by the Windows NT 4.0 domain model. However, Windows 2000 domain controllers and Windows NT 4.0 backup domain controllers can seamlessly co-exist within the domain without problems. Switching to native mode, which is irreversible, allows the directory to scale up to millions of objects and overcome the constraints of the earlier SAM, but requires that all domain controllers be upgraded to Windows 2000. A domain in native mode allows for rich group creation and nesting, which is advantageous to Exchange 2000. Note that Windows NT 4.0 member servers can still exist within a native-mode domain. Additionally, clients do not have to be upgraded before the domain mode is switched.

Domain Name Services - DNS

A major standards-based protocol that allows clients and servers to resolve names into Internet Protocol (IP) addresses and vice versa. Windows 2000 extends this concept even further by supplying a Dynamic Domain Name System (DDNS) service that enables clients and servers to automatically register themselves in the database without needing administrators to manually define records.

Domain tree
Domain Tree is a collection of domains that have a contiguous namespace, such as microsoft.com, dog.microsoft.com and cat.microsoft.com. Domains within the forest that do not have the same hierarchical domain name are located in a different domain tree. A disjoint namespace is the term used to describe the relationship between different domain trees in the forest.

Global Catalog
A server that holds a complete replica of the configuration and schema naming contexts for the forest, a complete replica of the domain naming context in which the server is installed, and a partial replica of all other domains in the forest. The global catalog knows about every object in the forest and has representations for them in its directory, however, it may not know about all

attributes (such as job title and physical address) for objects in other domains. The attributes that are tagged for replication to the global catalog are assigned through the Active Directory Schema Manager Microsoft Management Console (MMC) snap-in. There is only one policy for global catalog attribute replication in the forest. A global catalog will listen on port 3268 for LDAP queries (that are global to the forest), and port 389, which standard domain controllers use (for local domain queries). A domain controller can be made into a global catalog (and vice versa) by selecting or deselecting a check box in the Active Directory Sites and Services MMC snap-in.

Schema
Schema is the metadata (data about data) that describes the use of objects within a given structure. In Active Directory, the schema governs the type of objects that can exist and the mandatory and optional attributes of each object. Windows 2000 Active Directory has an extensible schema that allows third parties to create their own object classes. Schemas also exist for other components such as the message transfer agent and information store in Exchange Server.

Forest (Enterprise)
Forest is a collection of domains and domain trees. The implicit name of the forest is the name of the first domain installed. All domain controllers within a forest share the same configuration and schema naming contexts. To join an existing forest, the Dcpromo utility is used. The first domain within the forest cannot be removed.

Site
Site a collection of IP subnets. All computers that are in the same site have high-speed connectivitylocal area network (LAN) speedswith one another. Unlike an Exchange site, an Active Directory site does not include a unit of namespace; for example, multiple sites may exist within a single domain, and conversely, a single site may span multiple domains.

Administrative Group
Its the administrative collection of servers running Exchange 2000 that can be administered as a single unit. An administration group can include zero or more policies, routing groups, public folder trees, monitors, servers, conferencing services, and chat networks. When security settings (permissions) are applied to an administration group, all child objects in the DS tree inherit the same Access Control Lists (ACLs) as the administration group node. Note that an administration group does not define the routing topology for messages; this is handled by routing groups.

Routing Groups
Exchange Server 2003 supports the concept of routing groups to control the message flow between Exchange Servers. Routing groups are groups of servers running Exchange Server 2003 that are connected over permanent highspeed network links. Within routing groups, Exchange Server always transfers messages over SMTP. There is one special Server called the Routing Group Master which is responsible for tracking and maintaining the routing information which is necessary for determining the best path for message delivery. The default Routing Group Master is the first server in the routing group. If you wish to transfer the Routing Group Master role you must do so manually in the Exchange System Manager.

Figure 5: Routing Groups

If your organization has more than one routing group, you must install a connector between the two or more routing groups. The preferred connector is the Routing Group Connector but you can also use a SMTP, or X.400, Connector. By default, all exchange server organizations include only a single routing group called First Routing Group. All servers in the organization are members of the First Routing Group, unless routing membership is modified by you as an exchange server administrator. You should plan to implement multiple routing groups when one or more of the following conditions occur: Network connections are slow or not permanent The network is unreliable or unstable Message transmission is complex and indirect, requiring multiple physical network hops Message transmission must be scheduled between different locations The routing group structure is created to prevent users from accessing public folder replicas

Routing Group Connector RGC

RGC is a connector in Exchange 2000 that connects routing groups to one another. An RGC is uni-directional and can have separate configuration properties (such as allowable message types over the connection). Routing Group Connectors use the concept of local and remote bridgeheads to dictate which servers in the routing groups can communicate over the link. The underlying message transport for an RGC is either Simple Mail Transfer Protocol (SMTP) or Remote Procedure Calls (RPC) and it uses link state information to route messages efficiently.

Routing service
A component in Exchange 2000 that builds link state information.

Routing Objects
Component Object Model (COM) objects that are used to program Exchanges routing engine behavior. These objects allow the creation and manipulation of process maps, which define the series of states to be tracked by the routing engine and the activities to be performed at each step. Routing objects are used primarily in workflow applications. Rendezvous Protocol (RVP) (Note that this name is preliminary). The Microsoft published protocol that is used between the MSN Messenger service and the Instant Messaging server that is implemented on Exchange 2000. RVP uses an extended subset of HTTP-DAV with an Extensible Markup Language (XML) payload to send subscriptions and notifications between Instant Messaging clients and servers.

Cluster: Nodes, Storage Device

Schema
The metadata (data about data) that describes how objects are used within a given structure. In relation to Exchange, this term may be used in the context of Active Directory, but it can also be used to describe the structure within the store or the MTA.

SMTP A major standards-based protocol that allows for the transfer of messages between different messaging servers. SMTP is defined under RFC821 and uses simple command verbs to facilitate message transport over TCP/IP port 25.

Site Replication Service SRS

Its actually the updated version of the Exchange Server 5.5 Knowledge Consistency Checker (KCC) that works in conjunction with (and is part of) the Exchange Site Replication Service to ensure that knowledge consistency of sites, administration groups and Active Directory domains is maintained when interoperating between Exchange 2000/ 2003 and Exchange 5.5. When changes are detected in either environment, the SCC (Site Consistency Checker) may adjust existing configuration connection agreements. The component of SRS are 1. Site Replication Service Application srsmain.exe 2. Site Consistency Checker (Runs as a part of srs.exe) 3. SRS database (srs.edb) SRS must also run LDAP in order to communicate with Active Directory. Because the Microsoft Windows Server 2003 operating system also uses LDAP and locks the well known LDAP port 389 for its own use, SRS defaults to using port 379 for its LDAP communication.

Online Backups
When Exchange Server 2003 performs an online backup, all services, including the Exchange store, continue to run normally throughout the backup process. This allows users to continue to use their mailboxes during a backup process, whether the backup is incremental, differential, or full. During a full online backup, the .edb, .stm, and .log files that comprise the Exchange store are backed up and checked for corruption at the file system level. Unreliable hardware, firmware, or disks can all cause file system corruption. The check verifies the checksums on each 4-kilobyte (KB) block or page in the database. If there is a checksum failure, backup aborts. Therefore, after an online backup is complete, you should check the Event Viewer to find out whether your Exchange store is corrupted. If you see a failed backup with a page read error event in Event Viewer, there may be a problem in the database.

Store
The generic name given to the storage subsystem on a server running Exchange. This term is used interchangeably to describe the Store.exe process and Exchange databases.

Storage group
A collection of Exchange databases on a server running Exchange 2003 that share the same Extensible Storage Engine (ESE) instance and transaction log. Individual databases within a storage group can be mounted and dismounted. Each server running Exchange 2003 can architecturally host up to 20 storage groups, although only four can be defined through the Exchange System Manager: 1. In Exchange Enterprise 2003 4 Storage Group. 2. Each Storage group can have 5 database.

Exchange Databases/ DB & STM files

Each Exchange database consists of two files .EDB and .STM. .EDB contains MAPI contents and .STM (streaming) contain non-MAPI contents. The default name for the first mailbox store is Priv1.edb and Priv1.stm. Similarly for Public Folder store it is Pub1.edb and Pub1.stm.

MDBEF
In Exchange 5.5 message are always written to the database in MS Datbabase Encapsulated Format (MDBEF). Even if the message in non-MDBEF format and needs to be written to the database, the Imail process converts it to MDBEF forrmat so that it can be written to the information store.

Mailbox Recovery
What happens when a user deletes some e-mails or you lose a mailbox or more through a hardware failure or a disaster like a fire or water damage? Exchange 2003 has some nice features to prevent damage from a disaster or to recover Mailbox items and mailboxes. Some of these features are: Deleted item Recovery in Outlook Mailbox Recovery through Mailbox Recovery Storage Group Mailbox Recovery through Keep Deleted Mailbox for XX days Mailbox Recovery Center Deleted item Recovery in Outlook If you delete an object in Outlook, it is usually moved to the deleted items container in Outlook. Be sure that you dont activate the deletion of Objects from the deleted items container when you close Outlook (you can configure this setting in Outlook under Options).

Important Files in Exchange Databases File

Priv.edb Priv.stm Pub.edb Pub.stm Dir.edb Edb.log Edbxxxxx.log

Use

Private information store, the location for all user mailboxes Streaming File Public information store, the location for all public and system folders Streaming File Directory store Current transaction log Old transaction logs, numbered (hexadecimal) from 00001 eg. Edb00006.log Res1.log and Res2.log Reserved transaction logs, used to flush transactions out of memory if disk space is exceeded Edb.chk Checkpoint file marking the last buffer that has been committed to a database Tmp.edb Temporary database file created when a database is compacted Tempdfrg.edb Temporary database file created when a database is compacted

Replaying Transaction Logs Basics

Some of the fundamental rules of transaction log file replay are: Preserve all transactional files before you do anything. You cannot replay log files from one database against a different one. You cannot replay log files unless all uncommitted log files from the time the database was last running are available. You cannot replay log files if the database files have been moved to a different file path location. You cannot replay log files if the checkpoint file points to the wrong log. You cannot replay log files if any database files for the storage group have been removed. Eseutil.exe command line parameters are not case sensitive. The minimum Eseutil.exe command line needed to run soft recovery is: ESEUTIL /r Enn If you do not specify any file paths on the command line, Eseutil.exe uses your current command prompt directory as the default for both log files and the checkpoint file. Database files do not have to be in the log file path. Use the /D switch to override the paths stored in the log files only when you are sure the paths in the log files are incorrect. If the checkpoint file is not present in the same path as the transaction logs, all log files are scanned during replay, rather than starting replay from the checkpoint log. You can copy an existing checkpoint file temporarily to the log file path. After soft recovery is complete, Exchange no longer uses this copy of the checkpoint file in normal database operation.

ESEUTIL Basics

Recovering while a Database is missing

If you want to begin recovery when a database is missing from the storage group, you can use the command:
ESEUTIL /r Enn /i

Recovery Storage Group

Although Exchange limits the number of ordinary storage groups on a server to four, the recovery storage group does not count toward this limit. You can create a recovery storage group on a server that already contains four storage groups. For best performance, place the recovery storage group on the same server as the original database that you are restoring. You can merge recovered data into a database from a recovery storage group database on a different server, but performance will be noticeably slower than it would be if both databases were on the same server. Critical properties that you must set when creating a recovery storage group are: 1. Name 2. Transaction log location 3. System Path Location

Dial Tone Database

The dial tone database supports your users while you recover the original database. The first time that users log on to their mailbox after this database is created, Exchange creates a new, empty mailbox for them. Although the users do not have access to their previous data, they can send and receive messages normally. How to create Dial tone Database 1. In Exchange system manager, stop all databases still running in the storage group. 2. Move or rename the files for the failed database (.edb and .stm files). 3. When this warning comes At least one of this store's database files is missing. Mounting this store will force the creation of an empty database. Do not take this action if you intend to restore an earlier backup. Are you sure you want to continue?
4.

Click Yes. Exchange generates a new database.

Defragmentation of Exchange Store

1. In Exchange system manager, stop all the exchange store which you want to defrag. 2. Goto Bin Directory

3. Type eseutil /d "c:\program files\exchsrvr\mdbdata\privl.edb

The output is shown above of ESEUTIL offline defragmentation. Note When you defragment an .edb database file, the associated .stm file is defragmented also. Be sure to defragment your database whenever you move users between servers or delete a lot of information. You can also know how much space can be saved by checking the event viewer for event ID 1221 message description contains the following text:
The database "storage_group\mailbox_store (server_name)" has nnn megabytes of free space after online defragmentation has terminated.

Verify the integrity of Exchange Store

Run command isinteg -s server01 -test allfoldertests and specify the store name.

Output of Isinteg SYMPTOMS in Exchange 2003 When the mailbox store database in Microsoft Exchange Server 2003 Standard Edition reaches the 16-gigabyte (GB) size limit, the mailbox store does not mount. Additionally, the following event IDs may be logged in the Application event log:
Event Type: Error Event Source: MSExchangeIS Event Category: General Event ID: 1112 Description: The database "Mailbox Store (Server Name)" has reached the maximum allowed size. Attempting to unmount the database. Event Type: Warning Event Source: ESE Event Category: Space Management Event ID: 445 Description: Information Store (3160) The database D:\Program Files\Exchsrvr\MDBDATA\priv1.edb has reached its maximum size of 16383 MB. If the database cannot be restarted, an offline defragmentation may be performed to reduce its size.

Note Although the description for event ID 445 states that the Priv1.edb file has reached a size of 16,383 megabytes (MB), this may not be true. Event ID 445 is triggered if the combined size of the Priv1.edb file and the Priv1.stm file reaches 16,383 MB. The Priv1.edb file by itself may be smaller than 16,383 MB.

System Attendant - (MAD.EXE)

One of the core Exchange 2000 services that performs miscellaneous functions (usually related to directory information) such as 1. Generation of address lists 2. Offline Address Books 3. Directory lookup facilities.

The Exchange System Attendant is a multi-faceted and sometimes mysterious service. To remove some of the mystery & hopefully provide a bit of clarity to MAD here are the cliff notes version of what it actually does. Initialization and Tasks 1. Binds to Domain Controller upon startup a. Uses ADSI to do a server-less binding to find a DC b. Temporarily binds to GC for tasks like proxy generation 2. Loads various Exchange components upon startup a. DSAccess, DS Proxy, DS2MB, etc... 3. Has various background tasks a. Example: verifies machine account is present in the Exchange Domain Servers Inventory of Functions in MAD 1. DSAccess (Directory Service Access) - dsaccess.dll a. Builds a list of available Domain Controllers (DCs) that will be used by Exchange b. proxies LDAP queries from multiple components to the AD and maintains results in cache for a better overall system performance c. Other components besides MAD can load & initialize DSAccess 2. DS2MB (Directory Service to Metabase Update Service) - ds2mb.dll a. Mainly replicates protocol settings from the active directory to metabase b. Also creates exchange application pool & adds Exchange virtual roots to application pool in upgrade scenarios to Windows 2003 to support IIS6 Dedicated App Mode 3. RUS (Recipient Update Service) - abv_dg.dll a. Proxy generation - Bases proxyAddresses attribute for users on recipient policies, calls MAD to evaluate recipient policies & generate proxies b. Address List - stamps showInAddressBook attribute on users/distribution lists 4. DSProxy (also known as DS referral) - dsproxy.dll a. Relays all "MAPI to DS" communication for older MAPI clients 5. Offline Address List - Oabgen.dll a. Set of address lists in files that are created and stored on an offline address list server 6. Free/Busy - madfb.dll a. Mad Free/Busy (MADFB) is used by OWA to publish free/busy b. Store extracts free/busy from clients calendar and sends messages to System Attendant mailbox c. MADFB picks up messages and publishes to free/busy public folder 7. Mailbox Manager - logic in MAD a. Used to enforce corporate message retention policies & manage information store size b. Mailbox Manager Task runs every 15 minutes to see if the schedule information indicates it needs to call the mailbox clean task 8. Monitoring - logic in MAD a. System Attendant monitors server resources based on an interval b. Updates the routing table via WMI based on current status 9. RPC-HTTP Polling - logic in MAD a. RPC-HTTP polling thread to configure FE & BE (added in exchange 2003 SP1)

DSProxy

The Directory Service Proxy (DSProxy) is the Exchange Server 2003 component that provides an address book service to Microsoft Outlook clients. DSProxy is implemented in DSProxy.dll. DSProxy has two functions: Emulate a MAPI address book service Proxy requests to an Active Directory server

DSProxy provides both proxy and referral services. MAPI clients running Outlook 2002 Service Release 1 and earlier versions use the proxy functionality because these clients were designed to use Exchange Server as its Directory Service. This was true for Microsoft Exchange Server from 4.0 to 5.5 but beginning with Exchange Server 2000, Microsoft Active Directory takes the part of the Exchange Directory services. Therefore, DSProxy emulates a directory service, so that earlier clients can function. Exchange Server 2003 server forwards the requests to Active Directory. Later versions of Outlook, such as Outlook 2000 with SR-2 and Outlook 2002/2003, are designed with the assumption that Exchange Server 2003 does not have its own directory service. After DSProxy refers one of these later clients to a global catalog server, the client communicates directly with Active Directory. DSProxy obtains its list of working global catalog servers from DSAccess. DSAccess handles only LDAP queries. However, DSProxy fully relies on DSAccess to provide global catalog failover support.

DSProxy Operations
DSProxy performs the following operations: It collects a list of working global catalog Servers from DSAccess and selects only global catalog Servers that are in the Server's local Active Directory site.

It proxies MAPI queries from earlier Outlook clients to the remaining global catalog Servers. The mechanism used to direct Outlook clients to one of the remaining global catalog Servers is a round robin mechanism. DSProxy initially runs single threaded and can support up to 512 client connections. DSProxy automatically creates an additional thread for every 512 client connections. Unlike DSAccess, DSProxy has no caching mechanism. Every MAPI query processed through DSProxy is sent to a Global Catalog Server.

DSAccess
Exchange 2003 services access information that is stored in Active Directory and write information to Active Directory. If this communication occurred directly between each service and Active Directory, Exchange 2003 could overwhelm an Active Directory domain controller with communication requests. DSAccess is the component which controls the interaction between Exchange requests and Active Directory. DSAccess is a shared API that is used by multiple components in Exchange 2003 to query Active Directory and obtain both configuration and recipient information. DSAccess is implemented in DSAccess.dll, which is loaded by both Exchange and non-Exchange components. The components are: System Attendant Message Transfer Agent (MTA) Microsoft Exchange Information Store Exchange Management Service Internet Information Services (IIS) Windows Management Instrumentation (WMI)

DSAccess discovers the Active Directory topology, detects domain controllers and Global Catalog servers, and maintains a list of valid directory servers that are suitable for use by Exchange components. In addition, DSAccess maintains a cache that is used to minimize the load on Active Directory by reducing the number of Lightweight Directory Access Protocol (LDAP) requests that individual components send to Active Directory servers. The DSAccess Cache is configurable through several Registry Keys.

RUS Recipient Update Service

The Exchange Recipient Update Service (RUS) is the Exchange component which is responsible for

Managing the Exchange Server Proxy E-Mail addresses and for creating and updating email addresses for Exchange Server recipients and Exchange core components.

There is one RUS service in every domain where Exchange is installed and one Exchange Recipient Update Service for the Enterprise Configuration (the whole Exchange Organization). Exchange Server 2003 communicates with directory servers to update recipient objects (such as mailbox-enabled user accounts and mail-enabled groups) with e-mail addresses, according to the recipient policies defined for the organization. To do this, Exchange Server 2003 uses Recipient Update Service, a component of System Attendant. Recipient Update Service creates and maintains Exchange Server 2003specific attribute values in Active Directory. If you create a mailbox for a user, Recipient Update Service automatically generates the user's SMTP address and any other proxy addresses that you defined for your recipients.

Exchange Server 2003 installs two instances of Recipient Update Service:

1. Enterprise configuration Recipient Update Service There is only one instance of this
Recipient Update Service in the organization, because the Enterprise Recipient Update Service is used to update the configuration directory partition, and there is only a single configuration directory partition shared by the entire forest. Domain Recipient Update Service You must have a Recipient Update Service for each domain that contains mailbox-enabled users.

2.

For each particular domain in a forest, Recipient Update Service associates one Exchange Server 2003 computer (on which Recipient Update Service runs) with one domain controller (on which the directory objects are updated). Only one Recipient Update Service can be associated with any directory server at any given time. Updating Recipient Objects The method that Recipient Update Service uses to perform a search is determined by the actions that an Exchange administrator takes in Exchange System Manager. For example, in Exchange System Manager, you can right-click a Recipient Update Service configuration object and select the Rebuild command to recalculate address list memberships and the recipient policy settings of all recipients in a domain at the next scheduled interval. You can also select the Update Now command to perform this processing immediately. Recipient Update Service searches the directory for objects to update in the following three ways: Update new and modified objects only. This is the default behavior that Recipient Update Service exhibits each time it searches for objects to update. This is also the default behavior that Recipient Update Service exhibits when you use Update Now, if you do not select the Rebuild option, and none of the policies were modified or applied. Recipient Update Service tracks the last change that occurred on the domain controller, against which Recipient Update Service is configured to run. Based on the schedule that is set on the Recipient Update Service object, Recipient Update Service periodically checks for objects that have been created or updated since it last checked.

The Update Now function in Exchange System Manager sets the msExchReplicateNow attribute to TRUE, and causes Recipient Update Service to temporarily ignore its schedule and immediately query for new changes and take appropriate action on those objects. After the Update Now process is finished, msExchReplicateNow is reset to FALSE.

 Update all objects When you select the Rebuild option in Exchange System Manager, you set the msExchDoFullReplication attribute on Recipient Update Service to TRUE. After msExchDoFullReplication is set to TRUE, the next time that Recipient Update Service starts, it looks at every object, instead of querying only for new objects. When the Rebuild process finishes, msExchDoFullReplication is reset to FALSE. Update objects that correspond to a specific recipient policy You can modify the filter on a policy (the purportedSearch attribute) to cause Recipient Update Service to take action beyond its default behavior. When you modify the filter on a policy, the policy can apply to a completely different set of users than those to whom it applied previously. Because of this, if the filter on a policy is modified, Recipient Update Service queries for every user who matches both the later filter and the earlier filter. This occurs the next time that Recipient Update Service is started by the schedule or by the Update Now command. Recipient Update Service runs against all users who match either filter and updates their msExchPoliciesIncluded attribute to reflect the filter that now applies. Recipient Update Service updates the proxy addresses on all users that match the corresponding policy filter.

DS2MB Directory Service to Metabase

The function of DS2MB is to replicate configuration information from Active Directory to the local IIS metabase. DS2MB is implemented as a process in DS2MB.dll and the primary function is to synchronize several Exchange configuration settings in Active Directory with its counterpart settings in the IIS metabase. The DS2MB is a unidirectional process. Only from Active Directory to the IIS Metabase. You can view the IIS Metabase with the Metabase Explorer from the IIS 6 Resource Kit and some other tools. The metabase update is a subprocess that is launched when the System Attendant is started. The operation of SMTP, POP3, IMAP4, Outlook Web Access and OMA are all dependent on the replication by DS2MB. DS2MB registers with the config domain controller after startup, enabling the config domain controller to notify DS2MB of any changes that are made to the Exchange configuration. This notification occurs within 15 seconds of the change.

Microsoft Exchange MTA Stacks service (EMSMTA.exe)

The Microsoft Exchange MTA Stacks service (MTA) routes messages through X.400 and gateway connectors to non-Exchange messaging systems. In a mixed environment with servers running Exchange Server 5.5 in the local routing group, the MTA is also used to transfer messages between Exchange Server 2003 and Exchange Server 5.5. This occurs because Exchange Server 5.5 MTAs communicate with each other in the local site directly through RPCs. Exchange Server 2003 must rely on this communication method for backward compatibility. The executable file of the Microsoft Exchange MTA Stacks service is EMSMTA.exe, which is located in the \Program Files\Exchsrvr\bin directory. This service depends on System Attendant

and maintains its own specific message queues outside the Exchange store in the \Program Files\Exchsrvr\Mtadata directory. The registry key is HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\MSExchangeMTA

Routing Engine (RESvc.dll)

The Exchange Routing Engine service provides topology and routing information to servers running Exchange Server 2003. The advanced queuing engine (AQE) within the SMTP transport subsystem uses this service to provide next-hop information when routing messages within the Exchange organization. The Exchange Routing Engine service depends on the IIS Admin service and runs within the Inetinfo.exe process. This service is implemented in a file called RESvc.dll, which is palced in the \Program Files\Exchsrvr\Bin directory. The registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc

IIS Admin service

The IIS Admin service (IIS Admin) manages the IIS Metabase and updates the registry for the following services: WWW service FTP service SMTP service POP3 service IMAP4 service NNTP service

The IIS Admin service also provides access to the IIS configuration information to other applications, such as to the metabase update service, which is an internal component of System Attendant. The registry key for the IIS Admin service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin. The IIS Admin service depends on the Remote Procedure Call (RPC) service and Security Accounts Manager (SAM) service.

PUBLIC FOLDERS
For the administrator, public folders are a separate database.

Figure 1
This screenshot shows the Exchange databases on a single Exchange 2003 Standard server. The priv1 database, composed of both an EDB and an STM file, contains the user mailboxes. The pub1 database contains the public folders. Both databases in Exchange 2000 and in Exchange 2003 up to SP2 had a limit of 16GB. In the fast moving Internet days, 16GB is not much. However, most mail accumulates in user mailboxes, leaving the public folder database pretty empty. Later on I will show how public folders can be better used to even this out, so you get a smaller mailbox database and more room to grow. Public Folders contain the same type of folders you can access using Outlook, and can hold mail, calendaring and task information. You can set security on these folders so that only specific people will have specific types of access to these folders.

Public folders can be created using Exchange System Manager or the Outlook client.

Figure 2

Outlook 2003 sort of hides the public folders, so you first have to access the Folder list, then on the right side, open the Public Folder List, All Public Folders and the select New Folder

Figure 3
Exchange System Manager can only create folders that hold mail items, such as your Inbox and Sent Items folders, while Outlook can also create other types of folders such as Calendar items.

Figure 4
You can also create Public Folders using Outlook Web Access.

Figure 5

Public Folders have two types of security mechanisms administration and client access. Public Folder Administration security can only be set by Exchange System Manager. It allows you to decide which of the Exchange administrators have the right to manage security for the public folder and administrate the database (also called information store).

Figure 7

In most cases, in a small to medium company you would mostly need to set client permissions and not administrative rights. These can be set by the Outlook client and Exchange System Manager, but not the Outlook Web Access client.

Figure 8

Figure 9

The above screenshots show the default security settings for Public Folders. The owner of a public folder is the user who created it and gets full control of the folder. Authenticated users (designated here as Default) are granted the right to add items and delete their own items and anonymous users can add items but not read them. When creating a new public folder that you want a user to administer, you can simply add the user to the permission list and change the permission level to Owner.

Figure 10 The owner would be able to create subfolders for the folder you created and set further permissions on it.

MX Record
As long as the mail server is using SMTP as the e-mail transfer mechanism we need to configure the MX Records for our domain. MX is an acronym for Mail eXchange. It specifies the name and relative preference of mail servers for the zone. MX is a DNS record used to define the host(s) willing to accept mail for a given domain. I.e. an MX record indicates which computer is responsible for handling the mail for a particular domain. Without proper MX Records for your domain, only internal e-mail will be delivered to your users. External e-mail from other mail servers in the world will not be able to reach your server simply because these foreign servers cannot tell to which server they need to "talk" (or open a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in preference order. If a host has three MX records, a mailer will try to deliver to all three before queuing the mail. MX Records must be in the following format: domain.com. IN MX 10 mail.domain.com.

The Preference field is relative to any other MX Record for the zone and can be on any value between 0 and 65535. Low values are more preferred. The preferred value is usually 10 but this is just a convention, not a thumb rule. Any number of MX Records may be defined. If the host is in the domain it requires an A Record. MX Records do not need to point to a host in the same zone, i.e. an MX Record can. point to an A Record that is listed in any zone on that DNS or any other DNS server When connecting your mail server to the Internet (or to another ex-organizational mailing system that uses SMTP) you must always make sure that the rest of the world can successfully resolve your domain's MX Record. Failing to do so will cause e-mail traffic not to be delivered to you. In order to properly configure your domain's MX Record you should contact your ISP (Internet Service Provider) or the party responsible for hosting your DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain Name) and IP address of your mail server. Make sure you know them.

FSMO (Flexible Single Master Operations) roles in Active Directory

In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:
1. 2. 3. 4. 5. Schema Master Domain naming master Infrastructure master RID Master PDC Emulator

1.

Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

2.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.

3.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain. Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

4.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain. Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.

5.

PDC Emulator:

The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage. The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner. In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions: Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator. Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.

 Account lockout is processed on the PDC emulator. Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator. The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients. This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment. At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

How to Transfer FSMO roles

You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can use one of the following three MMC snap-in tools: Active Directory Schema snap-in Active Directory Domains and Trusts snap-in Active Directory Users and Computers snap-in If a computer no longer exists, the role must be seized. To seize a role, use the Ntdsutil.exe utility. Transfer the Schema Master Role Use the Active Directory Schema Master snap-in to transfer the schema master role. Before you can use this snap-in, you must register the Schmmgmt.dll file. Register Schmmgmt.dll 1. Click Start, and then click Run. 2. Type regsvr32 schmmgmt.dll in the Open box, and then click OK. 3. Click OK when you receive the message that the operation succeeded.

Transfer the Schema Master Role

1. Click Start, click Run, type mmc in the Open box, and then click OK. 2. On the File, menu click Add/Remove Snap-in. 3. Click Add. 4. Click Active Directory Schema, click Add, click Close, and then click OK. 5. In the console tree, right-click Active Directory Schema, and then click Change Domain Controller. 6. Click Specify Name, type the name of the domain controller that will be the new role holder, and then click OK. 7. In the console tree, right-click Active Directory Schema, and then click Operations Master. 8. Click Change. 9. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the Domain Naming Master Role

1. Click Start, point to Administrative Tools, and then click Active Directory Domains and Trusts. 2. Right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller. NOTE: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer. 3. Do one of the following: In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK. -or In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK. 4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations Master. 5. Click Change. 6. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles
1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers. 2. Right-click Active Directory Users and Computers, and then click Connect to Domain Controller. NOTE: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer. 3. Do one of the following: In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK. -or In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Master. 5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and then click Change. 6. Click OK to confirm that you want to transfer the role, and then click Close.

Important IP Ports Used

20 21 FTP, File Transfer Protocol, data. FTP, File Transfer Protocol, control.

23 25 53 80 109 110 119 135 143 161 162 220 366 369 389 379 443 636 691 563 992 993 994 995 3268

Telnet. SMTP, Simple Mail Transfer Protocol. (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) - Domain Name System (DNS) to all DNS Servers listed in the front-end server's IP configuration. HTTP, HyperText Transfer Protocol. POP, Post Office Protocol, version 2. POP, Post Office Protocol, version 3. NNTP, Network News Transfer Protocol. Exchange 2003 RPC Applications uses TCP port 135 IMAP, Interactive Mail Access Protocol. SNMP, Simple Network Management Protocol. SNMP, Simple Network Management Protocol traps. IMAP, Interactive Mail Access Protocol, version 3. SMTP, Simple Mail Transfer Protocol. ODMR, On-Demand Mail Relay. rpc2portmap. LDAP, Lightweight Directory Access Protoco AND CLDAP, Connection-less Lightweight X.500 Directory Access Protocol. SRS in Exchange 2003 uses 379 for LDAP because 389 is locked by Windows Server for LDAP HTTPS, HTTP over SSL/TLS. For SSL authentication, the port that the Exchange Server computer listens Exchange Server uses 691 for Link State Table within the routing group NNTP over TLS/SSL (was snntp). telnet over TLS/SSL. imap4 over TLS/SSL. irc over TLS/SSL. pop3 over TLS/SSL (was spop3). (TCP) - LDAP to global catalog servers.

Communication between POP3 clients and Exchange Server computers

Exchange 5.0 supports POP3, a protocol used to retrieve messages from a mail server. In addition to POP3 mail clients like Internet Mail and News, Windows CE Inbox, and Internet Mail Service for Windows, clients such as Pegasus and Eudora Pro are often used to send and retrieve messages from the Exchange Server computer. This introduces a new angle to the discussion of the availability of TCP port access.

- Downloading and retrieving messages

POP3 client access to messages on an Exchange Server computer is regulated by the authentication method used. There are three such authentication methods. If Basic or Windows NT Challenge/Response authentication (Windows NTLM authentication) is used, downloading and retrieval of messages using a POP3 client requires access to TCP port 110. Exchange Server listens on port 110 for any incoming connection requests from POP3 clients for message download. If the SSL (Secure Sockets Layer) authentication method is used, the Exchange Server computer listens on port 995. Therefore, if you are designing the packet filtering requirements of a network that includes an Exchange installation, keep in mind the access to either TCP port 110 or TCP port 995 if POP3 is a supported protocol.

- Sending messages
When POP3 clients send messages, the Exchange Server computer is communicating with an SMTP (Simple Mail Transfer Protocol) host. This requires access to TCP port 25. The Internet Mail Connector and the Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail

Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports POP3 as defined in the RFC- 1734 and RFC- 1957 specifications

Communication between IMAP4 clients and Exchange Server computers

Exchange version 5.5 supports IMAP4, the Internet Message Access Protocol. IMAP4 is a superset of POP3 and therefore supports all its features and some additional ones. An example of an IMAP4 enhancement over POP3 is the ability to search messages for key words while the messages are still on the mail server. Users can then choose which messages to download to their local computer. IMAP4 also allows access to public folders and personal folders.

- Downloading and retrieving messages

The ports that IMAP4 clients use when accessing messages on an Exchange Server computer depend on the authentication method in use. With Basic or NTLM authentication and TCP, the IMAP4 server listens on TCP port 143 for any incoming connection requests from IMAP4 clients for message download and retrieval. If SSL authentication is used, however, the port on which the Exchange Server computer listens is TCP port 993. Router and firewall setups should therefore take into consideration the access to TCP port 143 or TCP port 993 when this protocol is a supported feature for messaging.

- Sending messages
As discussed above for POP3 clients sending messages, when IMAP4 clients send messages, the Exchange Server computer is communicating with an SMTP host. This requires access to TCP port 25. The Internet Mail Connector and Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports IMAP4 as defined in the RFC-2060 and RFC- 2061.

Communication between Exchange Server computers and LDAP clients

LDAP (Lightweight Directory Access Protocol) is a specification for client access to the Exchange Server directory service to provide address book functionality. It allows the client to connect to the directory and allows information retrieval, addition, and modification. LDAP was introduced in Exchange version 5.0. For the LDAP client to connect to the Exchange Server computer, the ports that need to be configured on the firewall are based purely on the authentication method in use. With Basic authentication, the Exchange Server computer listens on port 389. For SSL authentication, the port that the Exchange Server computer listens on is 636. Microsoft Exchange Server supports LDAP as defined in RFC-1777.

Communication between Exchange Server computers and NNTP clients

The Network News Transport Protocol (NNTP) is widely used to post, distribute, and retrieve USENET messages. Clients can access these newsgroups as Exchange public folders. NNTP clients need to connect to the Exchange Server computer via port 119. The proxy software or firewall should take this into consideration when NNTP is supported. Microsoft Exchange Server supports NNTP as defined in RFC-977. Communication between Exchange Client computers and Exchange Server computers

An Exchange Client computer on a LAN or WAN link uses remote procedure call (RPC) to communicate with an Exchange Server computer. The Exchange Server computer, an RPCbased application, uses TCP port 135, also referred to as the location service that helps RPC applications to query for the port number of a service. The Exchange Server computer monitors port 135 for client connections to the RPC endpoint mapper service. After a client connects to a socket, the Exchange Server computer allocates the client two random ports to use to communicate with the directory and the information store. The client does not communicate with other components of the Exchange Server computer. If security concerns for a network infrastructure require blocking of any ports other than the ones used, then the random assignment of ports for communication with the directory and the information store can become a roadblock. To avoid this, Exchange Server versions 4.0 and later allow you to statically allocate these ports. At this juncture, for successful communication between client and server, the firewall needs to be configured to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor. Back to the top Communication between two Exchange Server computers in the same site All intrasite communication between Exchange Server computers uses RPC. Consequently, access to TCP port 135 becomes an important variable in the ability of Exchange Server computers to communicate if they are separated using routers and firewalls. Communication between two Exchange Server computers within a site is between the two message transfer agents (MTAs) and the two directory services. No other components of the Exchange Server computers communicate directly. As discussed above in client to server communication, an Exchange Server computer monitors port 135 for connections to the RPC endpoint mapper service. When an initiating Exchange Server computer connects to a socket, the receiving Exchange Server computer assigns two random ports to use to communicate with the directory and the MTA. Already discussed above was the possibility of static allocation of a TCP port for the directory to listen and communicate on a specific port number. With the release of Exchange Server 4.0 Service Pack 4 and all releases of Exchange Server 5.0, a similar adjustment can be made for the MTA. The endpoint mapper will then relay the appropriate port number, so that further communication can be achieved by going to the port number specified. For establishing a static allocation of port for the MTA, refer to the latter part of Knowledge Base article 161931 (http://support.microsoft.com/kb/161931/EN-US/), "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This explains the use of the registry value "TCP/IP port for RPC listens". Consequently, for successful communication between two servers, the firewall needs to be configured to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor. For more information about the ramifications and guidelines for static port assignment of Exchange services, please see the following article in the Microsoft Knowledge Base: 180795 (http://support.microsoft.com/kb/180795/EN-US/) XADM: Intrasite Directory Replication Fails with Error 1720 Back to the top Communication between two Exchange Server computers in different sites

- Intersite link uses site connector (RPC) Most of the discussion on intersite communication via site connectors mirrors the situation of intrasite communication between Exchange Server computers. The only difference is that communication between Exchange Server computers installed in two different sites is only via the corresponding message transfer agents (MTAs). Although you continue to need the services of the RPC locator service and thereby port 135, the only adjustment you may need for static allocation of a port would be for the MTA. Again, refer to Knowledge Base article Q161931, "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This article discusses the use of the registry value "TCP/IP port for RPC listens". This feature is available with Exchange Server Service Pack 4 and all releases of Exchange Server 5.0. - Intersite link is an X.400 connector If the intersite link is an X.400 connector, then the communication between the two Exchange Server computers continues to be between corresponding MTAs only. However, RPC is not the means of such communication. Communication between the MTAs follows the RFC1006: ISO over TCP/IP. Consequently Exchange Server computers, by default, use TCP port 102 for all such communication between the MTAs. There is no need for TCP port 135 as far the Exchange communication is concerned, because no RPC traffic is involved. Exchange Server Service Pack 4 and all releases of Exchange Server 5.0 provide the ability to change this default port assignment of port 102. Article 161931 (http://support.microsoft.com/kb/161931/EN-US/), referred to above, discusses the use of the registry value "RFC1006 Port Number". In this setting, for successful communication between two servers, the firewall must be configured to allow TCP connections to TCP port 102 or the manually assigned replacement port. If you need to monitor traffic for analysis, these are the ports to monitor. IMPORTANT: If the port number for RFC1006 is changed from the default value of 102 on one server, then it is absolutely essential that all servers communicating via the X.400 connector incorporate this change. All MTAs must use the same port number.

Lightweight Directory Access Protocol LDAP

LDAP is a standards-based protocol that can be used to interact with conformant directory services. LDAP version 2.0 allows for reading the contents of a directory database, whereas LDAP version 3.0 (defined under RFC2251) allows users and applications to both read and write to a directory database. LDAP was developed by Tim Howes and the University of Michigan.

Bridge Head Server

Bridgehead is a nominated server that acts as a message transfer point between Exchange 2000 routing groups. This term can also refer to the computer hosting a directory replication connector.

Naming context
It is a self-contained section of a directory hierarchy that has its own properties, such as replication configuration and permissions structure. Active Directory includes the domain, configuration, and schema naming contexts. Exchange Server 5.5 also uses naming contexts; Organization, Address Book Views, Site, Configuration, and Schema.

Namespace
It is a logical collection of resources that can be managed as a single unit. Within Active Directory, a domain defines a namespace.

Security principal
It is a user who can log on to a domain and have access to network resources. In Active Directory, a user object is a security principal. A non-security principal is an object represented in Active Directory that cannot access resources within the enterprise. User Principal Name UPN A multi-valued attribute of each user object that the system administrator can set. A UPN allows the underlying domain structure and complexity to be hidden from users; for example, although 50 domains may exist within a forest, users would seamlessly log on as if they were in the same domain. For consistency purposes, system administrators can make the UPN and users SMTP address the same. A user can log on to Active Directory through a number of different methods: a. By specifying the user name and domain name b. By using the convention of username@domain-name in the user box c. By using his or her UPN, such as e-mailalias@microsoft.com

How message Flows

A. Within the same server
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Clients submit the message Goes to Information Store Message passed Precategorization queue Message Categorizer Post Categorizer Routing Engine Domain Mapping Table Local Delivery Queue Exchange Store Driver Information Store Client receive the message

B. Within the same Routing Group

1. 2. 3. 4. 5. 6. 7. 8. Clients submit the message Goes to Information Store Message passed Precategorization queue Message Categorizer Post Categorizer Routing Engine Submitted to the Domain Mapping Table Outgoing SMTP message Queue

9. The sending server looks up the recipients mailbox in Active Directory, conducts a DNS lookup for the mail exchanger MX record associated with the destination server on which recipients mailbox is stored. 10. TCP port 25 Connection to desination server. 11. Message transmitted to destination. 12. Exchange Store Driver 13. Information Store 14. Client receive the message

C. To other Routing Group

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Clients submit the message Goes to Information Store Message passed Precategorization queue Message Categorizer Post Categorizer Routing Engine Creates a Outgoing SMTP message Queue Routing Group Information is gathered from the Configuration Naming Partition of Active Directory. Link State Information is Consulted to determine the best routing path. Message is passed to BHS ( Bridge Head Server) over TCP port 25 BHS pass the message to desination routing group BHS over TCP port 25. BHS of another routing group passes the message vita SMTP service and placed into NTFS queue. Message is taken out from the queue by the AQE (Advance Queing Engine) and associated with the recipients Inbox.

D. To Foreign Domain
1. 2. 3. 4. 5. 6. 7. 8. Clients submit the message Goes to Information Store Message passed Precategorization queue Message Categorizer Post Categorizer Routing Engine Creates a Outgoing SMTP message Queue SMTP Service reads out the message of this queue and sends it tover TCP port 25 to SMTP server. 9. Delivered to Foreign Domain.

Figure 4.2 Sending messages from Exchange 2003 to a remote SMTP host

Another look of Mail Flow

Figure 4.3 Receiving messages from a remote SMTP host

Information Store (Store.exe) The Microsoft Exchange Server Information Store (Store.exe) is the end point for e-mails sent to users on this server. It is also the start point for e-mails which are sent by MAPI clients, like Microsoft Outlook 2003, which directly connect to the MSExchangeIS.

Exchange InterProcess Communication (EXIPC) EXIPC (formerly known as Epoxy)

A queuing layer that allows the Internet Information Server (IIS) and store processes (Inetinfo.exe and Store.exe) to shuttle data back and forth very quickly. This is required to achieve the best possible performance between the protocols and database services on a server running Exchange 2000. Conventional applications require the processor to switch contexts when transferring data between two processes. Exchange Server 5.5 incorporated protocols such as Network News Transfer Protocol (NNTP), Post Office Protocol 3 (POP3), and Internet Messaging Access Protocol (IMAP) directly into the Store.exe process, so data transfer was very efficient. The Exchange 2000 architecture separates the protocols from the database for ease of management and to support future architectures.

EXIPC is responsible for Data Transfer between Internet Information Server 6.0 (IIS) and the Microsoft Exchange Server Information Store (MSExchangeIS). EXIPC provides a layered service between both components to achieve the best possible performance between IIS

dependant components and the Exchange databases. As you might know, all Internet Client Access Protocols like HTTP/S, SMTP, POP3 and IMAP4 are configured and managed by IIS with some exceptions.

Figure 2: EXIPC Layer This interaction allows Exchange to be in a FrontEnd, and BackEnd, Server scenario. Through Virtual Servers, multiple configurations of the same protocol can exist on a single Exchange Server

Advanced Queuing Engine (AQE)

The Advanced Queuing Engine (AQE) is responsible for creating and managing message queues for e-mail delivery. When AQE receives a Simple Mail Transfer Protocol (SMTP) mailmsg object, this object will be forwarded to the Message Categorizer. The Advanced Queuing Engine then queues the Mailmsg object for message delivery based on the Routing information provided by the Routing Engine process of Exchange Server 2003. The Message Categorizer is part of the Advanced Queuing Engine and is responsible for address resolution on every Mailmsg object that flows through the AQE. The Message Categorizer is

implemented as an Event Sink. The Message Categorizer is also responsible for splitting messages into RTF or MAPI.

Routing Engine
The Exchange Routing Engine uses Link State information for e-mail routing. The Routing Engine will forward this information to the Advanced Queuing Engine. Please note: The SMTP Stack from Windows Server 2003 will be extended through the Exchange Server installation process with several enhancements. One of these enhancements is the implementation of the XLINKSTATE protocol. The Routing Engine creates and maintains the Link State information for every Exchange Server and is also responsible for routing the messages to inbound or outbound destinations.

SMTP Service
The SMTP Service processes incoming traffic from any SMTP host. SMTP is also used in most communications between Exchange Servers (except Exchange 5.x Servers which use RPC for message transferring). SMTP is also responsible for some advanced Exchange Server functions like Message Journaling. During the Exchange installation, the built in SMTP Serivce from Windows Server 2003 will be extended with several new functions. Some of the Enhancements are: Moving the Message Queue Directories to the Exchange installation Directory Providing support for the LSA (Link State Algorithm) in SMTP Moving SMTP Messaging from IIS to the Exchange System Manager

Because understanding the e-mail message flow is important, I will list some high level steps in the message flow: MAPI client sends a message to a remote recipient Information Store (Store.exe) receives the message The created MailMsg object is forwarded to the Advanced Queue Engine (AQE) The Message Categorizer from the AQE processes the MailMsg object and splits it into MIME or RTF as necessary The Message Categorizer expands groups and checks defined Message limits on Exchange The MailMsg object is then transferred to the Remote Destination Domain within the AQE The AQE passes the destination address to the Exchange Routing Engine SMTP initiates an SMTP session with the remote SMTP host After the SMTP session with the remote host has been established, the information store retrieves the body of the message and converts the message as necessary SMTP sends the Message from the Queue to the Remote Host

The following Exchange Features require the use of SMTP: Intra Server Message Delivery Inter Server Message Delivery Message Delivery to the Internet Exchange of Routing Information

Intra Server Message Delivery SMTP will be used for Intra Server Message Delivery for several components like Message Journaling and Message categorization. Exchange Servers in the same Routing Group use SMTP to communicate with each other. Message delivery to the Internet SMTP is often used to deliver e-mail to other exchange organizations or other messaging systems. Exchange Server 2003 can use the Virtual SMTP Server to deliver messages, or one or more Exchange SMTP Connectors or Routing Group Connectors. Exchange of Routing Information SMTP is also used to exchange Link State information between routing groups Relaying SMTP Relaying occurs when one SMTP host forwards e-mail to another SMTP host. Open SMTP relaying occurs when the SMTP host accepts messages from recipients outside the organization and forwards the messages to other recipients that are also outside the organization.

Figure 4: Relaying
If the Exchange Server allows everyone without authentication to deliver messages, the server is called an Open Relay. Open Relays can be used to send UCE (Unsolicited Commercial E-Mail). By default Exchange Server 200x is not an open relay. The following steps describe the process: The unauthorized user sends an e-mail message to the SMTP Server and addresses multiple recipients in the message. The recipients in the e-mail are in domains external to the Exchange Server's Messaging Organization. The Exchange Server accepts the Message. After Exchange has accepted the message, Exchange delivers this message to an outside SMTP host because there is no match in the recipient policies in the exchange organization.

Mail Flow Troubleshooting

Queues - If you are looking for e-mail messages which were not delivered to their recipients,
one of the first places to look to see where the Message has gone is the Queue Viewer. You can find the Queue Viewer in the Exchange System Manager directly under the Server Node. There are several Queues of interest and you should have a look at the state of the Queues and the number of messages in the Queue. If there are any messages in the Queue, you can select the Queue and you will see more information about possible problems in the info pane. If you right click the Queue you can force a connection if the problem is only temporarily.

DSN messages pending submission This folder contains Delivery Status Notifications awaiting delivery. Its primarily used for NDRs Non Delivery Reports. Failed message retry queue Contains outbound messages which couldnt be delivered to their destination but will be given another attempt. Local delivery Contains inbound messages for delivery to mailboxes on the Exchange server. Messages awaiting directory lookup Contains inbound messages awaiting recipient lookup in Active Directory. Messages pending submission Contains messages accepted by the SMTP virtual server, but havent yet been processed. Messages queued for deferred delivery Contains messages queued for deferred delivery (later time). Messages waiting to be routed Contains outbound SMTP/X400 messages still waiting to be routed to their destination server, when it has been determined the message will be sent.

Figure 1: Queue Viewer

For Troubleshooting reasons it is also possible to Stop all Outbound Mail if you click the Symbol in the Queue viewer. Please note that in the picture above Outgoing Mail has already been stopped. Outbound e-mail delivery was stopped for the purposes of this article so that some Messages in the Queues can be easily shown.

Message Tracking Center

One of the fundamental settings that every Exchange Server should have enabled is the Message Tracking option. The Message Tracking option enables the logging of every e-mail message and, if enabled, for the message subject. You should enable message subject tracking only on low utilized Servers. Message subject logging can also be problematic in Data Security, so please speak with your legal department before implementing this feature.

Figure 2: Enabling Message Tracking

After the Message Tracking feature has been enabled, the Message Tracking Feature can be used in the Exchange System Manager to find messages sent to recipients.

Figure 3: Message Tracking Center

If an e-mail message is selected, the message can be clicked in order to see the message delivery status details.

Figure 4: Message History

As can be seen in the picture above, the message was Submitted from Store, delivered to the AQE, submitted to the Categorizer, Queued for Routing and Queued for Remote Delivery. For an explanation of these terms read the first article about Exchange message flow.

SMTP Logging
With Exchange Server 2003 it is possible to use extended SMTP Logging for troubleshooting purposes. If SMTP Logging is enabled, Exchange will write every outgoing mail through SMTP in a special logfile located by default in \Windows\System32\Logfiles\SMTPSVC1 where SVC1 is the first Virtual SMTP Server. You must enable this feature in the Exchange System Manager under the potocol container from the Exchange Server object.

Figure 5: SMTP Logging

After enabling this feature, the generated logfile can be opened and the detailed steps are shown in the SMTP connection process. For better viewing and analyzing, it is possible to export the logfile into Microsoft Excel. With Microsoft Excel the logfile can be formatted so that it is easier to analyze its content.

Figure 6: SMTP Logfile

One other troubleshooting helper is the Diagnostic Logging of Exchange Server 2003. Diagnostic Logging sets the details that are logged in the Event Viewer for specific Exchange components to a higher level, so more information will be logged in the Event Viewer Application Log . Diagnostic Logging should only be enabled when troubleshooting specific problems because Diagnostic Logging quickly fills the Event Log. The Logging Level can be set from None to Maximum in the GUI but there is also a Registry Key for setting the Logging Level to Level 7 for SMTP Logging purposes.

Diagnostic Logging must be enabled in the Exchange System Manager under the Exchange Server object. After enabling the Diagnostic Logging feature the Event Viewer can be analyzed for specific problems.

Figure 7: Diagnostic Logging

Message Categorizer
Message Caterorizer retriews attributes from the active directory and it apply those attributes to message. For example: It checks size limits for incoming as well as outgoing messages, check delivery restrictions, forwarding specifications, any restrictions settings, adding disclaimer, running an antivirus program.

Conferencing Management Service CMS

The network service that coordinates the booking of virtual resources for online meetings in the Exchange Conference Service. Each site (not domain) normally has an active Conferencing Management Service to allow fast connection for data conferencing users.

Configuration Connection Agreement ConfigCA

A special Connection Agreement implemented as part of the Active Directory Connector that replicates configuration naming context data from downlevel Exchange 5.x sites to administration groups in Active Directory and vice versa. ConfigCAs work in conjunction with the Site Replication Service.

Connection Agreement
It is the configuration of information to replicate using the Active Directory Connector. Configuration information includes the servers that participate in the replication; which object classes (mailbox, custom recipient, distribution list and user, contact, and group) to replicate; containers and organization units to use for object placement; and the activity time schedule.

Distributed Authoring and Versioning DAV (also known as HTTP-DAV and Web-DAV)
Its an extension to the Hypertext Transfer Protocol 1.1 (HTTP/1.1) that allows for the manipulation (reading and writing) of objects and attributes on a Web server. Exchange 2000 natively supports WebDAV. Although not specifically designed for the purpose, DAV allows for the control of data using a filing system-like protocol. DAV commands include Lock, Unlock, Propfind and Proppatch.

Exchange Conferencing Services ECS

ECS is a service that allows users to meet in virtual rooms on a server running Exchange. Exchange Conferencing Services defines the use of a Conferencing Management Service to coordinate the room bookings and a T.120 Multipoint Control Unit (MCU) for the actual connection of clients to a conferencing session.

Event sink
It is a piece of code that is activated by a defined trigger, such as the reception of a new message. The code is normally written in any COM-compatible programming language such as Visual Basic, VBScript, JavaScript, C, or C++. Exchange 2000 supports the following event sinks: Transport Protocol Store Event sinks on the store can be synchronous (code executes as the event is triggered) or asynchronous (code executes sometime after the event).

Exchange Virtual Server EVS

When clustering, you allocate different resources (such as storage groups) to an EVS. Upon node failure, an EVS can be moved from the failed node to one of the remaining nodes.

Extensible Storage Engine ESE (also known as JET)

Formerly known as Joint Engine Technologies (JET), the ESE is a method that defines a very low-level Application Programming Interface (API) to the underlying database structures in Exchange Server. Other databases, such as the Active Directory database (Ntds.dit), also use ESE. Exchange 2000 uses ESE98, whereas Exchange 5.5 and Active Directory use the older ESE97 interface.

C:\Program Files/Exchsrvr/BIN/>ESEUTIL /? Microsoft(R) Exchange Server(TM) Database Utilities<BR/> Version 6.0<BR/> Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. DESCRIPTION: Maintenance utilities for Microsoft(R) Exchange Server databases. MODES OF OPERATION: Defragmentation: ESEUTIL /d <database name> [options] Recovery: ESEUTIL /r [options] Integrity: ESEUTIL /g <database name [options] File Dump: ESEUTIL /m[mode-modifier] <filename> Repair: ESEUTIL /p <database name [options] Restore: ESEUTIL /c[mode-modifier] <path name> [options] <<<<< Press a key for more help >>>>> D=Defragmentation, R=Recovery, G=Integrity, M=File Dump, P=Repair, C=Restore => DEFRAGMENTATION/COMPACTION: DESCRIPTION: Performs off-line compaction of a database. SYNTAX: ESEUTIL /d <database name> [options] PARAMETERS: <database name> - filename of database to compact OPTIONS: zero or more of the following switches, separated by a space: /b<db> - make backup copy under the specified name /t<db> - set temp. database name default: TEMPDFRG.EDB) /s<file> - set streaming file name (default: NONE) /f<file> - set temp. streaming file name (default: TEMPDFRG.STM) /p - preserve temporary database (i.e., don't instate) /o - suppress logo /i - do not defragment streaming file NOTES: 1) If instating is disabled (i.e., /p), the original database is preserved uncompacted, and the temporary database will contain the defragmented version of the database. RECOVERY: DESCRIPTION: Performs recovery, bringing all databases to a consistent state. SYNTAX: ESEUTIL /r (3 character logfile base name)[options] OPTIONS: zero or more of the following switches, separated by a space: /l<path> - location of log files (default: current directory) /s<path> - location of system files (e.g., checkpoint file) (default: current directory) /i - ignore mismatched/missing database attachments /o - suppress logo INTEGRITY: DESCRIPTION: Verifies integrity of a database. SYNTAX: ESEUTIL /g <database name> [options] PARAMETERS: <database name> - filename of database to verify OPTIONS: zero or more of the following switches, separated by a space: /t<db> - set temp. database name (default:TEMPINTEG704.EDB)

/s<file> - set streaming file name (default: NONE) /f<name> - set prefix to user for name of report files (default: <I>database</I>.integ.raw) /o - suppress logo NOTES: 1) The consistency-checker performs no recovery and always assumes that the database is in a consistent state, returning an error if this is not the case. FILE DUMP: DESCRIPTION: Generates formatted output of various database file types. SYNTAX: ESEUTIL /m<mode-modifier> <filename> [options] PARAMETERS: <mode-modifier> - an optional letter designating the type of file dump to perform. Valid values are: h - dump database header (default) k - dump checkpoint file l - dump log file or set of logs m - dump meta-data s - dump space usage <filename> - name of file to dump. The type of the specified file should match the dump type being requested. (eg. if using /mh, then <filename> must be the name of a database. OPTIONS: zero or more of the following switches, separated by a space: /v - verbose<BR/> /s<file> - set streaming file name (default: NONE) /t <table> - dump nodes for a certain table <dump modes mode only> REPAIR: DESCRIPTION: Repairs a corrupted or damaged database. SYNTAX: ESEUTIL /p <database name> [options] PARAMETERS: <database name> - filename of database to repair OPTIONS: zero or more of the following switches, separated by a space: /s<file> - set streaming file name (default: NONE) /t<db> - set temp. database name (default: TEMPREPAIR*.EDB) /f<name> - set prefix to use for name of report files (default: <database>.integ.raw) /i - bypass the database and streaming file mismatch error /g - run integrity check before repairing /createstm - create empty streaming file if the file is missing /o - suppress logo NOTES: 1) Repair does not run database recovery. If a database is in a "Dirty Shutdown" state it is strongly recommended that before proceeding with repair, recovery is first run to properly complete database operations for the previous shutdown. 2) The /i option ignores the signature mismatch error in the check phase if the database and streaming file do not match each other. The database and streaming file will receive new signatures in the repair phase. Without using this option, repair will terminate immediately once the database and streaming file mismatch error occurs. 3) The /g option pauses the utility for user input before

repair is performed if corruption is detected. This option overrides /createstm and /o options. 4) The /createstm option is irreversible. Once you start the repair process a new streaming file will be created. Any streaming file that existed before the repair will no longer work with this database.

Event Service
A Windows NT service that is installed by Exchange Server 5.5. This service allows programmers to write programs that use Exchanges Event Handler to process events that occur in a Public Folder or Mailbox. Hosted organization (also known as virtual server, virtual machine, virtual organization)

A collection of Exchange services including, but not limited to virtual servers (that is, instances of IMAP4, SMTP, POP3, NNTP, HTTP, RVP), storage space, and real-time collaboration facilities that exist to serve the needs of a single company. A hosted organization is normally used by Internet Service Providers to host multiple companies on the same physical computer. However, a hosted organization is not limited to a single server running Exchange 2000.

Instant Messaging Presence Protocol IMPP

The standards-based protocol clients use to interact with an Instant Messaging server. IMPP is being developed by leading vendors, including Microsoft and Lotus. The Instant Messaging service in Exchange 2000 uses a Microsoft published protocol called Rendezvous Protocol (RVP) while IMPP is being ratified

Internet Messaging Access Protocol version 4 IMAP4

It is a standard-based protocol for accessing mailbox information. IMAP4 is considered to be more advanced than POP3 because it supports basic online capabilities and access to folders other than the Inbox. Exchange Server 5.x and Exchange 2000 both support IMAP4.

Joint Engine Technology JET

It defines the low-level access to underlying database structures in Exchange Server 4.0 and 5.0. JET was superceded with the Extensible Storage Engine (ESE) in Exchange Server 5.5 and Exchange 2000.

Link State Algorithm LSA

The algorithm used to propagate routing status information between servers running Exchange 2000. Based on Dijkstras algorithm, link state information is transferred between routing groups using the X-LINK2STATE command verb over Simple Mail Transfer Protocol (SMTP)SMTP and within a routing group using a Transmission Control Protocol (TCP) connection to port 691.

Mail-based replication MBR

It is a mechanism to replicate directory information through a messaging transport. This term applies to Exchange 5.x inter-site directory replication, and additionally, Active Directory replication through SMTP.

MDB
An instance of a database implemented in Exchange server. A single MDB is normally identified as being public or private depending on the type of data that it stores. A single server running Exchange 2000 can accommodate up to 20 active MDBs.

Messaging Application Programming Interface MAPI

MAPI is the API that is used by Microsoft messaging applications such as Outlook to access collaboration data. MAPI, or more specifically, MAPI Remote Procedure Calls (RPC), is also used as the transport protocol between Outlook clients and servers running Exchange.

Metabase
Metabase is a store that contains metadata such as that used by Internet Information Server IIS to obtain its configuration data. The metabase can be viewed through utilities such as Metaedit.

Metabase update service

It is a component in Exchange 2000 that reads data from Active Directory and transposes it into the local IIS metabase. The metabase update service allows the administrator to make remote configuration changes to virtual servers without a permanent connection to each system.

OLE DB
An Application Programming Interface (API) that allows low-level programming languages such as C and C++ to access dissimilar data stores through a common query language. OLE DB is seen as the replacement for Open Database Connectivity (ODBC). Data stores such as those in Exchange 2000 and SQL Server allow for OLE DB access, which makes application development easier and faster. High-level programming languages such as Visual Basic can use ActiveX Data Objects (ADO) to issue queries through OLE DB

Outlook Web Access OWA in Exchange 2003

Exchange 2003 now includes two versions of Outlook Web Access: Outlook Web Access Premium Outlook Web Access Premium is designed for Microsoft Internet Explorer 5.01 or later. Outlook Web Access Premium includes all Outlook Web Access features, including the new enhanced features for Exchange 2003. Microsoft Internet Explorer 6 is required for some features.

Outlook Web Access Basic Outlook Web Access Basic is designed to work in browsers that support the HTML 3.2 and the European Computer Manufacturers Association (ECMA) script standards. It provides a subset of the features available in Outlook Web Access Premium.

New Features
Logon / Logoff improvement New user interface improvements like colors, display, toolbar etc. View improvement like reading pan, auto-preview, mail icons, items per page etc. Navigation improvements like navigation pan, search folders, notification, public folders, logoff option on toolbar etc. Mail workflow improvement like spelling checker, global address list properties sheets, add to contacts, auto signature, default mail editor, read receipts, attachment blocking junk email filtering, Rules improvement like user can create server based rules Task improvement like user can create and manage personal tasks and receive reminders for these items. Calendar improvement like users can not reply to sender of meeting requests or forward meeting to other users. Performance improvement.

Post Office Protocol version 3 POP3

POP3 is a standards-based protocol for simple access to Inbox data. All versions of Exchange server except version 4.0 support POP3. POP3 uses TCP/IP port 110 for client to server access.

Protocol farm
A collection of virtual servers that are used as the primary connection point for users in an organization. The farm abstracts the connection protocols from the location of the back-end data, which allows users to access information without having to know its physical location.

Public folder tree (also known as public folder root and top level hierarchy TLH)
A collection of public folders created under the same hierarchical namespace. Previous releases of Exchange server used only a single tree (called: All Public Folders), whereas multiple trees can be defined in Exchange 2000. Each tree is a unit of hierarchy replication and can be replicated to one or more Public MDBs. A Public MDB can host only one tree. Messaging Application Programming Interface (MAPI) clients such as Outlook can only access a single tree called All Public Folders, whereas other clients such as a Web browser or a networking client using the Microsoft Web Storage System can access any tree that is defined.

Recipient Update Service RUS

This is part of the Exchange System Attendant and is responsible for keeping Address Lists upto-date and creating proxy addresses for users.

Remote Procedure Calls RPC

RPC is a reliable synchronous protocol that transfers data between clients and servers, and between servers. Outlook clients use Messaging Application Programming Interface (MAPI) RPC

for accessing mailboxes and public folders, and servers running Exchange 2000 communicate with the Exchange Server 5.x Message Transfer Agent (MTA) using RPC (in a mixed-vintage organization).

Resource mailbox
A mailbox that is associated with a resource instead of a user (such as a conference room for reservation purposes). In Exchange 5.5 one user (Windows security principal) may have had several mailbox accounts associated with it such as a receptionist with a personal mailbox and a conference room mailbox associated. In Exchange 2000, there must be a one-to-one correspondence between a Windows 2000 security principal and a mailbox. Consequently, Exchange 5.5 resource mailboxes must have a Windows 2000 security principal (usually with no logon rights) associated with it, and a resource mailbox owner (with their own personal mailbox) is given delegated access to the resource mailbox.

Public Calendar
A public calendar is also a useful tool. It can also save you money, because unlike a dedicated mailbox, a public folder doesnt require a license. You can have as many public folders as you like. So, instead of creating a mailbox enabled user in Active Directory for scheduling meetings in, say, a meeting room, you can simply create an accessible public calendar folder. Unfortunately, public calendar folders are not published in the free/busy folder, so you cant really do advanced scheduling with these folders.

Public Folder Favorites

It is also beneficial to add the public contacts folder or any other public folder that you use frequently to your public folder favorites by dragging it there or by using the context menu using Right-click and choosing Add to Favorites. Be sure to also add sub-folders.

Figure 16 If you use Outlook 2003, after adding a folder to the public folder favorites you will be able to access it using the regular sections without the need to browse all the way to the folder list.

Figure 17

If you have public calendar favorites, you will be able view them side by side to determine which calendar is free and compare them to your own calendar.

Figure 18 You can also modify your Exchange account in Outlook 2003 Cache mode to download public folder favorites so they are automatically available offline. From the Outlook menu choose Tool > E-mail Accounts > Exchange Server Settings > More Settings > Advanced.

Figure 19

Exchange 2003 Windows 2003 connectivity through firewalls

53 (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) Domain Name System (DNS) to all DNS Servers listed in the front-end server's IP configuration. (TCP) Required for Exchange 2000 Outlook Web Access for communication between Exchange front-end and back-end servers. (Transmission Control Protocol [TCP], UDP) - Kerberos authentication to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (UDP) - Windows Time Synchronization Protocol (NTP) to all domain controllers that are in the same Active Directory site as the Exchange

80 88

123

front-end server. This is not required for Windows 2000 logon capability, but it may be configured or required by the network administrator. 135 389 (TCP) - EndPointMapper to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP, UDP) - Lightweight Directory Access Protocol (LDAP) to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP) - Server message block (SMB) for Netlogon, LDAP conversion and Microsoft Distributed File System (DFS) discovery to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP) - LDAP to global catalog servers.

445

3268

What Features have been removed from Exchange 2003

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

Connectors for Lotus cc:Mail and MS Mail The Connector for Lotus cc:Mail and Connector for MS Mail components are not supplied with Exchange 2003. Using Exchange 2003 System Manager to manage MS Mail or cc:Mail connectors on Exchange 2000 servers is not supported. If you need to manage these connectors, use the Exchange 2000 SP3 or later version of System Manager. If you want to upgrade an existing Exchange 2000 server to Exchange 2003 and either of these connectors is installed, you must use the Exchange 2000 Setup program to remove the connector before upgrading. If you want to retain these services in your organization, you should not upgrade the Exchange 2000 servers that are running these components. Instead, you should install Exchange 2003 on other servers in your organization. Real-time Collaboration Features Exchange 2000 supports numerous real-time collaboration features such as chat, Instant Messaging, conferencing (using Microsoft Exchange Conferencing Server), and multimedia messaging (also known as unified messaging). These features have been removed from Exchange 2003. A new dedicated real-time communications and collaboration server (currently under developmentcode-named Greenwich) will provide these real-time collaboration features. M: Drive The Exchange store (which uses the \\.\BackOfficeStorage\ namespace) has traditionally been mapped to the M: drive on an Exchange server. M: drive mapping provided file system access to the Exchange store. The M: drive is disabled, by default, in Exchange 2003. You can still use the file system to interact with the Exchange store, but you must enter the path directly using the \\.\BackOfficeStorage\ namespace. For example, to view the contents of the mailbox store on an

Exchange server in the mail.adatum.com domain, you would type the following at a command prompt: dir \\.\BackOfficeStorage\mail.adatum.com\mbx The reason for removing the M: drive mapping is because, in some cases, the mailbox store would become corrupted from file system operations, such as running a file-level virus scanner on the M: drive or running file backup software on the drive. Key Management Service Exchange 2000 includes Key Management Service, which works with Windows 2000 Certificate Services to create a public key infrastructure (PKI) for performing secure messaging. With PKI in place, users can send signed and encrypted messages to each other. Exchange 2000 Key Management Service provides a mechanism for enrolling users in Advanced Security, and manages key archival and recovery functions. Exchange 2003 no longer includes Key Management Service. Exchange 2003 supports standard X.509v3 certificate implementation, and works with PKI solutions that support X.509v3 certificates. For example, you can use the PKI included with Windows Server 2003 in place of Key Management Service. Specifically, Windows Server 2003 PKI includes the ability to manage the key archival and recovery tasks that are performed by Key Management Service in Exchange 2000.

RPC over HTTP

Exchange Server 2003 and Microsoft Outlook 2003 support the use RPC over HTTP feature in Microsoft Windows to access Exchange. Using the RPC over HTTP feature eliminates the need for remote office users to use a virtual private network (VPN) to connect to their Exchange servers. Users running Outlook 2003 can connect directly to an Exchange server within a corporate environment over the Internet. The Windows RPC over HTTP feature provides an RPC client (such as Outlook 2003) with the ability to establish connections across the Internet by tunneling the RPC traffic over HTTP. Because standard RPC communication is not designed for use on the Internet and does not work well with perimeter firewalls, RPC over HTTP makes it possible to use RPC clients in conjunction with perimeter firewalls. If the RPC client can make an HTTP connection to a remote computer running Internet Information Services (IIS), the client can connect to any available server on the remote network and execute remote procedure calls. Moreover, the RPC client and server programs can connect across the Interneteven if both are behind firewalls on different networks.

This protocol allows remote Outlook 2003 clients to connect to Exchange 2003 Servers using HTTP or HTTPS. The RPC protocol commands and data are "wrapped" (as known as encapsulated) in an HTTP header. The firewall in front of the Outlook 2003 MAPI client only sees the HTTP header and passes the outbound connection through. The RPC over HTTP protocols allows your remote users to get around what might be considered an overly zealous approach to outbound access control.

The Outlook 2003 client connects to an RPC over HTTP proxy server. The RPC over HTTP proxy server can be a front-end Exchange Server running IIS 6.0 on Windows Server 2003, or the RPC over HTTP proxy server can be a machine running the IIS 6.0 RPC over HTTP proxy service on a machine that is not configured as a front-end Exchange Server. The Outlook 2003 client only needs to connect to a Windows Server 2003 machine configured as a RPC over HTTP proxy. An example of such a configuration is shown in the figure below.

Que: Is there option to install Exchange 2003 on Windows 2003 64 Bit Edition?
Ans: Exchange 2003 cannot be installed on Windows 2003 64 Bit. The major reason for this limitation is that the Installable File System (ExIFS) driver runs under 32-Bit Kernel mode. Exchange Server 2003 doesn't include an Installable File System (ExIFS) 64-Bit driver version. Running 32 Bit Kernel mode drivers under 64 Bit Windows 2003 is not supported.

How the Kerberos Version 5 Authentication Protocol Works?

Windows Server 2003 implements the Kerberos V5 authentication protocol as a Security Support Provider (SSP), a dynamic-link library (DLL) supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both SSPs are loaded by the Local Security Authority (LSA) on a Windows Server 2003 computer when the system boots.

The system can use either SSP to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection and the preferences of the individual application that is being used. The Microsoft SSPI is the foundation for authentication in Windows Server 2003. That is, applications and infrastructure services that require authentication use SSPI to provide it. Windows Server 2003 implements the Kerberos V5 authentication protocol as a Security Support Provider (SSP), a dynamic-link library (DLL) supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both SSPs are loaded by the Local Security Authority (LSA) on a Windows Server 2003 computer when the system boots. The system can use either SSP to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection and the preferences of the individual application that is being used. The Microsoft SSPI is the foundation for authentication in Windows Server 2003. That is, applications and infrastructure services that require authentication use SSPI to provide it.

Kerberos SSP
Windows Server 2003 implements the Kerberos V5 authentication protocol as an SSP, a DLL supplied with the operating system. The system uses the Kerberos SSP, Kerberos.dll, as its first choice for authentication. After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP can be loaded by a process running in the user's security context to support the signing and sealing of messages. Because the Kerberos protocol is the preferred authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, including: Active Directory queries using the Lightweight Directory Access Protocol (LDAP) Remote server or workstation management using RPC calls Print services Client-server authentication Remote file access using the Common Internet File System/Server Message Block (CIFS/SMB) Distributed file system management and referrals

Intranet authentication to Internet Information Services (IIS) Security authority authentication for Internet Protocol Security (IPSec) Certificate requests to Certificate Services for domain users and computers

The Difference between a Mailbox enabled recipient and a Mail enabled recipient?
A Mailbox enabled recipient can log on to network resources and can access domain resources. Users can be added to groups and appear in the global address list. Mailboxenabled recipients can send and receive messages and store messages on their Exchange server mailboxes. You can use mailbox enabled recipients for all aspects and functions in Exchange Server 2003. A Mail enabled recipient can receive messages only at an external e-mail address. The mail enabled recipient cannot send or store messages on Exchange message stores. A mail enabled user has an account in Active Directory but no Exchange mailbox. A mail enabled user is listed in the global address list. This enables other users to easily locate and send email to a mail enabled user even if the account does not have a mailbox in the Exchange organization. For example, you may create a mail enabled user for onsite contract employees who require access to the network but who want to continue receiving their e-mail through their Internet service provider.

The Difference Between POP3 and IMAP

There are two different protocols available to access e-mail: POP3 (Post Office Protocol version 3) and IMAP (Internet Message Access Protocol). POP3 is useful when e-mail is checked from only one computer. IMAP is the better choice when you would like to check your mail from multiple computers, at work and home, for example. IMAP has the added benefit of accessing folders on the server, allowing you to organize your e-mail, and access it from anywhere. Tulane's Webmail uses IMAP. If you use Webmail, you should use IMAP on all of your e-mail clients. Use of a POP3 mail client in association with Webmail can cause errors in your inbox that will result in a temporary loss of access to your mail.

The Difference
POP3 works by reviewing the inbox on the mail server, and downloading the new messages to your computer. IMAP downloads the headers of the new messages on the server, then retrieves the message you want to read when you click on it. When using POP3, your mail is stored on your PC. When using IMAP, the mail is stored on the mail server. Unless you copy a message to a "Local Folder" the messages are never copied to your PC. Scenarios of Use POP3 You only check e-mail from one computer. You want to remove your e-mail from the mail server. IMAP You check e-mail from multiple locations.

Similarties:
Handle mail access only; relying on SMTP for sending. Rely on mail delivery to a, usually shared, "always up" mail server. Allow access to new mail from a variety of client platform types. Allow access to new mail from anywhere on the network.

Fully support the offline (download and delete) access model. Support persistent message identifiers for disconnected use. Have freely available implementations (including source) available. Have client implementations available for PCs, Macs, and Unix. Have commercial implementations available. Are open protocols, defined by Internet RFCs. Are native Internet protocols; no mail gateways required.

The Difference Between HTTP & HTTPS

The https:// protocol can be used in exactly the same way as the http:// protocol. The differences are that HTTPS uses a default port number of 443 (80 for HTTP) and that HTTPS automatically performs SSL negotiation and thus always sends data in encrypted form, i.e. web servers accessed through https:// have to be "secure web servers".

HTTPS is conducted over a Secure Socket Layer (SSL) connection. This encrypts your data for optimal security. Standard HTTP login transfers your data over the Internet like a standard Web page. Most Web-based e-mail accounts are limited to this format. The advantage of using the Standard HTTP is that it is faster than the Secure HTTPS.

Difference between - ESEutil & ISinteg

Microsoft includes two command line utilities with Exchange Server that are designed to accomplish various maintenance functions within the Exchange database. They are limited, complex, tedious, and time consuming when compared to the functionality contained within GOexchange. The best time to learn how to use these tools is in a lab environment before you need them. Like firearms and prescription medications, these tools can be dangerous if you don't understand how they work and when to use them. Imagine shooting a shotgun at a container full of watera graphic demonstration of what can happen when you mishandle a powerful tool. These two utilities are named ESEutil and ISinteg. ESEutil checks and fixes individual database tables and ISinteg checks and fixes the links between tables. To better understand the difference between ESEutil and ISinteg, lets use a building construction analogy. Running ESEutil is like having a structural engineer check your house's foundation. The engineer doesn't care what's inside the house. The engineer cares only whether the underlying structure is sound. Running ISinteg is like having an interior decorator come inside your house to check the way you've laid out your furnishings. The decorator doesn't care about the house's foundation. The decorator cares only whether the rooms' layout and decor meet with their approval. As you can see from the analogy above, both ESEutil and ISinteg are vastly different utilities, but they are complimentary and in some ways dependent upon each other to provide proper Exchange maintenance. In the next section, we will provide a more in-depth description of these two Microsoft Exchange utilities.

About ESEutil
ESEutil checks and fixes individual database tables but does not check the mail data contained in the Extensible Storage Engine (ESE) database. Object-oriented databases like Microsoft Exchange consist of big, structured sequential files connected by a set of indexes. The underlying database technology that controls these files is called Indexed Sequential Access Method, or ISAM. The ESE database engine exposes the flat ISAM structure as a hierarchy of objects. The function of ESEutil is to examine these individually indexed object pages, check them for correctness by comparing a computed checksum against a checksum stored in the page header, and verify that each page's data is consistent. ESEutil isn't for casual use. So, don't use ESEutil unless you absolutely need to run it and you understand what it does. To understand ESEutil, you need to know about the format of the ESE database in which ESEutil works and you need to be familiar with ESEutil's many modes of operation. ESEutil is a useful tool because it can operate in many modes. Each mode, however performs different functions with limitations or caveats. Defragmentation: ESEutil /d [options] Recovery: ESEutil /r [options] Integrity: ESEutil /g Repair: ESEutil /p [options] Checksum: ESEutil /k [options] The way that each of these functions is executed within the utility is to use a cryptic MS-DOS-like command structure as the parameter qualifier. For example, in order to run the defragmenter portion of the utility, an administrator would run ESEutil /d [options] and so on. We are not going to attempt to cover all the potential pitfalls with ESEutil, however, here are a few major issues regarding ESEutil to keep in mind: There are times when it is appropriate to use ESEutil on its own, however, a complete maintenance process includes the combined use of specific ESEutil and ISinteg commands, as well as other steps that must be undertaken. ESEutil is very powerful tool and, if the commands are entered improperly or in an incorrect order, the results can be catastrophic. The ESEutil command structure can be very confusing and, at times, misleading. Changing one letter in the command structure executes a completely different utility function, and the results to an Exchange database can be disastrous. Below are a few of the many different available modes and options for ESEutil, each of which can have very different results on a database. NOTE: For brevity we have not included entire command statements. - ESEutil /d will defragment the designated database and is a fairly straight forward mode of operation that is commonly used. Running a manual offline defragmentation is only part of the process that should be completed in order to keep the databases healthy. Many administrators run ESEutil on a database to remove deleted items and regain white space then, mistakenly assume that by doing so, the process is complete. Performing this task, however, doesn't check or address issues that may exist within the mail data itself, and it won't fix the links between the tables of an ESE database. The database now contains a higher percentage of errors, warnings, and minor inconsistencies than it did prior to defragmentation. NOTE: Running ESEutil repeatedly without implementing a complete offline maintenance process is certain recipe for disaster. - ESEutil /d /p will have a slightly different result. The /d tells ESEutil to defragment the designated database. The /p option used with the /d instructs ESEutil to leave the newly created defragmented database in the temporary work area and not to overwrite the original database. - Now slightly modify the command to ESEutil /p and the actions taken on the designated database are extremely different. The /p evokes the Exchange Repair mode. At first glance

this sounds like a great thing to do, and it couldnt hurt to try because repairing the database should be beneficial right? Wrong! This command actually invokes a Hard Repair mode of ESEutil. This means that ESEutil will attempt to repair corrupt pages, but it makes no attempt to put the database in a consistent state. If it finds problems that cannot be corrected, then those pages will be discarded. Each page contains data therefore each discarded page represents data loss. Discarding certain pages of the database can actually render it useless. In other words, wave goodbye to your data. Sometimes, using the repair mode is the only way to fix a database. In the vast majority of situations, however, it should be avoided except as a last resort and there are specific steps that should be taken pre and post use of Repair /p mode.

About ISinteg
The purpose of the Microsoft ISinteg utility is to inspect and fix weaknesses within the information store (IS). ISinteg looks at the mailboxes, public folders, and other parts of the IS, checking for anything that appears to be out of place. ISinteg scans the tables and Btrees that organize the ESE pages into their logical structures. In addition, the tool looks for orphaned objects, or objects that have incorrect values or references. Because ISinteg focuses on the logical level rather than physical database structure, it can repair and recover data that ESEutil can't. When looking at the physical database level, ESEutil might find the data to be valid because it looks for things such as page integrity and B-Tree structure. Data that appears valid to ESEutil from a physical view of the database might not be valid from a logical view. For example, data for various IS tables like the message, folder, or attachments table may be intact, but the relationships among tables or records within tables may be broken or incorrect because of corruption in the logical structure. This corruption can render the database unusable. Logical corruption of your Exchange Server databases is problematic and much more difficult to diagnose and repair than physical corruption. The user and administrator are, typically, unaware of a logical corruption occurrence. No specific symptoms identify logical corruption. Often, when an administrator discovers the logical corruption, it's too late for any repairs to take place. You can run ISinteg one of two ways: Default mode, in which the tool runs the tests you specify and reports its findings. Fix mode, where you specify optional switches instructing ISinteg to run the specified tests and attempt to fix whatever it can. The most important thing about running ISinteg is to run the command until it no longer reports any problems. Just running the command once does not guarantee that the information store is functioning properly. Depending on the size of the information store, the process can take a long time, however, it ensures that the databases are properly functional

Welcome to Exchange Team Blog Sign in | Join | Help

Overview of Exchange Server 2007 CAS Proxying and Redirection

In a Microsoft Exchange Server 2007 organization, a computer that is running Exchange 2007 that has the Client Access Server role installed can act as a proxy for other Client Access Servers within the organization. This is useful when multiple Client Access Servers (CAS) are present in different Active Directory sites in an organization and only one is exposed to the Internet. Note: In case the Active Directory does not have multiple sites, you do not have to configure Exchange 2007 for proxying or redirection. A Client Access Server can also perform redirection for Microsoft Office Outlook Web Access URLs. Redirection is useful when a user is connecting to a Client Access Server that is not in their local Active Directory site. Each site would have to have an Internet-facing CAS server with the ExternalURL set. Having the ExternalURL set is not a default configuration in Exchange 2007. This topic explains how Client Access Server Proxying, Redirection and "Find the Best CAS" work, when each is used, and how to configure your Client Access Servers for different scenarios. Understanding CAS Proxying In Exchange 2003, the front-end server communicates with the back-end server over HTTP. In Exchange 2007, the Client Access Server communicates with the mailbox server over RPC. It is a requirement to have a Client Access Server in each site where there is an Exchange 2007 Mailbox Server. The recommendation is to have the Client Access Server as the first Exchange 2007 Server role installed in each Active Directory site. If you were to just have a Mailbox Server role in any given site without a Client Access Server no users would be able to connect to their mailboxes via Outlook Web Access, ActiveSync, Exchange Web Services, POP3 and IMAP4.

The Client Access Server can be configured for internal access or can be Internet-facing named "First CAS". If there is no Internet-facing Client Access Server in the same site as the mailbox, then the request will be proxied from the Internet-facing Client Access Server to the internal Client Access Server named "Second CAS". All the traffic between First CAS and Second CAS is over http(s). Note: By default Exchange 2007 installs a self certificate when you install the Client Access Server role. As a recommendation you should install a public or a private certificate. Proxying is supported for clients that use Outlook Web Access, Exchange ActiveSync, Exchange Web Services, and the Availability service.

An Exchange 2007 Client Access Server can proxy requests in the following two scenarios: Between Exchange 2007 Client Access Servers Organizations that have multiple Active Directory sites can designate one Client Access Server as an Internet-facing server, named "First CAS", and have that server proxy requests to Client Access Servers in sites that have no Internet presence, named "Second CAS". The First CAS then proxies the request to the Client Access Server that is closest "Second CAS" to the user's mailbox. This is known as CAS-CAS proxying as we can in see the following illustration:

The mailbox of User2 is located on a mailbox server MBX2 in a remote active directory site without presence on the Internet. When the User2 accesses his mailbox via OWA or ActiveSync, the First CAS which is present on the Internet receives the request and then proxies to the Second CAS in the same AD site where the User2 mailbox is located. Note: Integrated Windows authentication for /owa virtual directory must be enabled via Exchange Management Console or Exchange Management Shell on the Second CAS. For /Microsoft-Server-ActiveSync virtual directory on Exchange 2007 SP1, you can enable via Exchange Management Shell via cmdlet Set-ActiveSyncVirtualDirectory. Between an Exchange 2007 Client Access Server and an Exchange Server 2003 Back-end server Proxying requests between an Exchange 2007 Client Access server and a Microsoft Exchange Server 2003 frontend server enables Exchange 2007 and Exchange 2003 to coexist in the same organization. External clients who connect to Outlook Web Access by using the /Exchange virtual directory or connect to Exchange ActiveSync by using the /Microsoft-Server-ActiveSync virtual directory will have their requests proxied to the appropriate Exchange 2003 back-end server (click to see a bigger version):

The above illustration presents the scenario where the mailbox of User2 is located on Exchange 2003 back-end server in an Active Directory remote site. When the User2 access his mailbox via OWA or ActiveSync, the First

CAS proxies the request not to the Second CAS or any Exchange 2003 front-end server but straight to the Exchange 2003 back-end server via http where the user mailbox is located. If the mailbox is located on a Exchange 2003 backend server in the same Active Directory site as the CAS, such as User1, the First CAS proxies the request straight to the Exchange 2003back-end server via http. Note: Integrated Windows authentication for /Exchange and /Microsoft-Server-ActiveSync virtual directories must be enabled via Exchange System Manager on Exchange 2003 back-end server. Proxying and Redirection both do not support virtual directories that use Basic authentication. For client communications to be proxied or redirected between virtual directories on different servers, Integrated Windows authentication must be turn on the Second CAS for /owa and /Microsoft-Server-ActiveSync, as well as on an Exchange 2003 back-end server for the virtual directories /Exchange and /Microsoft-Server-ActiveSync. Note: CAS-CAS Proxying will not work for Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4) clients. A client who is using POP3 or IMAP4 must connect to a Client Access server in the same Active Directory site as their Mailbox server. If the user mailbox is located on a Exchange 2003 backend server, POP3 and IMAP4 request will be proxied from CAS to Exchange 2003 back-end server. Understanding CAS Redirection Redirection is used when the organization has multiple Exchange 2007 Client Access Servers, in different Active Directory sites, facing to the Internet with the ExternalURL attribute enabled. Outlook Web Access users who access an Internet-facing Client Access server that is in a different Active Directory site than the site that contains their mailbox can be redirected to the Client Access server that is in the same site as their Mailbox server if that Client Access server is Internet-facing. When Outlook Web Access users try to connect to a Client Access server that is outside the Active Directory site that contains their Mailbox server, they will see a Web page that contains a link to the correct Client Access server for their mailbox. The scenario bellow presents how redirection works for Outlook Web Access and ActiveSync users. The mailbox of User2 is located on a mailbox server MBX2 in a remote Active Directory site where the Second CAS is Internet-facing, the ExternalURL attribute is set on for /owa virtual directory. When the User2 accesses his mailbox via OWA pointing to the First CAS. The First CAS checks if the ExternalURL is configured on the Second CAS. In this case the First CAS will return a web page that contains a link to the correct Client Access server for their mailbox, in the case, the Second CAS in AD Remote site.

The mailbox of User2 is located on a mailbox server MBX2 in a remote Active Directory site where the Second CAS is Internet-facing, the ExternalURL attribute is set on for /Microsoft-Server-ActiveSync virtual directory. When the User2 accesses his mailbox via ActiveSync pointing to the First CAS, the First CAS checks if the ExternalURL attribute is configure on the Second CAS. In this case the First CAS will return an HTTP error code 451 and an application Event ID 1008. In this case, you have to recreate the partnership with the device pointing to the right Exchange 2007 Client Access Server. Note: Redirection is supported only for clients that use Outlook Web Access. Clients that use Exchange ActiveSync, Exchange Web Services, POP3, and IMAP4 cannot use redirection. In next two blog posts on the subject, I will cover how Exchange 2007 CAS Proxying works for ActiveSync and OWA clients.

Additional reading on the subject

How Exchange Server 2007 CAS Proxying works for Outlook Web Access (OWA). Proxying for Outlook Web Access is used when there is only one Internet-facing CAS Server. In this scenario the will be proxied to the CAS server where his mailbox server is located. This requires more intensive resource on the CAS server than doing redirection. The main benefit to this is your users can have a single point of access from external and proxying is transparent to the end user. CAS-CAS Proxying is quite similar with the process described in the future topic "How CAS proxying works for ActiveSync". There are a few differences regarding the errors and logs.

Please see the following flowchart that will help you understand this process. To view the full version, please click on the thumbnail. We wanted to publish the flowchart in high resolution:

1. The First CAS queries the Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the mailbox is on Exchange 2007, the First CAS will determine the best CAS, a Client Access Server in the same AD site as the user's mailbox server. If the user's mailbox is on an Exchange 2003 server, the request will be proxied directly to the destination Exchange 2003 back-end server, even if there is an Exchange 2007 Client Access server within the destination Active Directory site. Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory. Once is determined where the user mailbox is located, in this case on a Mailbox Exchange 2007 Server named Chicago.fourthcoffee.com. The First CAS has already made the decision to talk directly to a mailbox server in the same site, proxy the request to the Second CAS or return a web page link with the ExternalURL from the Second CAS where the user mailbox is located. As the mailbox is on an AD remote site, the request is proxied to the Second CAS named Dallas.fourthcoffee.com. 2. If the First CAS itself is the best CAS for the request it will handle the request and initialize a mailbox session via RPC with the Exchange 2007 mailbox server. If it is an Exchange 2003 Server the communication will be via http(s) and Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory. If there is a Client Access server that is closer to the user's Mailbox server, Exchange 2007 determines whether the Client Access server has the InternalURL property configured on /owa virtual directory Exchange and if the authentication method is Integrated Windows authentication. If so, the user is proxied to the Client Access server specified by the InternalURL property. Otherwise will return an error message to the client if could not find the best CAS. Error: Outlook Web Access is not currently available for the user mailbox that you are trying to access. Please try again in a few minutes. If the problem continues, contact technical support for your organization and tell them the following: The available Microsoft Exchange Client Access servers in the target Active Directory site are not responding. If the Integrated Windows authentication is not set on the Second CAS, it will return an error message to the client.

Error: Outlook Web Access is not available. If the problem continues, contact technical support for your organization and tell them the following: There is no Microsoft Exchange Client Access server that has the necessary configuration in the Active Directory site where the mailbox is stored. 3. The server hosting https://dallas.fourthcoffee.com/owa may be configured not to allow Kerberos authentication. It might be set to use Windows Integrated authentication for the Outlook Web Access virtual directory, but be configured to only use NTLM (not Kerberos) authentication for Windows Integrated authentication. See the IIS documentation for additional troubleshooting steps if you suspect this may be the cause of the failure. 4. If the best CAS has an "ExternalURL" set on the /owa virtual directory, than then First CAS will return a web page link to the client with the ExternalURL from the Second CAS. 5. When attempting to connect to a proxy request, if the Second CAS returns a HTTP_441 response, it indicates that the second CAS did not have the CSC for the SID that was passed. The First CAS will obtain the CSC, serialized into XML and issues a proxy login request. Note: InternalURL is configured automatically during Exchange 2007 Setup. For Client Access servers that do not have an Internet presence, the ExternalURL property should be set to $null 6. The Second CAS initializes a new mailbox session to sync the user mailbox.

BES Activation Process What happens in the Background

Stage 1 - Activation The BlackBerry device user types the email address and activation password in the Enterprise Activation application on the BlackBerry device. The BlackBerry device then creates an encrypted activation message containing an ETP.DAT file and sends it using the wireless network to the BlackBerry device user's mailbox. The ETP.DAT message contains information about the BlackBerry device such as routing information and the BlackBerry devices activation public keys. The ETP.DAT message is routed through the BlackBerry Infrastructure to the BlackBerry device user's mailbox as a standard message with an attachment. When the ETP.DAT message is sent, the BlackBerry device displays a status of Activating.

Stage 2 - Encryption verification When the ETP.DAT message arrives at the messaging server, the BlackBerry Messaging Agent which is monitoring the users mailbox checks the message contents. The BlackBerry Enterprise Server processes the data attached to the message, first verifying that the encrypted password matches the one set for the BlackBerry device user. So the password that was entered by the user is matched with the one that was set by the Administrator on the BES. If they match, then the BlackBerry Messaging Agent generates a new permanent encryption key using either Triple Data Encryption Standard (Triple DES) or Advanced Encryption Standard (AES) and sends it to the BlackBerry device. The BlackBerry device displays a status of Verifying Encryption. Stage 3 - Receiving services The BlackBerry Enterprise Server and the BlackBerry device now establish a master encryption key. The BlackBerry device and the BlackBerry Enterprise Server verify their knowledge of the master key to each other. The BlackBerry device implements the new encryption key and displays the following message: Encryption Verified. Waiting for Services. This key will be used to encrypt all data that is sent from the device to the BES infrastructure. The BlackBerry Messaging Agent forwards a request to the BlackBerry Policy Service to generate service books. The BlackBerry Policy Service receives and queues the request, and then sends out an IT policy update to the BlackBerry device. The BlackBerry device registers that the policy is applied successfully. The BlackBerry Policy Service generates and sends the service books to the BlackBerry device, which is now able to send messages and displays the Services Received status. The BlackBerry device then displays the following message: Your email address, <user@domain.com> is now enabled. Synchronization service Desktop [S<SRP_Identifier>]

Stage 4 - Slow synchronization Once the [CMIME] service book has arrived, the BlackBerry device will be able

to reconcile messages with the BlackBerry device user's email account. You can configure reconciliation as required. All the service books should arrive at the same time, but only the [CMIME] is required for email reconciliation. The BlackBerry device registers the receipt of its service books to the BlackBerry Enterprise Server and the activation process completes. The message Activation Complete is shown. The slow synchronization process begins with a BlackBerry device request, synchronizing data from the calendar first (using the [CICAL] service book) and then the other organizer databases with the BlackBerry device. For wireless synchronization to occur, the Desktop [SYNC] service book is sent to the BlackBerry device. The [SYNC] service book allows for organizer data synchronization, wireless backup and restore capability, and synchronization of email settings and filters. The process is managed by the BlackBerry Messaging Agent for the Calendar, and the BlackBerry Synchronization Service for the remaining organizer databases. The appropriate service books and IT policies are sent from the BlackBerry Enterprise Server to the BlackBerry device. The BlackBerry device user is now able to send and receive email messages on the BlackBerry device. If the BlackBerry device user is configured for wireless organizer data synchronization and wireless backup, the BlackBerry Enterprise Server will send the following data to the BlackBerry device: Calendar entries Address Book entries Tasks Memos Email messages Existing BlackBerry device options that were backed up through automatic wireless backup When the enterprise activation process is complete, the BlackBerry device displays a status of Activation Complete. Role of the ETP.DAT message in the enterprise activation process

Once the BlackBerry device user selects Activate in the Enterprise Activation application on the BlackBerry device, the following actions occur: The ETP.DAT message is sent to the BlackBerry Infrastructure, which forwards

it to the email address that was typed in the Enterprise Activation application. The BlackBerry Enterprise Server, which monitors the BlackBerry device users mailbox, picks up the ETP.DAT message. The activation process begins. The BlackBerry Enterprise Server sends the acknowledgement and encryption information to the BlackBerry device. The IT policy is sent to the BlackBerry device. Once the BlackBerry Enterprise Server verifies that the policy has been applied successfully, it sends the required service books to the BlackBerry device. When the BlackBerry Enterprise Server has sent all the required information to the BlackBerry device, the following message is displayed: Your email address <user@domain.com> is now enabled The slow synchronization process begins.

A link to the same http://www.blackberry.com/support/enterpriseActivationPackage/ent erpriseActivation/activationProcess.swf

"The server is not responding. Please contact your system administrator" appears on the BlackBerry smartphone during the enterprise activation process
Overview During the enterprise activation process, the following error message appears indicating that the activation process failed: The server is not responding. Please contact your system administrator.

Cause
This issue might be caused by one of the following: 1. The activation password has not been set on the BlackBerry Enterprise Server.

2. The email address or password has been incorrectly entered on the BlackBerry smartphone. 3. The temporary password has expired. 4. The BlackBerry user's mailbox is full. 5. The ETP.DAT activation message is not arriving in the BlackBerry smartphone user's mailbox. 6. The BlackBerry smartphone does not have BlackBerry Enterprise Server and email transfer protocol (ETP) services turned on. 7. The BlackBerry smartphone is not assigned the BlackBerry Enterprise Server service class.

Resolution
Perform the appropriate resolution for the cause of the issue. Cause 1 The activation password has not been set on the BlackBerry Enterprise Server. Resolution 1 Set the activation password in BlackBerry Manager.

Cause 2 The email address or password has been incorrectly entered on the BlackBerry smartphone. Resolution 2 Have the BlackBerry smartphone user type the correct email address and password on the BlackBerry smartphone.

Cause 3 The temporary password expired due to one of the following:

Five activation attempts failed. The BlackBerry smartphone was not activated within 48 hours after the password was created.

The BlackBerry smartphone user typed the password correctly once, but the enterprise activation process could not complete for reasons such as IT policy rejection or a cancelled activation.

Resolution 3 Create a new temporary password for the account in BlackBerry Manager.

Cause 4 The BlackBerry smartphone user's mailbox is full. Resolution 4 Clear the contents from the mailbox.

Cause 5 The ETP.DAT activation message has not arrived in the BlackBerry smartphone user's mailbox. Resolution 5 Make sure the messaging server is not filtering ETP.DAT attachments.

Cause 6 The BlackBerry smartphone does not have BlackBerry Enterprise Server and email transfer protocol (ETP) services turned on. Resolution 6 BlackBerry smartphone users with only BlackBerry Internet Service cannot activate the BlackBerry smartphone using the enterprise activation process.

Cause 7 The BlackBerry smartphone is not assigned the BlackBerry Enterprise Server service class. Resolution 7

Have the BlackBerry smartphone user contact the wireless service provider to request that BlackBerry enterprise services be assigned to the BlackBerry smartphone .