Exchange 2003 Technical Reference

Microsoft Exchange Server 2003 Technical
Reference Guide
Microsoft Corporation
Published: December 12, 2006
Author: Exchange Server Documentation Team
Abstract
This guide is for Exchange Server experts who require detailed information about the
architecture and interaction among core components of Microsoft Exchange Server 2003.
Comments? Send feedback to exchdocs@microsoft.com.

Contents
Microsoft Exchange Server 2003 Technical Reference Guide.......................................... ........1
Contents.................................................................................................................. .................3
Technical Reference Guide for Exchange Server 2003.......................................... ................16
Introduction to the Exchange 2003 Technical Reference Guide.............................................16

What Will You Learn from This Guide?............................................................................. ...16
Who Should Read This Guide?............................................................................... ............18
What Should You Read First?......................................................................... ....................18
Exchange Server 2003 Technical Overview................................................. ..........................19
Exchange Server 2003 as a Message Handling System............................................. ...........20

General Components of a Message Handling System.................................................. ......20
The Message Handling System in the Network Infrastructure.......................................... ...22
Directory Integration.......................................................................................... .....................23

Recipient Objects in the Directory....................................................................... ................24
Configuration Information in the Directory.............................................................. .............25
Exchange Classes and Attributes in Active Directory......................................... .................26
Directory Access Architecture........................................................................................... ...26
The Message Transport.................................................................................................... ......27

Message Routing Architecture.................................................................. ..........................27
Message Routing with Routing Groups................................................................... ............28
The Exchange Message Store...................................................................... .........................30

Exchange Server 2003 Database Technology........................................ ............................30
Stores and Storage Groups.............................................................................................. ...31
User Agents in an Exchange Server 2003 Organization.................................................... .....32
Exchange Server 2003 Services Dependencies.................................................................. ...33
Understanding Windows Services Architecture................................................... ...................35

Responsibilities of Service Control Manager............................................................... ........35
Exchange Services and the LocalSystem Account.................................. ...........................41
Examining the Services Database.......................................................... ............................42
Operating System Services.................................................................................. ..................47
Internet Information Services........................................................................................... .......51

Core Exchange Server 2003 Services............................................................................... .....56
Additional Exchange Server 2003 Services..................................................................... .......65
How to Stop All Exchange Server 2003 Services on a Server........................................ ........69

Before You Begin..................................................................................... ...........................69
Procedure.......................................................................................................................... ..69
Exchange Server 2003 and Active Directory.................................................. ........................69
Directory Integration and Exchange Server 2003..................................................... ..............71

Exchange Classes and Attributes in Active Directory......................................... .................71
Directory Service Access................................................................................................... ..73
LDAP Connection Load-Balancing and Failover.......................................... .......................75
DSAccess Topology Discovery...................................................................................... ......77
Initial Discovery and Ongoing Rediscovery........................................................... ..............78
Hard-Coding DSAccess Servers......................................................................... ................81
DSAccess Profiles.......................................................................................................... .....83
Specifying the Configuration Domain Controller.............................................................. ....84
How DSAccess Assigns Server Roles................................................................................ .85
Directory Access Cache.................................................................................... ..................89
Preloading DSAccess......................................................................................................... .91
Directory Service Proxy......................................................................................... .................93

DSProxy Operations........................................................................................................... .94
Exchange Server 2003 Referral Behavior before Service Pack 2.......................................94
Exchange Server 2003 Service Pack 2 Referral Behavior............................... ...................97
SMTP Categorizer............................................................................................... .................101

Message Categorization and Active Directory.......................................................... .........102
Recipient Update Service and Exchange Server 2003............................................... ..........104

Updating Recipient Objects....................................................................................... ........104
Metabase Update Service............................................................................. .......................106

DS2MB Operations..................................................................................... ......................107
Exchange System Manager Architecture........................................................................ ......107
Integration with Microsoft Management Console.......................................................... ........108

Exchange Server 2003 Snap-ins and Snap-in Extensions................................................114
Building Custom Exchange Management Consoles.........................................................126
Managing Configuration Information in Active Directory....................................... ................127

Binding to a Domain Controller............................................................... ..........................128
The Exchange Organization in the Configuration Directory Partition................................130
Exchange System Manager and Permission Settings................................................. ......132
Enabling the Security Tab for Objects in Exchange System Manager...............................133
Permissions Inheritance and Exchange System Manager................................................135
Managing Exchange Store Resources........................................................... ......................138

MAPI-Based Communication........................................................................ ....................139
Information Obtained Through the IExchangeManageStore Interface..............................139
Exchange System Manager and MAPI-Based Clients............................... .......................141
DAV-Based Communication.............................................................................. ................141
DAV-Based Communication and HTTP Virtual Directories......................................... .......141
Exchange System Manager and the Exadmin Virtual Directory........................................143
Connecting to a Specific Exchange Server.................................................... ...................145
Exchange System Manager and the Default Web Site................................................... ...146
The Exadmin Virtual Directory and SSL Encryption.................................... ......................147
How to Display All Information Obtained for a Mailbox Store or Public Folder Store............148
Procedure........................................................................................................................ ..148
How to Connect to a Specific Exchange Server in Exchange System Manager...................149

Procedure........................................................................................................................ ..149
Integration with Windows Management Instrumentation................................ ......................149
Service Configuration in Exchange System Manager....................................................... ....153
Message Routing Architecture...................................................................................... ........155
Exchange Server 2003 Message Routing Topology............................................ .................156
Exchange Server 2003 Message Handling.......................................................................... .160
Exchange Server 2003 Message Routing..................................................... .......................167

Message Routes and Link State Table................................................................ ..............167
Initializing the Link State Table......................................................................... .................167
Routing Engine and Exchange Routing Engine Service................................................... .168
Examining the Link State Table........................................................................ .................169
Exchange Routing Path Selection.......................................................................... ...........186
Routing Path Selection Process.............................................................................. ..........189
Dijkstra's Shortest-Path Algorithm....................................................................... ..............190
Message Transfer Load Balancing......................................................................... ...........194
Load Balancing between Routing Groups............................................................ .............194
Load Balancing between Connectors and External Systems.............................. ..............197
Message Rerouting Based on Link State Information................................ .......................198
Message Rerouting.......................................................................................... .................198
Rerouting and Address Spaces............................................................................... ..........200
Connector Recovery.......................................................................................................... 200
Rerouting and Activation Schedules............................................................................ ......200
Link State Propagation................................................................................... ......................201
Link State Algorithm................................................................................... .......................201
An LSA Example......................................................................................... ......................204
Link State Changes and Link State Propagation..................................................... ..........209
Changing the Routing Group Master........................................................................... ......210
Conflicts Between Routing Group Masters.............................................................. ..........211
Backward Compatibility with Exchange Server 5.5........................................................... ....212

Generating the GWART............................................................................ ........................212
Routing Issues in Mixed Mode..................................................................... .....................212
Topology Updates.................................................................................. ...........................213
Broken Link State Propagation...................................................................................... ....213
SMTP Transport Architecture............................................................................................ ....215
SMTP Service Design.......................................................................................................... .216

Internet Information Services (IIS) Integration.......................................................... .........217
Asynchronous Thread Execution...................................................................................... .217
Handling Incoming SMTP Connections..................................................................... ........218
Limiting the Number of SMTP Threads........................................................ .....................220
Component Object Model-Based SMTP Extensions............................................ .............221
Events in the SMTP Transport Subsystem.............................................................. ..........222
Event Dispatcher and Event Notifications................................................. ........................223
Administrative Interfaces...................................................................................... .............224
Configuration Settings and Event Bindings.................................................... ...................225
Configuration Information in Active Directory........................................... .........................226
SMTP Configuration Settings in the Metabase............................................................. .....230
SMTP Configuration Keys.................................................................................. ...............230
Direct Metabase Editing.................................................................................. ..................233
Local Domain Registrations..................................................................... .........................233
Event Sink Registrations................................................................................ ...................234
Server Extension Objects.......................................................................................... ........236
How to Enable the Enable Direct Metabase Edit Feature in IIS Manager............................237
Before You Begin................................................................................... ...........................238
Procedure........................................................................................................................ ..238
The Advanced Queuing Engine.............................................................................. ..............240

Events Triggered by the Advanced Queuing Engine........................................ .................240
Message Queues in the Advanced Queuing Engine........................................ .................244
Limiting the Number of Messages in Message Queues.................................. ..................249
SMTP Transport Components......................................................................... .....................250

Exchange Categorizer................................................................................................ .......252
Message Bifurcation.................................................................................................... ......263
Content Conversion........................................................................................................... 265
IMAIL.......................................................................................................................... .......266
TNEF.......................................................................................................................... .......266
Public Folder Message Handling................................................................................... ....268
Categorizer Performance Tuning........................................................... ...........................269
Global Catalog Load Balancing................................................................................ .........272
LDAP Search Batches.................................................................................................... ...273
Message Re-Categorization...................................................................................... ........275
Alternate Data Streams in the \Queue Directory.......................................... .....................275
Forcing Re-Categorization....................................................................... .........................277
SMTP Service Store Drivers........................................................................................ .........278

NTFS Store Driver....................................................................................................... ......279
Relocating the \Mailroot Directory............................................................... ......................281
Exchange Store Driver.................................................................................... ..................282
Exchange Store Driver Architecture........................................................... .......................283
Exchange Installable File System.......................................................... ...........................285
Outbound Message Transfer.................................................................................... .........287
Inbound Message Transfer............................................................................................. ...290
Transfer Retries.............................................................................................................. ...292
SMTP Protocol Extensions..................................................................................... ..............293

Protocol Event Categories............................................................................................... ..298
Exchange-Specific SMTP Protocol Extensions................................................ .................299
For More Information................................................................................................... ......305
Protocol Logging, Event Logging, and Message Tracking......................................... ...........305

Protocol Logging.......................................................................................... .....................306
Event Logging.............................................................................................. .....................307
Field Engineering Logging............................................................................................... ..307
Message Tracking............................................................................................. ................307
How to Enable Diagnostics Logging for the SMTP Service in Exchange System Manager..308
Before You Begin................................................................................... ...........................308
Procedure........................................................................................................................ ..309
How to Set the Diagnostics Logging Level for MSExchangeTransport Categories to Field
Engineering......................................................................................................... ..............309
Before You Begin................................................................................... ...........................309
Procedure........................................................................................................................ ..310
How to Enable Message Tracking in Exchange System Manager..................................... ...310

Before You Begin................................................................................... ...........................310
Procedure................................................................................................................ ..........311
Reference................................................................................................................ ..........311
X.400 Transport Architecture...................................................................... ..........................311
Exchange MTA in Exchange Server 2003 Architecture........................................................ .313

Exchange MTA Communication Partners................................................................. .........313
Exchange MTA Configuration Settings in Active Directory................................................317
Internal Exchange MTA Architecture........................................................ .........................322
Exchange MTA Database........................................................................................ ..........326
Relocating the MTA Database Directory......................................................................... ...329
Secured and Unsecured Message Copies........................................................... .............330
MTA Database in a Server Cluster.................................................................. ..................331
Corrupted Messages in Gateway Queues....................................................................... ..331
Fixing MTA Database Corruption...................................................................................... .332
Wiping the MTA Database....................................................................................... ..........333
Replaying DAT Files................................................................................................ ..........333
Examining Exchange MTA Processing..................................................................... .........334
Checking the Exchange MTA Using System Monitor................................ ........................334
Exchange MTA Event Logging................................................................... .......................338
Text Event Logging...................................................................................................... ......342
Trace Level Logging................................................................................................ ..........343
MTA Check Logging....................................................................................... ...................344
Object IDs and Message IDs.......................................................................................... ...344
How to Wipe the MTA Database................................................................................. ..........345

Before You Begin................................................................................... ...........................345
Procedure........................................................................................................................ ..345
How to Replay DAT Files After an MTA Database Wipe....................................... ................346

Before You Begin................................................................................... ...........................347
Procedure........................................................................................................................ ..347
Reference........................................................................................................................ ..347
How to Replay DAT Files After an MTA Database Wipe via a Complete Replay..................347
Before You Begin................................................................................... ...........................347
Procedure........................................................................................................................ ..348
How to Replay DAT Files After an MTA Database Wipe via a Remote Replay.....................350
Before You Begin................................................................................... ...........................350
Procedure........................................................................................................................ ..351
How to Replay DAT Files After an MTA Database Wipe via an Incremental Replay.............352
Before You Begin................................................................................... ...........................352
Procedure........................................................................................................................ ..352
MTA Transport Stacks and X.400 Connectors....................................................... ...............354

Message Transfer Service.............................................................................................. ...355
Reliable Transfer Service............................................................................... ...................362
Association Control Service..................................................................... .........................365
Presentation and Session Services.............................................................................. .....366
MTA Transport Stacks................................................................................... ....................367
MTA Communication Example.................................................................... ......................370
X.400 Connectors.................................................................................. ...........................372
Configuring an X.400 Connector........................................................................ ...............372
Connect Request Information......................................................................................... ...374
Outgoing and Incoming OSI Address Information........................................ .....................375
X.400 Addresses............................................................................................... ................375
X.400 Address Spaces.......................................................................................... ............376
Conformance Year and Body Parts................................................................... ................378
Message Loop Detection................................................................................................. ..380
X.400 Connector Objects in Active Directory.................................................................. ...382
Running Multiple X.400 Connectors....................................................................... ...........387
Connecting Routing Groups Using X.400 Connectors...................................................... ....389

Load Balancing between Routing Groups............................................................ .............390
Message Routing over Exchange MTAs................................................. ..........................391
SMTP XAPI Gateway.......................................................................................... ..............391
Exchange MTA Message Transfer................................................................................... ..393
Link State Information and Message Rerouting...................................... ..........................395
Exchanging Link State Information Between Routing Groups.................................. .........396
Exchange MTA in a Mixed-Mode Organization........................................................... ..........397

RPC-Based MTA Communication.............................................................. .......................398
RPC Performance Impact........................................................................ .........................399
RPC Bindback Error.............................................................................................. ............400
Gateway Address Routing Table................................................................ .......................400
Message Loops Between Exchange Server 5.5 and Exchange Server 2003...................402
Gateway Messaging Connectors Architecture......................................................... .............402
EDK Connector Architecture.......................................................................................... .......403

Connector Components............................................................................ ........................406
Message Transfer to and from Exchange Server 2003.................................... .................413
Outbound Message Transfer.................................................................................... .........414
Inbound Message Transfer............................................................................................. ...415
MAPI Profiles for MAPI-Based Connectors......................................................... ..............415
Message Conversion........................................................................................................ .417
Address Translation........................................................................................................... 418
Proxy Addresses and One-Off Addresses.......................................................... ...............419
Address Mapping Issues...................................................................................... .............420
Directory Synchronization........................................................................ .........................423
Directory Synchronization from a Non-Exchange Messaging System to an Exchange
Organization....................................................................................... ...........................423
Directory Synchronization from an Exchange Organization to a Non-Exchange Messaging
System.................................................................................................................. .........425
How to Open a Connector Mailbox Using Mdbvu32.exe................................ ......................427

Before You Begin................................................................................... ...........................427
Procedure........................................................................................................................ ..427
Connector for Lotus Notes Architecture..................................................................... ...........428

Message Transfer................................................................................. ............................435
E-Mail Message Type Conversion.............................................................................. .......439
E-Mail Message Property Mapping............................................................. ......................439
Connector for Novell GroupWise Architecture................................................... ...................442

Message Transfer................................................................................. ............................450
E-mail Message Type Conversion.............................................................................. .......455
E-mail Message Property Conversion................................................................... ............455
Calendar Connector Architecture....................................................................................... ...459

Free/Busy Information........................................................................................... ............459
Publishing of Free/Busy Data................................................................................... .........460
Free/Busy Messages........................................................................................................ .460
Free/Busy Data Generation............................................................................................ ...461
Free/Busy Publishing in Outlook.................................................................. .....................461
Free/Busy Publishing in Outlook Web Access and Outlook Mobile Access.......................463
Free/Busy Data Lookup................................................................................................... ..463
Free/Busy Publishing Agent (MadFB)........................................................ .......................464
Cleaning Free/Busy Data............................................................................... ...................465
Outlook Startup Switch............................................................................................... .......465
Cleaning Using Outlook Web Access................................................................... .............466
Calendar Connector Components........................................................................... ..........466
Free/Busy Lookups to and from Lotus Notes................................................ ....................471
Free/Busy Lookups from Exchange 2003................................................. ........................473
Free/Busy Lookups from Lotus Notes.............................................................. .................474
Free/Busy Lookups to and from Novell GroupWise.............................. ............................475
Free/Busy Lookups from Novell GroupWise............................................ .........................478
How to Check Whether a Server Running Exchange Server Contains a Replica of the
Free/Busy System Folder for the Administrative Group.................................................... .479
Before You Begin................................................................................... ...........................479
Procedure........................................................................................................................ ..479
Protocol Virtual Servers in Exchange Server 2003.................................................... ...........480
IIS Integration.................................................................................................... ...................481

Examining the Interprocess Communication Between IIS and Microsoft Exchange
Information Store Service.................................................................... ..........................482
Exchange Installable File System.......................................................... ...........................483
Inbound Messages................................................................................................. ...........484
Outbound Messages........................................................................................ .................485
File System Semantics............................................................................................... .......485
ExIPC Binding Facility........................................................................................... ............485
ExIPC Protocol Stubs................................................................................................. .......486
MAPI and RPC over HTTP....................................................................................... ............486

RPC over HTTP.......................................................................................... ......................486
RPC Virtual Directory..................................................................................... ...................488
RPC over HTTP and the Microsoft Exchange Information Store Service..........................488
Internet Protocol Details................................................................................. ......................488

HTTP.......................................................................................................................... .......489
WebDAV and XML.................................................................................. ..........................490
POP3................................................................................................................................ .491
IMAP4....................................................................................................... ........................495
NNTP......................................................................................................... .......................498
Configuration Settings in Active Directory................................................. ........................499
Configuration Settings in the Metabase............................................................................ .499
IIS Metabase Updates Through DS2MB....................................................... ....................500
High Water Marks........................................................................................................... ...500
Front-End Server Architecture.................................................................................. .........500
Considerations When Using Front-End Servers............................................................ ....501
Exchange ActiveSync and Exchange 2003................................................... .......................502

Exchange ActiveSync Protocol Architecture................................................................... ...503
Sync Protocol Versions and Device Support....................................................... ..............505
Sync Protocol Commands......................................................................................... ........505
Sync Command Format............................................................................ ........................506
URI......................................................................................................................... ...........506
HTTP Header................................................................................................... .................507
HTTP Body................................................................................................................... .....507
Protocol-Independent Multicast Data on the Mobile Device................................. .............507
Exchange ActiveSync Profile.................................................................. ..........................508
Up-to-Date Notification.......................................................................................... ............508
Aggregators.................................................................................................................... ...509
Outlook Mobile Access and Exchange 2003........................................................................ .509

Outlook Mobile Access Dependencies............................................................. .................510
Outlook Mobile Access and .NET............................................................................ ..........510
.NET Framework............................................................................................. ..................510
ASP.NET............................................................................................................................ 511
Session Management................................................................................................ ........511
Modified URL Session ID........................................................................... .......................512
ASP.NET Device Updates................................................................................ .................512
Outlook Mobile Access Architecture................................................................. .................512
Outlook Mobile Access and Microsoft Outlook Web Access Templates............................513
Outlook Mobile Access Data Sources........................................................ .......................513
Outlook Mobile Access Directory Settings................................................................. ........514
Outlook Mobile Access and DS2MB............................................................................ ......516
Outlook Mobile Access and the Windows Registry............................... ............................516
Outlook Mobile Access and Web.Config................................................. ..........................518
Outlook Mobile Access Client Requests..................................................................... .......520
Outlook Mobile Access Security Architecture................................................ ....................520
Exchange Information Store Service Architecture....................................... .........................521
Exchange Storage Architecture......................................................................... ...................522

Storage Groups....................................................................................................... ..........523
Storage Group Architecture....................................................................................... ........524
Storage Group Attributes in Active Directory................................................. ....................526
Storage Group Minimum Disk Space Requirements.............................................. ...........528
Exchange Store Databases............................................................................................ ...528
MAPI Database File................................................................................... .......................529
Streaming Database File............................................................................................ .......529
Property Promotion..................................................................................... ......................530
Database Size Limit Configuration and Management....................................................... ....531

Registry Settings............................................................................................... ................531
Database Size Limit in GB....................................................................... .........................532
Database Size Buffer Warning in Percentage............................................... ....................533
Database Size Check Start Time in Hours from Midnight................................................. .533
Behavior When the Configured Database Size Limit or Licensed Database Size Limit Are
Reached.............................................................................................. ..........................534
Licensed Database Size Limit............................................................................ ...............534
Disaster Recovery Planning Considerations.................................................. ...................535
Extensible Storage Engine Architecture................................................... ............................535
Transactions............................................................................................................... .......536
ACID Transactions...................................................................................... ......................536
The Version Store................................................................................. ............................537
Snapshot Isolation........................................................................................................ .....537
ESE Database Structure................................................................................ ...................538
Database Pages........................................................................................................... .....538
ECC Checksum............................................................................................................. ....539
Database Consistency and -1018 Errors......................................................................... ..539
Database Tree Balancing..................................................................................... .............541
Split.................................................................................................................. .................542
Merge.................................................................................................................... ............542
Fan-Out................................................................................................................ .............542
Indexes............................................................................................................................ ..542
Long-Values................................................................................................ ......................543
Record Format............................................................................................. .....................543
Column Data Types.................................................................................................... .......543
Fixed and Variable Columns.................................................................. ...........................545
Tagged Columns.......................................................................................... .....................545
Responsibilities of the Information Store........................................................ ......................545

Interactivity with other Exchange Services.......................................................... ..............545
Space Management......................................................................................... .................547
Database Defragmentation...................................................................... .........................547
Buffer Management................................................................................................... ........548
Dynamic Buffer Allocation....................................................................... ..........................548
The LRU-K Replacement Algorithm............................................................ ......................549
Public Folder Replication........................................................................................... ...........549

Public Folder Database Trees............................................................................ ...............550
Replication Overview........................................................................................................ .551
Packing and Unpacking.................................................................................................... .551
Change Numbers.............................................................................................. ................552
Replication Message Types................................................................... ...........................552
Replication Process........................................................................................................... 556
Hierarchy Replication....................................................................................... .................556
Content Replication................................................................................................ ...........557
Backfilling............................................................................................................ ..............557
Backfill Array........................................................................................... ..........................558
Replication Status....................................................................................... ......................558
Replication Status Thread.................................................................................. ...............559
Replication Status Requests......................................................................... ....................559
Modifying the Replica List........................................................................ .........................560
Adding a Replica............................................................................................... ................560
Deleting a Replica............................................................................................. ................561
Replication State Tables........................................................................................... .........561
Default Replication Event Schedule................................................................. .................562
Default Replication Values..................................................................... ...........................564
Exchange Server 2003 Cluster Architecture............................................................. ............564
Windows Cluster Architecture....................................................................................... ........566

Server Clusters...................................................................................... ...........................566
Server Cluster Architecture...................................................................... .........................567
Cluster Service Components.......................................................................................... ...568
Cluster Failover................................................................................................. ................573
Cluster Failback..................................................................................... ...........................574
Cluster Quorum....................................................................................................... ..........574
Standard Quorum......................................................................................................... .....575
Majority Node Set Quorums................................................................................ ..............575
Cluster Resources........................................................................................................ .....576
Cluster Administration................................................................................ .......................577
Cluster Formation and Operation...................................................................... ................577
Creating a Cluster....................................................................................... ......................577
Forming a Cluster......................................................................................................... .....577
Joining a Cluster.................................................................................... ...........................578
Leaving a Cluster........................................................................................ ......................579
Failure Detection............................................................................................... ................579
Exchange Virtual Servers.................................................................................. ...................580

Exchange Components in a Cluster....................................................................... ...........582
Active/Active Clusters....................................................................................................... .583
Active/Passive Clusters.............................................................................................. .......584
Resource Dependencies...................................................................................... .............585
Microsoft Exchange System Attendant Service....................................................... ..........585
Microsoft Exchange Information Store Service....................................... ..........................586
Message Transfer Agent........................................................................... ........................586
Protocols........................................................................................................ ...................587
Microsoft Search......................................................................................... ......................587
Exchange Cluster Interaction.............................................................................................. ..587

ExchangeOpen/ExchangeClose Functions......................................................... ..............588
ExchangeOnline and ExchangeOffline Functions...................................... .......................589
ExchangeIsAlive and ExchangeLooksAlive.................................................................... ...589
ExchangeTerminate........................................................................................................... 590
Creating Resources........................................................................................................... 590
Cluster-Specific Configurations................................................................... .........................590

Exchange MTA...................................................................................................... ............591
IIS SMTP Logging........................................................................................... ..................591
AntiAffinityClassNames....................................................................................... ..............591
MAPI Public Stores.................................................................................... .......................592
Eseutil....................................................................................................... ........................593
Installing Updates......................................................................................................... .....593
How to Disable MTA Monitoring on an Exchange Virtual Server..........................................593

Before You Begin................................................................................... ...........................593
Procedure........................................................................................................................ ..594
How to Enable SMTP Logging and Log the Files to a Shared Disk......................................594
Before You Begin................................................................................... ...........................595
Procedure........................................................................................................................ ..595
How to Create an HTTP Virtual Server in Exchange System Manager................................595

Before You Begin................................................................................... ...........................595
Procedure........................................................................................................................ ..596
How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster
.......................................................................................................................... ................597
Before You Begin................................................................................... ...........................597
Procedure........................................................................................................................ ..598
How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a
Windows Server Cluster............................................................................................ ........599
Before You Begin................................................................................... ...........................600
Procedure........................................................................................................................ ..600
Copyright............................................................................................................. .................600
16
Technical Reference Guide for Exchange

Server 2003
This technical reference guide presents a system architect's view of Microsoft® Exchange
Server 2003. It includes an overview of Exchange Server 2003 messaging system design,
together with more specific details, such as services dependencies, Active Directory®
directory service integration, Exchange System Manager architecture, routing architecture,
SMTP transport architecture, X.400 architecture, Exchange store architecture, and cluster
architecture. This information will help you design, maintain, and troubleshoot an Exchange
organization and also develop custom solutions for administrators.
This detailed reference guide is not for beginning administrators and does not show you how
to implement or maintain Exchange Server 2003. Instead, this guide is for Microsoft Certified
Systems Engineers (MCSEs) and Exchange Server experts who want to take their
knowledge about Exchange Server 2003 to the next level.
Note:
Download Microsoft Exchange Server 2003 Technical Reference Guide to print or
read offline.
Introduction to the Exchange 2003

Technical Reference Guide
Microsoft Exchange Server 2003 Technical Reference Guide is for Exchange experts who
require detailed information about the architecture and interaction among core components of
Microsoft Exchange Server 2003.
What Will You Learn from This Guide?

This technical reference guide presents a system architect's view of Exchange Server 2003.
It includes a general overview of Exchange Server 2003 messaging system design, together
with more specific details, such as services dependencies, Active Directory directory service
integration, Exchange System Manager architecture, routing architecture, SMTP transport
architecture, X.400 architecture, Exchange store architecture, and cluster architecture. This
information will help you design, maintain, and troubleshoot an Exchange organization and
also develop custom solutions for administrators.
This detailed reference guide is not for beginning administrators and does not show you how
to implement or maintain Exchange Server 2003. Instead, this guide is for Microsoft Certified
17
System Engineers (MSCEs) and Exchange experts who want to take their knowledge about
Exchange Server 2003 to the next level. See "What Should You Read First?" later in this topic
for a list of books that you might want to study before reading this technical reference guide.
This technical reference guide is structured according to the key components in Exchange
Server 2003, so that you can choose the chapter that interests you. For example, if you are
troubleshooting Active Directory communication problems, go to Exchange Server 2003 and
Active Directory, or if you are having issues with the SMTP service, go to SMTP Transport
Architecture. This guide provides detailed answers to the following questions:
• How does Exchange Server 2003 architecture compare to the general

architecture of a client/server messaging system?
• How are the various Exchange Server 2003 components integrated with the
operating system?
• What are the services dependencies of each Exchange Server 2003 component?
• Which components in Exchange Server 2003 communicate with Active Directory

and in what situations?
• With what types of domain controllers does Exchange Server 2003

communicate, and for what purpose?
• What are the components and communication dependencies of Exchange

System Manager?
• How does Exchange Server 2003 handle message transfer and routing?
• What are the internal components of the Simple Mail Transfer Protocol (SMTP)
service that Exchange Server 2003 replaces or extends to implement Exchange-
specific functionality?
• How exactly does the SMTP service communicate with the Exchange store for
inbound and outbound message transfer?
• What is the role of the Exchange message transfer agent (MTA) in the message
transfer architecture?
• What are the technical implications of deploying an X.400-based messaging

backbone in an Exchange Server 2003 organization?
• How does Exchange Server 2003 provide connectivity to non-Exchange

messaging systems, such as Lotus Notes and Novell GroupWise?
• What is the general architecture of Exchange Development Kit (EDK)-based

connectors?
• How does Exchange Server 2003 support Internet-based messaging clients?
• What is the architecture of the Extensible Storage Engine (ESE) that Exchange
Server 2003 uses to maintain the Exchange store?
18
• What are the responsibilities of the Exchange store?
• How does Exchange Server 2003 replicate public folders between servers in the
same Exchange organization?
• What components enable you to deploy Exchange Server 2003 in a server

cluster, and how does Exchange Server 2003 integrate with the Microsoft Windows
Cluster service architecture?
Who Should Read This Guide?

This guide contains valuable information for readers who want to learn more about Exchange
Server 2003. As mentioned earlier, this guide is for experienced messaging consultants,
system architects, administrators, and troubleshooters who are already Exchange experts.
Detailed technical knowledge will enable these Exchange experts to implement solutions that
go beyond the standard product capabilities or to solve bottlenecks and other problems.
This guide was designed for the following types of Exchange experts:
• IT Architects who design and deploy Exchange Server 2003.
• IT consultants who assist customers who deploy and maintain Exchange

Server 2003 organizations.
• Messaging administrators who operate an Exchange Server 2003 organization.
• System administrators who troubleshoot messaging systems.
• System developers who create messaging solutions that go beyond the standard
capabilities of Exchange Server 2003.
What Should You Read First?

Readers who are new to Exchange Server 2003 should read Windows, Microsoft Office
Outlook, and Exchange product documentation, in addition to the Exchange online books,
before reading this guide. Exchange documentation is available at the Exchange Server
TechCenter.
Exchange Server 2003 Technical Reference Guide assumes that you have read the following
books:
• Planning an Exchange Server 2003 Messaging System This book discusses

Exchange Server 2003 and related messaging technologies at a high level, including
features and limitations.
• Exchange Server 2003 Deployment Guide This book provides installation and
deployment information for intermediate and advanced administrators who plan to
deploy Exchange Server 2003.
19
• Exchange Server 2003 Administration Guide This book covers the core
concepts of Exchange Server 2003 administration.
• Exchange Server 2003 Interoperability and Migration Guide This book guides
you through the process of determining an efficient strategy to move from common
non-Exchange messaging platforms, such as Lotus Notes and Domino, Novell
GroupWise, and other messaging systems, to Exchange Server 2003.
Exchange Server 2003 Technical Overview

As a messaging server platform, Microsoft Exchange Server 2003 shares the following
common features with other e-mail systems:
• It transfers e-mail messages to intended recipients in a reliable way, whether the

recipients reside on the local server, another server in the same Exchange
Server 2003 organization, or another server in an external messaging environment
that is connected to the organization.
• It stores the e-mail messages in a server-based store.
• It supports various e-mail clients that are used to access or download messages.
• It gives users information about recipients in the organization through an address

book or global address list.
Exchange Server 2003 includes these features and many more. However, Exchange
Server 2003 does not provide these features by itself. Exchange Server 2003 integrates
tightly with the TCP/IP infrastructure provided by Microsoft Windows Server 2003 and Active
Directory directory service. To understand the Exchange Server 2003 architecture, you must
first understand TCP/IP-related technologies, Microsoft Windows Server 2003, and
Active Directory.
Additionally, you must be familiar with the following general messaging concepts:
• Messaging system characteristics This includes understanding the typical

components of a messaging system and basic message flow between servers.
• Integration of Active Directory with Exchange Server 2003 This includes

understanding how Exchange Server 2003 uses Active Directory to implement the
required directory infrastructure.
• Messaging connectivity This includes understanding how Exchange

Server 2003 transfers messages from senders to recipients.
• Message store This includes understanding the role and purpose of the
message store in a messaging system.
20
• Supported e-mail clients This includes understanding the various clients and
message access protocols that you can use in an Exchange Server 2003
organization.
This section gives you a foundation for later topics in this technical reference. For maximum
benefit from this guide, you must be familiar with Windows Server 2003 technologies.
For more information about Windows Server 2003, see the Windows Server 2003 Technology
Centers.
Exchange Server 2003 as a Message

Handling System
All messaging environments have several typical requirements in common. At a minimum,
every messaging system in a messaging environment requires the following:
• A message transport mechanism
• A list of all users in the messaging system
• A place to store messages until the client retrieves them
• An interface that e-mail clients can use to communicate with a server in the
messaging environment
General Components of a Message Handling

System
The following figure illustrates the components of a message handling system.
Components of a message handling system

21
Exchange Server 2003 implements the following messaging components:
• Directory The directory contains information about the users of the system.
This information is used to deliver messages to the intended users. The directory
also stores most of the configuration information about the message handling
system. It includes information about how the system is configured and how to route
messages from one messaging server to another. In Exchange Server 2003,
Active Directory provides the directory. Many components in Exchange Server 2003
use a directory access module, known as DSAccess, to communicate with
Active Directory. For more information about Exchange Server 2003 directory
architecture, see Exchange Server 2003 and Active Directory.
• Message transfer subsystem This component implements a routing and

transfer mechanism for e-mail messages. The message may be intended for
recipients on the same server or another server in the same organization, or for
recipients on the Internet or other messaging systems. The central transport engine
in Exchange Server 2003 is the Simple Mail Transfer Protocol (SMTP) transport
engine, which is implemented in the SMTP service that originally is included with
Windows Server 2003. Exchange Server 2003 extends the SMTP service to
implement the message-handling features that Exchange Server 2003 requires. Be
aware that message transfer in Exchange Server 2003 relies completely on the
SMTP transport engine, even if sender and recipient reside on the same server. For
more information about the SMTP transport engine, see SMTP Transport
Architecture.
• Message store In Exchange Server 2003, the message store (that is, the
Exchange store) stores e-mail messages and other items in mailboxes and public
folders. It also contains message tables that the transfer subsystem uses to store
messages temporarily when messages are routed from one server to another. The
Exchange store relies on Extensible Storage Engine (ESE) technology to implement
the messaging databases. For more information about Exchange store architecture,
see Exchange Information Store Service Architecture.
• User agent The user agent provides access to the messaging system. In other
words, the user agent is the messaging client. Exchange Server 2003 supports a
wide variety of messaging clients, including MAPI clients, HTTP clients, and clients
that use POP3, IMAP4, and Network News Transfer Protocol (NNTP). Lightweight
Directory Access Protocol (LDAP) support for directory lookups, on the other hand, is
provided by Active Directory.
22
The Message Handling System in the Network

Infrastructure
To transfer a message from one server to another in an Exchange Server 2003 organization,
the network must support TCP/IP. Both Active Directory and the SMTP service require
TCP/IP. The following figure illustrates the components that are required for system
communication and message transfer. You should be aware that specific components, such
as Connector for Novell GroupWise, might require additional components that are not listed in
this figure.
Networking components for Exchange Server 2003
Exchange Server 2003 requires the following networking components:
• IP and TCP Exchange Server 2003 requires TCP/IP to communicate with other
computers on the network. Exchange Server 2003 does not support other network
protocols.
• DNS Exchange Server 2003 requires DNS to resolve the IP addresses for other
hosts on a TCP/IP network, locate domain controllers and global catalog servers in
an Active Directory domain, and locate the e-mail servers in other messaging
organizations.
• DHCP and WINS Exchange Server 2003 does not require Dynamic Host
Configuration Protocol (DHCP) to function. But some of the networking clients on the
23
TCP/IP network may require this service. DHCP is used to automatically assign an IP
address to computers on a network. Windows Internet Name Service (WINS), on the
other hand, is used by Microsoft Windows clients to perform NetBIOS name
resolution. In network environments that contain routers that do not forward
broadcasts across network segments, WINS is required to resolve the IP addresses
for other computers on the network. Exchange Server 2003 requires WINS.
• Windows Sockets Exchange Server 2003 uses Windows Sockets to provide

connection points for network clients connecting to services on a server. A Windows
socket is a host's IP address combined with a port number that is used to identify a
server service.
• Active Directory Active Directory provides the directory service for Exchange
Server 2003.
• Internet Information Services (IIS) Exchange Server 2003 requires IIS to

provide Internet protocol support. All the Internet protocol services, such as HTTP,
SMTP, or IMAP4, run within the processing environment of IIS on the Exchange
server. For more information about IIS, see Internet Information Services.
• Security Subsystem Exchange Server 2003 uses a security subsystem of

Windows Server 2003 to authenticate users in the Exchange organization. The
security subsystem makes sure that only authorized users can access mailboxes or
send e-mail to specified recipients.
• Windows I/O Manager The I/O Manager on the server that is running
Exchange Server manages the transfer of data between the server hard disks.
Exchange Server 2003 uses the I/O Manager to access the transaction logs and
databases that are stored on the server hard disk. The I/O Manager also controls the
network file systems, such as server and client for Microsoft networks. Exchange
Server 2003 shares several file-system folders for network access and accesses
these folders using the Microsoft network file system.
Directory Integration
The Exchange Server 2003 information in Active Directory includes information about
recipients in the messaging system, as well as configuration information about the messaging
organization. Active Directory also provides the security subsystem for Exchange
Server 2003. Active Directory security ensures that only authorized users can access
mailboxes and that only authorized administrators can modify the Exchange configuration in
the organization.
24
Recipient Objects in the Directory

Recipients in an Exchange Server 2003 organization are represented by recipient objects in
Active Directory. The following five types of recipient objects are contained in an Exchange
Server 2003 organization:
• Mailbox-enabled user accounts A mailbox-enabled user is the most common

recipient object in an Exchange Server 2003 organization. A mailbox-enabled user is
a Windows user with a mailbox on a server running Exchange Server. A mailbox-
enabled user account is an Active Directory object that has a unique security
identifier (SID) assigned to it. This identifier enables the user to access resources in
the Active Directory domain. When a user account is mailbox-enabled, it has a
mailbox on a server running Exchange Server, which enables the user to send and
receive e-mail messages using a supported client, such as Microsoft Office Outlook.
• Mail-enabled user accounts A mail-enabled user has an e-mail address but

does not have a mailbox on a server running Exchange Server. A mail-enabled user
account has a SID and can access resources in the Active Directory domain, but the
e-mail address that is used to mail-enable the user account refers to a mailbox in a
non-Exchange or external messaging system. Mail-enabled user accounts are listed
in the global address list.
• Mail-enabled contacts A mail-enabled contact does not have a SID and thus
does not have an Exchange mailbox in the Exchange organization. This means that a
mail-enabled contact cannot access resources in the domain, but the recipient object
is visible in the global address list. E-mail messages sent to a contact are routed to
the e-mail address associated with the contact object.
• Mail-enabled groups A mail-enabled group is a collection of users, groups, and

contacts that are configured with e-mail addresses. Both universal and security
groups can be mail-enabled, but universal groups are recommended for e-mail
purposes. A mail-enabled group is often called a distribution list, because it is
assigned an e-mail address. When a message is sent to the group, Exchange
Server 2003 expands the group membership and delivers the message to each
individual recipient. Exchange Server 2003 supports the use of query-based
distribution groups, which are distribution lists that have their membership determined
by a Lightweight Directory Access Protocol (LDAP) query.
• Mail-enabled Public Folders A mail-enabled public folder is a public folder to

which you can send e-mail messages. A mail-enabled public folder has a unique e-
mail address and can be displayed in the global address list.
Note:
Exchange recipient objects are stored in the domain partition in Active Directory
(Active Directory partitions are also referred to as directory partitions). The domain
partition contains all of the objects in a specific domain and is replicated to every
25
domain controller in that domain, but not beyond that domain. The domain partition is
shown in Figure 1.3. For more information about the replication of domain
information, see the product documentation in the Windows Server 2003 Technology
Centers.
Configuration Information in the Directory

Exchange Server 2003 stores most of the configuration information for the Exchange
organization in Active Directory. Active Directory contains detailed information on server
objects, containers for administrative and routing groups, and all of the Exchange connectors.
This information specifies how each server running Exchange Server is configured, the
number of storage groups and stores on each server, and the Internet Information Services
(IIS) server configuration.
Exchange configuration information is stored in the configuration directory partition in

Active Directory. Some of the information that is stored in the configuration partition is show in
the following figure. Because Active Directory replicates the configuration partition between all
domains in the forest, the Exchange organization is also replicated throughout the forest.
However, the configuration partition cannot be replicated outside the forest. This means that
an Exchange organization cannot span multiple forests. However, it is possible to implement
multi-forest topologies in an Exchange organization. For more information about Exchange
multi-forest topologies, see the Exchange Server 2003 Deployment Guide.
Viewing Exchange information in Active Directory by using adsiedit.msc

26
Exchange Classes and Attributes in

Active Directory
In addition to the information stored in domain and configuration partitions, Exchange
Server 2003 also stores information in the schema partition. The Active Directory schema
defines all of the object classes that can be created in the directory, as well as the attributes
that can be assigned to each of the class objects. Before an Exchange Server 2003 server
can be installed in a forest, the Active Directory schema must be extended to include
Exchange-specific objects and attributes. The Active Directory schema partition and some of
the Exchange-specific objects are shown in the figure above.
Directory Access Architecture

The connection between Exchange Server 2003 and Active Directory is critical for reliable
server operation. Exchange Server 2003 uses the following two primary components to locate
and communicate to Active Directory domain controllers:
• DSAccess This component controls how other Exchange components access

Active Directory. DSAccess reads 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 contains a
memory cache, which reduces the load on Active Directory by reducing the number
of LDAP requests that individual components must send to Active Directory servers.
For example, in order to route messages, the transport process uses DSAccess to
obtain information about the connector arrangement. The SMTP transport engine
also uses DSAccess to resolve recipient information. This enables messages to be
routed to the servers on which the mailboxes reside.
• DSProxy This component provides an address book service for MAPI clients
running Outlook 2002 Service Release 1 (SR-1) and earlier versions. Exchange
versions 5.5 and earlier implemented a directory service so that clients could view the
global address list by querying the server running Exchange Server. In
Exchange 2000 Server and Exchange Server 2003, DSProxy emulates this address
book service.
Note:
Directory Service Proxy (DSProxy) refers Microsoft Outlook 2003 directly to a
global catalog server. Unlike earlier versions of Outlook, Outlook 2003 does not
require a directory proxy component on the server running Exchange Server
itself.
For detailed information about DSAccess and DSProxy, see Exchange Server 2003 and
Active Directory.
27
The Message Transport

The main purpose of a message handling system is to provide a means for transferring
messages from one messaging server to another. This message transfer may occur on the
same server, between Exchange Server 2003 servers in the same organization, between
servers running Exchange Server and Internet hosts, or between servers running Exchange
Server and foreign messaging systems. In all cases, the Exchange Server 2003 message
transport engine provides the routing and relaying of e-mail messages.
Message Routing Architecture

In an Exchange Server 2003 organization, all messages are routed using SMTP. The SMTP
protocol is also supported by all Internet messaging servers. If a server running Exchange
Server sends a message to another messaging server that only supports the X.400
messaging protocol, the SMTP component in Exchange Server 2003 is responsible for
routing the message. To accomplish this functionality, the SMTP component includes several
subcomponents.
The following components are involved in every message transfer on a server running
Exchange Server 2003:
• SMTP service The SMTP service handles the SMTP communication between
remote SMTP hosts and clients. This service implements the SMTP protocol
commands that Exchange Server 2003 supports.
• Store driver The store driver allows the SMTP service to communicate with the
Exchange store to save messages that are passing through the SMTP service. The
store driver also handles the delivery of messages for local recipients.
• Advanced queuing engine The advanced queuing engine provides queue

management and logic for message delivery, routing, and relaying.
• Categorizer The categorizer provides categorization services for inbound and

outbound messages. This component is also responsible for distribution list
expansion using the LDAP and Active Directory.
• Routing engine The routing engine provides the routing logic necessary to
pass outbound messages to the correct messaging connector or SMTP virtual server.
• Queue manager The queue manager controls link queues. Link queues are
used to store messages that are waiting for transfer to the next remote destination.
For detailed information on message routing architecture and the relationships between these
components, see Message Routing Architecture.
28
Message Routing with Routing Groups

Exchange Server 2003 uses routing groups to manage message delivery within an Exchange
organization. A routing group is a collection of servers running Exchange Server that are
connected by permanent network links.
Message delivery within a single routing group has the following characteristics:
• All message delivery is point to point Within a single routing group,

messages are always delivered from the sender's server running Exchange Server
directly to the recipient's server running Exchange Server. Messages are never
routed among multiple servers.
• All message delivery between Exchange Server 2003 servers uses

SMTP Exchange Server 2003 servers will always use SMTP to deliver messages to
other Exchange Server 2003 servers in the same routing group.
• Messages are delivered as soon as the messages are received Message

delivery within a single routing group cannot be scheduled. If one of the servers
running Exchange Server in a routing group is offline, the other servers running
Exchange Server in the routing group will queue all messages to be sent to that
offline server.
• Message delivery is automatically configured between Exchange

Server 2003 servers in the same routing group There is no way for an
administrator to modify the message flow within a single routing group.
Message delivery within a single routing group is illustrated in the following figure.
Message routing in single routing group
Exchange Server 2003 supports the use of multiple routing groups. Message delivery
between routing groups has the following characteristics:
• Routing group connectors must be configured between the routing groups.

29
• All messages sent between routing groups flow through bridgehead servers in
each routing group.
• Message delivery between routing groups can be configured. Configuration

options include scheduling message delivery, limiting message size, and restricting
users or groups from sending messages across the connector.
The following figure illustrates message routing between multiple routing groups.
Message routing between multiple routing groups
Exchange Server 2003 supports the following three routing group connectors:
• Routing group connector The routing group connector is the recommended

connector for connecting routing groups that are in the same Exchange organization.
This connector uses SMTP to transfer messages to other servers running Exchange
Server 2003. The routing group connector can only be used to connect routing
groups.
• SMTP connector The SMTP connector establishes a messaging route between

two routing groups or between a routing group and a non-Exchange SMTP host.
Although the routing group connector and the SMTP connector use SMTP as the
transport protocol, the SMTP connector provides additional functionality in that it can
be used to connect an Exchange organization with any SMTP server.
• X.400 connector The X.400 connector establishes an X.400 messaging route

between two routing groups or between a routing group and an X.400 system. Like
30
the routing group connector and the SMTP connector, an X.400 connector can be
used to link Exchange routing groups. Generally, X.400 connectors are used only
when connecting to other X.400 messaging systems.
Exchange Server 2003 supports the following optional connectors that you can use to
connect the organization to non-Exchange messaging systems:
• Exchange Connector for Lotus Notes Exchange Connector for Lotus Notes is
used for message routing and directory synchronization between an Exchange
organization and a Lotus Notes messaging system.
• Exchange Connector for Novell GroupWise Exchange Connector for Novell

GroupWise is used for message routing and directory synchronization between an
Exchange organization and a Novell GroupWise messaging system.
• Exchange Calendar Connector Exchange Calendar Connector is used for
exchanging free/busy information between an Exchange organization and a Lotus
Notes or Novell GroupWise messaging system.
The Exchange Message Store

Exchange Server 2003 supports the use of two types of stores: mailbox stores and public
folder stores. Each store is a logical database that includes two database files. The first file is
the streaming database file (.stm) which stores Internet-formatted messages, such as native
Multipurpose Internet Mail Extensions (MIME) content. Any messages in Internet format that
are submitted to the store by any client, other than MAPI clients, are stored in this file. The
second file is the MAPI database file (.edb), which contains all messages submitted to the
store through MAPI, as well as the database tables that define mailboxes, messages, folders,
and attachments. Properties of Internet-formatted messages are promoted to the MAPI
database so that the messages are listed in the Inbox of MAPI-based clients. In other words,
the .stm file contains the content of e-mail messages in Internet format, such as UUENCODE
or MIME, which is referenced by the corresponding .edb file. This means that the streaming
database and MAPI database files that comprise a particular database cannot be separated.
Exchange Server 2003 Database Technology

Exchange uses Extensible Storage Engine (ESE) to maintain transaction-based databases,
and uses write-ahead transaction log files to ensure that Exchange data is efficiently
processed. The transaction-oriented Exchange store provides for maximum recoverability. A
transaction can include multiple actions, but for the transaction to be committed, all actions
must complete successfully. If one part of the transaction cannot be completed, the entire
transaction is rolled back and not committed to the database. For more information about
31
transaction handling in Exchange Server 2003, see Exchange Information Store Service
Architecture.
Stores and Storage Groups

You can split the Exchange store into multiple storage groups and stores. A storage group is
a group of databases that share a single transaction log. A store is a single database than
contains the mailbox or public folder contents. In Exchange Server 2003, you can configure
up to four storage groups on each server running Exchange Server. Each storage group can
contain up to five stores. Exchange Server 2003 also includes an additional, dedicated
Recovery Storage Group. The Recovery Storage Group can be used to restore mailboxes or
stores while the other stores remain online. For more information about storage groups and
the Recovery Storage Group, see Exchange Information Store Service Architecture.
The following figure shows one possible storage group and store configuration on a server
running Exchange Server.
Stores and storage groups on a server running Exchange Server
The primary reason for deploying multiple storage groups and stores is to reduce the size of
each individual database while still supporting many users on one server. Having multiple
smaller stores enhances Exchange Server backup and recovery. Because all of the stores in
a storage group share a transaction log, each storage group should be backed up as a whole.
If your backup infrastructure supports multiple backup streams, you can back up multiple
storage groups at the same time. If you must restore data on the server running Exchange
Server, you restore each store individually. When you restore each store, you can mount it
and make it available to users.
32
Note:
Exchange Server 2003 supports a dedicated Recovery Storage Group so that you
can restore databases while users are connected to the original databases. Using the
Recovery Storage Group, you can restore individual mailboxes without disconnecting
unaffected users from the server.
User Agents in an Exchange Server 2003

Organization
User agents are messaging clients that the recipients use to access their mailboxes on the
server running Exchange Server. Exchange Server 2003 supports several different client
access protocols. The following table lists the supported messaging protocols.
Supported messaging protocols in an Exchange Server 2003 organization
Protocol Description
MAPI MAPI clients provide the most functionality.

With a MAPI client such as Outlook, you can
access the contents of all folders in a mailbox
and on the default public folder store. MAPI
clients use remote procedure calls (RPC) to
connect to the server running Exchange
Server. Exchange Server 2003 also supports
RPC over HTTP when running on Windows
Server 2003. Windows Server 2003 provides
the RPC over HTTP infrastructure. Client and
server are not aware of the protocol
encapsulation. For more information about
RPC over HTTP, see the Microsoft
Knowledge Base article 833401, "How to
configure RPC over HTTP on a single server
in Exchange Server 2003."
HTTP Exchange uses HTTP to provide access to

the message store through Outlook Web
Access, Exchange ActiveSync, and Outlook
Mobile Access.
POP3 POP3 is a mail retrieval protocol that provides

the most basic access to Exchange. POP3
allows a user to access messages in the
inbox folder of their mailbox.
33
Protocol Description
IMAP4 IMAP4 is a flexible mail retrieval protocol. You

can use an IMAP4 client to organize your
messages on the server. You can move
messages from folder to folder and preview
the contents of messages before you
download the entire message or a selected
portion of a message, such as an attachment.
NNTP NNTP is used for accessing newsgroups. You

can configure Exchange to publish portions of
the public folder hierarchy and make them
available to NNTP clients.
Exchange Server 2003 Services

Dependencies
Microsoft Exchange Server 2003 is a client/server messaging system in which active server
processes interact with client processes. You can view these server processes in the
Services tool, which you can find in the Administrative Tools program group. In Microsoft
Windows terminology, a server process is called a service. Most Exchange Server services
have a name that starts with Microsoft Exchange. The Microsoft Exchange Information Store
service is a good example.
In a client/server system, the majority of processing is performed directly on the server.

Server services accept requests and data from clients, process the requests, store the data,
and return the processing results to the clients. Microsoft Office Outlook is a client—a
messaging client. The primary task of a messaging client is to provide a user interface so that
a user can interact with the messaging system in an intuitive way. Exchange System
Manager is also a client. This client provides administrators with an interface with which to
manage an Exchange Server 2003 organization. Furthermore, the server services
themselves are clients to other server services. For example, the Simple Mail Transfer
Protocol (SMTP) service must communicate with the Exchange Information Store service to
access e-mail messages on a server running Exchange Server. Each service in Exchange
Server 2003 has a dedicated purpose. All services must interact with each other and with the
services provided by the operating system to function together as a messaging platform.
To understand Exchange Server 2003 as a client/server system, you must be aware of the
following components, their dependencies, and their interactions:
34
• Service Control Manager and Windows services architecture Service

Control Manager (SCM) is at the core of the Windows services architecture, because
it is the central component that manages all Windows services and device drivers
that run on Windows. SCM enables you to control a service, but you cannot control a
device driver. For example, Service Control Manager starts device drivers in a well-
defined order, according to their dependency trees, but you cannot stop device
drivers. However, you can start or stop Windows services in the Services tool from
the Administrative Tools program group. When you use the Services tool, you interact
with the SCM process.
• Operating system services The operating system provides a number of

necessary services, such as Remote Procedure Call (RPC) service and NTLM
Security Support Provider.
• Internet Information Services Internet Information Services (IIS) is an
important process that must be running on every server running Exchange 2003
Server. Exchange Server 2003 adds POP3 and IMAP4 services to IIS and extends
the SMTP service, the Network News Transfer Protocol (NNTP) service, and World
Wide Web service.
• Core Exchange services In order to perform as a messaging system,

Exchange Server 2003 contains several services that are not part of the operating
system or IIS. The core services in Exchange Server 2003 are those services that
must run on every Exchange server. This section introduces all core services in
detail.
• Additional Exchange services Exchange Server 2003 can be configured to

handle specific tasks. For example, you can use Exchange Server 2003 to implement
a dedicated mailbox server or a dedicated bridgehead server. Depending on the
server role, additional Exchange services may be required, such as messaging
connectors. Exchange services that are required only in specific situations are
considered additional services.
This section provides an overview of operating system and Exchange-specific services that
are required to run a fully functional server running Exchange Server 2003. It is assumed that
you are familiar with the Microsoft Windows Server 2003 platform, networking services, and
Active Directory, as well as Exchange Server 2003 administration concepts. For additional
information about Windows Server 2003, see the Windows Server 2003 Technology Centers.
For additional information about Exchange Server 2003 administration, see the Exchange
Server 2003 Administration Guide.
35
Understanding Windows Services

Architecture
Windows services, also called service applications, are applications that run on Windows
computers regardless of whether a user is logged in. A Windows service includes an
executable file, a directory for storing application components, and registry settings that
define the service parameters. The Windows service implements a programmatic interface
that SCM can use to control the service. A Windows service can be started automatically
when the system is booted or manually with a service control program. A service control
program is an application that uses SCM functions to control a service. Examples of service
control programs are the Services tool and the command-line tools net.exe and SC.exe.
The following figure illustrates the Windows services architecture.
Relationships between service control program, service control manager, and

Windows services
Note:
The SCM process is a remote procedure call (RPC) server service. RPCs enable
service control programs to communicate with SCM locally or over the network, in
order to control services on remote computers.
Responsibilities of Service Control Manager

SCM, also referred to as the service controller, is a generic Windows process that performs
various service-related tasks. These tasks are detailed in the following sections.
36
Maintaining a database of installed services

SCM maintains a database of all installed services, including a list of all services and device
drivers that must be loaded, in order for Windows to start successfully. As additional services,
such as Exchange Server 2003 services, are installed on the server, entries are added to the
services database. SCM maintains this database in the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
The services database contains a key for each installed service and driver. The name of the
key corresponds to the name of the service, as specified when the service was installed by a
service configuration program. For example, MSExchangeIS is the name of the Microsoft
Exchange Information Store service and MSExchangeSA is the name of the Microsoft
Exchange System Attendant service. The maximum service name length is 256 characters.
The following figure shows several Exchange-specific service entries in the registry.
Exchange-specific service entries in the registry
Note:
The names that you can see when working with the Services tool are the display
names of Windows services. For example, MSExchangeSA has a display name of
Microsoft Exchange System Attendant. The display name is defined in a REG_SZ
value named DisplayName that you can find under:
37
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service
name>.
Locking and unlocking the services database

SCM must lock the services database during SCM initialization in order to serialize access to
the configuration information. For example, SCM locks the services database before starting
a service, so that the service configuration cannot be changed while the service starts. SCM
releases the lock when the service start is complete. Service configuration programs must
also communicate with SCM to request a lock before reconfiguring a service and to release
the lock. You can use the SC.exe command-line tool with the command sc QueryLock to see
if the services database is locked.
Note:
When administering services that take a very long time to start, remember that you
cannot reconfigure startup type or other configuration settings during the service start
process, because SCM locks the service database. You can apply configuration
changes only before or after you start a service.
Enumerating installed services

The SCM process reads each registry key from the services database to create a service
record for each service. A service record includes the service name, startup type, the service
status (for example, the current state of the service and acceptable control codes), and a
pointer to the dependency list. SCM uses these service records to determine which actions
are valid for the services, according to their current status and dependencies. For example,
you cannot stop System Attendant in the Services tool if another service is running that
depends on System Attendant, such as the Microsoft Exchange Information Store service.
Starting, stopping, pausing, or resuming services

To perform general tasks, such as starting or stopping a service, SCM communicates with the
services it controls. SCM can start Windows services automatically at system startup (auto-
start service) or manually when requested by a service control program (demand-start
service). However, if an auto-start service depends on a demand-start service, the demand-
start service is also started automatically. The startup type can also determine that the
service is disabled, in which case it cannot be started. You cannot start an auto-start or
demand-start service if the service depends on a disabled service. This dependency is
important to note, especially if you plan to disable services (for example, on a front-end
server running Exchange Server). You must not disable essential services. Otherwise, the
operating system may not start, because disabled services prevent the start of all other
services that depend on them. If you notice startup problems after disabling a service, do not
log on to Windows. Instead, you should reboot the system with the "last known good"
38
configuration to discard the most recent changes to the service configuration. Windows stores
the "last known good" configuration in the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001
registry key and updates this key every time you log on successfully to the operating system.
When you log on to Windows with an incorrect configuration, you apply the incorrect settings
to the "last known good" configuration.
To quickly verify the dependencies and startup type of Exchange services, you can use the
tool SC.exe with the command sc <service name> qc. For example, the following output
represents the standard configuration of System Attendant (command line: sc qc
MSExchangeSA):
SERVICE_NAME: MSExchangeSA
TYPE : 10 WIN32_OWN_PROCESS
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : "C:\Program Files\Exchsrvr\bin\mad.exe"
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Microsoft Exchange System Attendant
SERVICE_START_NAME : LocalSystem
To determine the startup type, from the Services tool, click the General tab, and then click
Startup Type. You can also use the Services tool to start System Attendant or use SC.exe
with the command line sc start MSExchangeSA. You can also start services with the net
start command, such as net start MSExchangeSA. Most administrators prefer using the
Services tool.
Whether you use the Services tool, SC.exe, the net start command, or any other service
control program, SCM performs the following sequential steps to start a service:
1. Retrieves the account information stored in the services database
The user name and password of the service account are specified at the time the service
is installed. SCM stores the user name in a REG_SZ registry value named ObjectName
within the Registry key of the individual service
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>). The
password is in a secure portion of Local Security Authority (LSA). You can change the
service account in the Services tool, using the Log On tab.
Note:
Exchange Server 2003 services use the LocalSystem account by default. The
LocalSystem account is a predefined local account that has extensive privileges
39
on the local computer. This account is only available to system processes and
does not have a password.
2. Logs on the service account
All active processes must have an identity in Windows, and service applications are no
exception. When starting a service, SCM uses the account information obtained from the
services database and logs on to Windows. On the local computer, the account that SCM
uses to log on must have the special user right Log on as a service.
Note:
The LocalSystem account has the Log on as a service right implicitly, because
this account has complete access to all local resources.
3. Creates the service in suspended state
SCM starts new services in a suspended state, because the service is useful only after
SCM adds the required security information to the new process.
4. Assigns the access token to the process
Every process executed in Windows requires an access token, also referred to as a

logon token. The access token is an object that describes the service's security context.
The information in the token includes the identity and privileges of the service account
that the service uses to interact with the operating system.
5. Allows the process to execute
After it completes the logon procedure and assigns the access token, SCM can allow the
service to run and perform its functions.
SCM performs the following sequential steps when stopping a service:
1. SCM receives a stop request for a service
A service control program can stop a service using a service control function by sending
a SERVICE_CONTROL_STOP request to the service through SCM.
2. SCM examines the service dependencies
If SCM determines that other services are running that are dependent on the service
specified in the stop request, SCM returns an error code to the service control program.
Before it triggers the stop procedure, the service control program must enumerate and
stop all services that depend on the specified service. For example, the Services tool
displays a Stop Other Services dialog box, which asks if you want to stop all dependent
services as well. SC.exe, however, simply reports the failure code and states that the
service cannot be stopped, because other active services depend on it.
3. SCM forwards the stop request to the service

40
If it detects no dependent active services, SCM instructs the specified service to stop by
forwarding the stop code to the service. The service must now free its allocated
resources and shut down.
Maintaining status information for services that are running

When a service is running, it sends status notifications to the SCM process. SCM maintains
this status information in the service record for each service. SCM tracks this information so
that it does not mistakenly send control requests that do not conform to the recipient service's
current state.
The service status information includes:
• Service Type A service can be a file system driver, device driver, or a Windows
service, and can run its own process or share a process with other services. System
Attendant is an example of a service that runs its own process. The SMTP service,
however, is a service that shares a process with other services that are integrated
with Internet Information Services (IIS).
• Current state The service state can be starting, running, paused, stopping, or
not running.
• Acceptable control codes Theses are the control codes that the service is
able to accept and process in its handler function, according to the current state.
• Windows exit code The service uses this code to report an error that occurs
when it is starting or stopping. To return an error code specific to the service, the
service must set this value to ERROR_SERVICE_SPECIFIC_ERROR to indicate that
additional information can be found in the service exit code. The service sets this
value to NO_ERROR when it is running or stopping properly.
• Service exit code The service uses this code to report an error when it is
starting or stopping. The value is ignored unless the Windows exit code is set to
ERROR_SERVICE_SPECIFIC_ERROR.
• Wait hint The service uses this code to report the estimated time, in
milliseconds, required for a pending start, stop, pause, or continue operation.
• Checkpoint The service uses this value to periodically report its progress
during a lengthy start, stop, pause, or continue operation. For example, the Services
tool uses this value to track the progress of the service during start and stop
operations.
Tip:
To display the current status for all Windows services, you can use the command sc
query state= all type= service.
41
Exchange Services and the LocalSystem

Account
Exchange Server 2003 services run under the LocalSystem account. This has the following
security implications:
• No extra services account or password changes required The LocalSystem

account (NT AUTHORITY\LocalSystem) always exists and has a random
hexadecimal number as the password. This password changes automatically every
seven days, so you do not need to create a services account in Active Directory
before you install Exchange Server 2003 or change a services password at frequent
intervals.
• Full control to all local resources Because Exchange Server 2003 services
have full control over all local resources, these services usually have unrestricted
access to the registry database, IIS metabase, and the file system. This is not the
case, however, if the special Windows account SYSTEM or the Everyone account is
explicitly denied access, which is not recommended. Thus, if Exchange 2003 is
installed on a domain controller, Exchange Server 2003 services have full access to
Active Directory, because the domain controller hosts a directory replica, and
LocalSystem has complete access to local resources.
Note:
Most security-conscious organizations do not install Exchange Server 2003 on a
domain controller, because this installation does not enable separate
administration of Exchange Server 2003 and Active Directory.
• LocalSystem enables access to local resources only When a service runs

under the LocalSystem account, it can access only local resources, unless another
account is used for network access. Therefore, services that run under LocalSystem
use the NetworkService account for network access. The name of the account is NT
AUTHORITY\NetworkService. This account does not have a password.
The NetworkService account corresponds to the computer account of the local computer
in the domain. An Exchange service that runs in the security context of the LocalSystem
account uses the local computer account credentials when accessing domain resources,
such as Active Directory, over the network. Thus, Exchange Server 2003 has
substantially fewer privileges on a member server than on a domain controller, because
computer accounts by default have very few privileges and do not belong to any groups.
The default configuration for computer accounts permits only minimal access to
Active Directory.
To address this issue and grant the computer account the required permissions,
Exchange Server 2003 creates the following two special security groups in
Active Directory:
42
• Exchange Domain Servers Exchange Domain Servers is a global

security group that contains the computer accounts of all servers running
Exchange Server in a domain.
• Exchange Enterprise Servers Exchange Enterprise Servers is a local

security group that contains all global Exchange Domain Servers groups in
the forest. This security group grants access to the required resources in the
local domain for all Exchange computer accounts.
Note:
Do not rename or move the Exchange Domain Servers or Exchange Enterprise
Servers security groups, and do not remove computer accounts of existing
servers running Exchange from these groups.
Examining the Services Database

When you open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services in Registry Editor
(Regedit.exe) and examine individual keys for Exchange services, you find that many
services that start with MSExchange contain similar values under their service keys. The
following table lists these values.
General registry values for Windows services
Value Type Description

DependOnGroup
REG_MULTI_SZ Lists load-ordering groups on
which Windows services
depend. Services that depend
on a group can run if, after
attempting to install all
members of a group, at least
one member of the group is
running.
DependOnService
REG_MULTI_SZ Lists the names of Windows
services on which this service
depends. SCM must start
these services before it starts
this service. This value can be
an empty string if the service
has no dependencies.
43

Description
REG_SZ Describes the service. The
description is simply a
comment that explains the
purpose of the service.
DiagnosticsMessageFile
REG_SZ Contains the name of the
resource DLL that contains
the event description strings
for those events that the
service writes into the
application event log.
Resource DLLs are located in
the \Program
Files\Exchsrvr\Res directory.
DisplayName
REG_SZ Contains the display name
that is used to identify the
service. This string has a
maximum length of 256
characters. The name is
case-preserved in SCM.
Display name comparisons
are always case-insensitive.
44

ErrorControl
REG_DWORD Specifies error severity and
the action taken if this service
fails to start. This parameter
determines one of the
following:
• The startup
program logs the
error but continues
the startup operation.
• The startup
program logs the
error and displays a
message but
continues the startup
operation.
• The startup
program logs the
error. If the "last
known good"
configuration is
started, the startup
operation continues.
Otherwise, the
system is restarted
with the "last known
good" configuration.
• The startup
program logs the
error, if possible. If
the "last known good"
configuration is
started, the system
startup is cancelled.
Otherwise, the
system is restarted
with the "last known
good" configuration.
45

FailureActions
REG_BINARY Cites the action SCM should
take for each failure of a
service. A service is
considered failed when it
stops without reporting a
status to the service controller
(for example, when a service
fails).
Group
REG_SZ Names the load-ordering
group of which this service is
a member. Note that setting
this value can override the
setting of the
DependOnService value.
ImagePath
REG_EXPAND_SZ Contains the fully qualified
path to the service binary file.
If the path contains a space, it
must be quoted, so that it is
correctly interpreted. For
example, "d:\\Program
Files\\Exchsvr\\Bin\\mad.exe".
The path can also include

program arguments.
ObjectName
REG_SZ Specifies the name of the
account under which the
service should run. If the
service uses the LocalService
account, this parameter is set
to NT
AUTHORITY\LocalService. It
is also possible to specify an
account name in the form
DomainName\UserName.
46

Start
REG_DWORD Specifies when to start the
service. SCM can start a
service automatically during
system startup, or when a
process requests the service
start. This value can also
specify that a service cannot
be started and that attempts
to start the service should
result in the error code
ERROR_SERVICE_DISABLE
D.
Tag
REG_DWORD Determines the service
startup order within a load-
ordering group. Tags are only
evaluated for driver services.
Type
REG_DWORD Specifies the service type as
file system driver, device
driver, a service that runs its
own process, or a service that
shares a process with one or
more other services.
MSExchangeSA is an
example of a service that runs
its own process. EXIFS is an
example of an Exchange-
specific file system driver.
In addition, the following subkeys might exist for Exchange services:
• Diagnostics This key contains REG_DWORD parameters for possible event

log categories that the service provides. The name of the parameters underneath this
key is made up of a resource identifier number followed by a string, such as 9 Clean
Mailbox. The value associated with each parameter represents the diagnostics
logging level for that category. You usually configure these values through the server
properties in Exchange System Manager. The Diagnostics Logging tab lists the
various categories and assigns the selected values to these parameters.
• Enum This key contains parameters that SCM uses to enumerate the services
in the services database. For example, the REG_SZ parameter 0 contains a value
that refers to subkeys under the
47
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root registry key. This enables

the Windows configuration manager to enumerate the services as logical devices
during system boot.
• Parameters This key contains registry parameters for service-specific

configuration information. The Parameters key can contain further subkeys.
• Performance This key provides counters for performance monitoring. The

REG_SZ parameter Library specifies the DLL that contains the performance
counters. Further keys exist for the performance counters. For example, the REG_SZ
parameter PerfIniFile refers to the .ini file that defines the individual performance
counters.
• Security This key holds a REG_BINARY parameter called Security that

contains a service security descriptor that specifies which accounts can control the
service. For example, an administrator may have permissions to start and stop a
service, while a regular user does not.
Caution:
Incorrectly editing the registry can cause serious problems that may require you to
reinstall your operating system. Problems resulting from editing the registry
incorrectly may not be able to be resolved. Before editing the registry, back up any
valuable data.
Operating System Services

Exchange Server 2003 relies heavily on the operating system for network communication,
security, directory services, and so forth. For example, Exchange Server 2003 requires
TCP/IP and depends on the TCP/IP protocol stack and related components. These
components are implemented in kernel drivers deeply integrated into the Windows I/O
subsystem. Exchange Server 2003 uses standard Microsoft Win32 programming interfaces to
interact with the kernel.
In addition to the Windows kernel, Exchange Server 2003 has the following Windows
services dependencies:
• Event Log This service enables event log messages issued by Exchange
services and other Windows-based programs and components to be viewed in Event
Viewer. This service cannot be stopped.
• NTLM Security Support Provider This service provides security for programs
that use remote procedure calls (RPCs) and transports other than named pipes to log
on to the network using the NTLM authentication protocol.
48
• Remote Procedure Call (RPC) This service enables the RPC endpoint mapper
to support RPC connections to the server. This service also serves as the
Component Object Model (COM).
RPCs and lightweight remote procedure calls (LRPCs) are important inter-process
communication mechanisms. LRPCs are local versions of RPCs. LRPCs are used
between the Exchange store and those server components that depend on MAPI and
related APIs for communication, such as messaging connectors to non-Exchange
messaging systems. Regular RPCs, however, are used when clients must communicate
with server services over the network. Typical RPC clients are MAPI clients, such as
Microsoft Outlook and Exchange System Manager, but internal components of System
Attendant, such as DSProxy, are also RPC clients. To accept directory requests from
MAPI clients and pass them to an address book provider, DSProxy must use RPCs to
communicate with Active Directory through the name service provider interface (NSPI).
For more information about DSProxy, see Exchange Server 2003 and Active Directory.
It is important to understand that RPCs are an application-layer communication

mechanism, which means that RPCs use other network communication mechanisms,
such as NetBIOS, named pipes, or Windows Sockets, to establish the communication
path. To create a connection, the RPC endpoint mapper is required, because the client
must first determine the endpoint that should be used. RPC server services use dynamic
connection endpoints, by default. In a TCP/IP network, the client connects to the RPC
endpoint mapper through TCP port 135, queries for the current TCP port of the desired
service (for example, the Name Service Provider Interface (NSPI) port of
Active Directory), obtains this TCP port from the endpoint mapper, and then uses this
TCP port to establish the RPC connection to the actual RPC server. The following figure
illustrates the role of the RPC endpoint mapper.
Establishing an RPC connection to Active Directory

49
Note:
By default, Exchange services use dynamic TCP ports between 1024 and 5000
for RPC communication. For various services, such as System Attendant and
Exchange Information Store service, it is possible to specify static ports using
registry parameters. However, the client must contact the RPC endpoint mapper
whether the port assignment is dynamic or static.
• Server This service enables file and printer sharing and named pipe access to
the server through the server message block (SMB) protocol. For example, if you
access message tracking log files using the message tracking center in Exchange
System Manager, you communicate with the server service because message
tracking logs are shared for network access through \\<server name>\<server
name>.Log, such as \\Server01\Server01.log. The SMB protocol is also required for
remote Windows administration.
The SCM key for the server service is lanmanserver. Underneath this registry key, you
can find an important subkey called Shares. This key contains parameters for all shares
on the server. One share that is particularly important for System Attendant is Address,
which provides access to the proxy address generation DLLs that the Recipient Update
Service uses to assign mailbox-enabled and mail-enabled recipient objects, X.400,
SMTP, Lotus Notes, Microsoft Mail, Novell GroupWise, and Lotus cc:Mail addresses
according to the settings in recipient policies. Address generation DLLs are accessed
over the network, because gateway connectors (and their address generation DLLs) do
not necessarily exist on the local server running Exchange Server. Recipient Update
Service is part of System Attendant, so the server service must be started before System
Attendant can start.
• Workstation This service is the counterpart to the server service. It enables the
computer to connect to other computers on the network based on the SMB protocol.
This service must be started before System Attendant will start.
• Security Accounts Manager The Security Accounts Manager (SAM) service

stores security information for local user accounts and is required for local accounts
to log on to the server. Because all Exchange services must log on to the local
computer using the LocalSystem account, Exchange Server 2003 cannot function if
this component is unavailable.
• Windows Management Instrumentation This service provides a standard

interface and object model for accessing management information about the
computer hardware and software. System Attendant is the component in Exchange
Server 2003 that is responsible for server monitoring and status.
Exchange Server 2003 adds additional Windows Management Instrumentation (WMI)
providers to the WMI service, so that you can access Exchange status information
through WMI. The WMI service is required for the Microsoft Exchange Management
service to start.
50
In addition, there are also several Windows services that Exchange Server 2003 requires in
specific situations:
• COM+ Event System This service supports system event notification for COM+
components, which provide automatic distribution of events to subscribing COM
components. You should not disable this service on servers running Exchange
Server 2003, because event sinks wrapped in a COM+ component application that
run out-of-process on the server will not function properly.
• COM+ System Application This service manages the configuration and

tracking of COM+-based components. If the service is stopped, most COM+-based
components in Exchange Server 2003 will not function properly.
• Error Reporting Service This is an optional service that enables automatic

reporting of errors. Servers running Exchange Server can use this service to
automatically send fatal service error information to Microsoft.
• HTTP SSL This service implements the secure HTTP (HTTPS) for the HTTP
service, using Secure Socket Layer (SSL). If you want to use HTTPS to secure
Outlook Web Access or RPC over HTTP connections, you must enable this service.
• IPSec Services This service enables Internet Protocol security (IPSec), which
provides end-to-end security between clients and servers on TCP/IP networks. This
service must be enabled if you want to use IPSec to secure network traffic between a
server running Exchange Server and other computers on the network, such as a
front-end server running Exchange Server or domain controller.
• Microsoft Search This service enables the indexing of information stored on

the server. This service is required if you want to enable full-text indexing on a
mailbox or public folder store on the server running Exchange Server.
• Microsoft Software Shadow Copy Provider This service manages software-

based volume shadow copies taken by the Microsoft Volume Shadow Copy service.
If you are using the Windows Backup tool to backup Exchange Server 2003
messaging databases, you can stop this service, because the Windows Backup tool
does not rely on the Volume Shadow Copy service. If you are using a non-Microsoft
backup solution, on the other hand, which does use the Volume Shadow Copy
service, you must enable this service. In general, this service should have the same
startup type as the Volume Shadow Copy service.
• Net Logon This service enables a secure channel between the server running
Exchange Server and a domain controller. This service is required for users to
access mailboxes on the server running Exchange Server and for any service that is
using a domain account to start.
• Performance Logs and Alerts This service collects performance data from
local or remote computers based on preconfigured schedule parameters, and then
writes the data to a log or triggers an alert. If you stop this service, you cannot collect
51
performance information using the Performance Logs and Alerts snap-in, which is
available in the Performance tool.
• Remote Registry This service enables users to modify registry settings

remotely. Exchange System Manager requires access to the registry, for example, if
you want to configure diagnostics logging for Exchange services. This service must
be available if you run Exchange System Manager on a management workstation. If
this service is stopped, the registry can only be modified on the local server.
• System Event Notification This service monitors system events and notifies
subscribers to COM+ Event System of these events. If this service is stopped, COM+
Event System subscribers do not receive Exchange system event notifications. The
following table lists the system events provided by Exchange Server 2003.
System events in Exchange Server 2003
Event Description
OnTimer Called at a specified interval.
OnMDBStartUp Called when a store is started.
OnMDBShutDown Called when a store is stopped.
• Volume Shadow Copy This service manages and implements Volume Shadow
Copies used for backup and other purposes. This service must be running if your
backup solution uses an Exchange Server 2003 Volume Shadow Copy service
requestor to create shadow copies of messaging databases. If this service is
disabled, your backup processes could fail.
Note:
The services listed above are configured to start automatically on Windows
Server 2003. They run within the security context of the LocalSystem account.
Internet Information Services

Internet Information Services (IIS) is an integral part of every server running Exchange 2003
Server. IIS hosts essential components that Exchange Server 2003 must have to function as
a messaging system. The Internet Server Application Programming Interface (ISAPI)
applications, which Exchange Server 2003 adds to the Web service, for example Outlook
Web Access, Outlook Mobile Access, and Exchange ActiveSync, provide users with access to
Exchange over a variety of HTTP-based protocols. The Web service is also responsible for
RPC over HTTP communication, if your users use this communication mechanism to access
their mailboxes over the Internet without a virtual private network (VPN) connection. IIS hosts
the SMTP service, which implements the central transport engine of Exchange 2003. IIS also
52
hosts the NNTP, IMAP4, and POP3 protocol engines that provide Internet users with access
to messaging data over most Internet access protocols. The File Transfer Protocol (FTP)
service is the only IIS protocol service that is not relevant for Exchange 2003, because FTP is
not a messaging protocol.
The following figure illustrates how SMTP, NNTP, IMAP4, POP3, Outlook Web Access,
Outlook Mobile Access, and Exchange ActiveSync are integrated into the architecture of
IIS 6.0.
Exchange Server 2003 components in the IIS 6.0 architecture
Exchange Server 2003 relies on the following key components in IIS 6.0:
• Inetinfo.exe Inetinfo.exe is a user-mode component that runs the main IIS

process and hosts most of the protocol engines of IIS 6.0. These components include
FTP, SMTP, NNTP, IMAP4, and POP3. The Admin service also runs in the context of
the Inetinfo.exe process. It is important to understand, however, that the World Wide
Web Publishing service does not run in Inetinfo.exe. The architecture of IIS 6.0 is
redesigned to run the Web service in its own processing context for fault-tolerance,
performance, and security reasons.
• Metabase The metabase is a data store that holds IIS configuration data. The
metabase is a plain-text .xml file that can be edited manually or programmatically.
You can find the metabase.xml file in the \Windows\System32\Inetsrv directory. For
more information on the metabase, see Protocol Virtual Servers in Exchange Server
2003.
• IIS Admin service The IIS Admin service (IIS Admin) manages the IIS
metabase and updates the registry for the Web service, FTP service, SMTP service,
53
POP3 service, IMAP4 service, and NNTP service. IIS Admin 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. For more
information on the metabase update service, see Exchange Server 2003 and Active
Directory.
The registry key for the IIS Admin service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin. IIS Admin depends
on Remote Procedure Call (RPC) service and Security Accounts Manager service. All
other IIS services depend on the IIS Admin service. IIS Admin is implemented in
Iisadmin.dll, which resides by default in the \Windows\System32\Inetsrv directory.
Note:
The IIS Admin service must be running on every server running Exchange
Server 2003.
• SMTP Service The SMTP service runs the SMTP protocol engine that accepts
incoming SMTP messages on TCP port 25 by default and sends messages to other
hosts using SMTP. On a server running Exchange Server 2003, the SMTP service
also controls the core transport engine. The SMTP service is included with Windows
Server 2003 and is extended by Exchange Server 2003. For more information about
the SMTP transport architecture, see SMTP Transport Architecture.
The registry key for the SMTP service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSvc. The SMTP service
runs in the context of the Inetinfo.exe process and depends on the Event Log service and
IIS Admin service. The SMTP service is implemented in Smtpsvc.dll, which resides by
default in the \Windows\System32\Inetsrv directory.
Note:
Although no other services depend on the SMTP service, the SMTP service must
be running on every Exchange Server 2003, because the entire Exchange
Server 2003 messaging system depends on it.
• POP3 Service The POP3 service is included with Exchange Server 2003 and
provides Internet users with access to their mailboxes through Post Office Protocol
version 3. Clients, such as Outlook Express, can download messages through POP3
when the user has the required permissions and when the POP3 service is running
on the server running Exchange Server. The POP3 service provides access only to
the Inbox folder. Other mailbox folders or public folders are not accessible.
The registry key for the POP3 service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc. The POP3 service
runs in the context of the Inetinfo.exe process and depends on the IIS Admin service so
that it can be controlled in IIS. The POP3 service is implemented in Pop3svc.dll, which
54
resides by default in the \Program Files\Exchsrvr\Bin directory. The POP3 service is

disabled by default.
Note:
Because no other Exchange services depend on the POP3 service, the POP3
service is not required to be running if users do not use POP3 clients to access
their mailboxes.
• NNTP Service The NNTP service enables an Exchange Server 2003 server to
host NNTP newsgroups (such as discussion groups) based on public folders.
Because this feature complies fully with the NNTP protocol, users can use any
newsreader client to participate in newsgroup discussions. If the NNTP service runs
on a server running Exchange Server 2003, the NNTP service can also be used to
replicate newsgroups with other NNTP hosts through newsfeeds. The NNTP service
is included with Windows Server 2003 and is extended by Exchange Server 2003.
The registry key for the NNTP service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NNTPSvc. The NNTP service
runs in the context of the Inetinfo.exe process and depends on the Event Log service and
the IIS Admin service. The NNTP service is implemented in Nntpsvc.dll, which resides by
default in the \Windows\System32\Inetsrv directory. The NNTP service is disabled by
default.
Note:
Because no other Exchange services depend on the NNTP service, the NNTP
service is not required to be running if you do not replicate newsgroups with other
NNTP hosts and if users do not use newsreader clients to access public folders.
• IMAP4 Service The IMAP4 service ships with Exchange Server 2003 and
enables Internet users to access their mailboxes and public folders through the
Internet Mail Access Protocol version 4. Clients, such as Outlook Express, can
download messages through IMAP4 when the user has the required permissions and
when the IMAP4 service is running on the server running Exchange Server. IMAP4
users can also work with messages directly on the server.
The registry key for the IMAP4 service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc. The IMAP4 service
runs in the context of the Inetinfo.exe process and depends on the IIS Admin service. The
IMAP4 service is implemented in IMAP4svc.dll, which resides by default in the \Program
Files\Exchsrvr\Bin directory. The IMAP4 service is disabled by default.
Note:
Because no other Exchange services depend on the IMAP4 service, the IMAP4
service is not required to be running if users do not use IMAP4 clients to access
their mailboxes.
55
• World Wide Web Publishing Service The World Wide Web Publishing service,
included with Windows Server 2003, is a user-mode configuration and process
manager, which manages the IIS components that process HTTP requests and run
Web applications, such as Outlook Web Access, Outlook Mobile Access, and
Exchange ActiveSync. The Web service is also a monitoring component, which
periodically checks the Web applications to determine if these applications are
running or have stopped unexpectedly. The Web service comes with Windows
Server 2003. Exchange Server 2003 extends this service with ISAPI components for
Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync.
The registry key for the World Wide Web service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc. Unlike all other IIS
services, the Web service does not run in the context of the Inetinfo.exe process. If you
check the ImagePath parameter under the W3Svc registry key, you see that the Web
service runs in the context of the Svchost.exe process, which is a generic host process
for services that are implemented in DLLs. The Web service is implemented in
Iisw3adm.dll.
The Web service runs in an Svchost.exe service group called IISSvcs. Svchost.exe uses
service groups to run separate services together in a single instance of Svchost.exe.
Multiple instances of Svchost.exe can run on a server and each Svchost.exe session can
contain a separate group of services. Svchost groups are listed in the following registry
key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost.
Each entry under this key is a REG_MULTI_SZ parameter that represents a separate
Svchost group. Each value contains the service names that run together in a service
group. If you check the value of the IISSvcs entry, you see that the Web service is the
only service in the IISSvcs group.
• World Wide Web Worker Process All Web application processing, including
loading of ISAPI filters and extensions, as well as authentication and authorization, is
done by a World Wide Web worker process. The worker process executable is called
w3wp.exe. Each worker process provides complete isolation from system
components and other Web applications, and receives requests directly from the
HTTP.sys kernel-mode driver.
• Application Pool An application pool is a request queue within HTTP.sys that is

used by one or more worker processes. In other words, an application pool can serve
requests for one or more unique Web applications. These Web applications are
assigned to the application pool based on their URL. Each application pool is
separated from other application pools by process boundaries. An application that is
assigned to one application pool is not affected by other application pools, and that
application cannot be routed to another application pool while being serviced by the
current application pool.
56
All necessary HTTP application run-time services, such as ISAPI extension support, are
equally available in any application pool. This design prevents a malfunctioning Web
application or Web site from disrupting other Web applications (or other Web sites)
served from other worker processes on that server. It is now possible to unload in-
process components without having to stop the entire Web service. The host worker
process can be paused temporarily without affecting other worker processes that are
communicating with Web browsers or other Web applications. An application pool can
also leverage other operating system services that are available at the process level (for
example, CPU throttling).
Note:
Applications can be assigned to another application pool in the IIS Manager
snap-in while the server is running. IIS supports up to 20,000 application pools
per server.
• HTTP.sys This is the kernel-mode component for HTTP listening, routing,

queuing, and caching. HTTP.sys is a single point of contact for all incoming HTTP
requests. It provides high-performance connectivity for HTTP server applications.
The driver sits on top of TCP/IP and registers itself for all Windows sockets (IP/port
combinations) on which incoming connection requests are received. HTTP.sys is also
responsible for overall connection management, bandwidth throttling, and Web
server logging.
HTTP.sys maintains a queue for each application pool so that the individual HTTP
requests are routed to the correct user-mode worker processes serving an application
pool. If a user-mode worker process quits unexpectedly, HTTP.sys continues to accept
and queue requests, provided the Web service is still running. HTTP.sys continues to
accept requests and queues them on the appropriate queue until there are no queues
available, there is no space left on the queues, or the Web service has been shut down.
Once the Web service notices the failed worker process, it starts a new worker process, if
there are outstanding requests waiting to be serviced for the worker process's application
pool. Thus, while there might be a temporary disruption in user-mode request processing,
the user does not experience the failure because requests continue to be accepted and
queued.
Core Exchange Server 2003 Services

The following figure illustrates the core components of Exchange Server 2003, together with
their service dependencies. Core components are System Attendant, the Exchange
Information Store service, the IIS Admin service, the SMTP service, and the Exchange
installable file system (ExIFS). All of these services must be running on every
Exchange Server 2003 server to guarantee a fully functioning messaging system.
57
Core Windows services and their dependent core Exchange Server 2003 services
IIS Admin service and SMTP service are integrated with IIS, as discussed in the previous
section. The SMTP service must run on every server running Exchange Server 2003 because
all messages sent to or from local recipients must pass through the SMTP transport engine. If
the SMTP service is stopped or unavailable, Exchange Server 2003 cannot deliver
messages. For more information about the routing architecture of Exchange Server 2003,
see Message Routing Architecture.
The core components of Exchange Server 2003 have the following responsibilities.
• Microsoft Exchange System Attendant service System Attendant is one of

the most important services in Exchange Server 2003. This component has many
responsibilities, including maintaining communication with Active Directory,
generating offline address lists, performing message tracking, and so forth. The
executable file is Mad.exe and is located in the \Program Files\Exchsrvr\Bin directory.
There are several registry keys that System Attendant uses for its various internal
components under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\, such
MSExchangeSA, MSExchangeDSAccess, MSExchangeAL, MSExchangeFBPublish, MSExchangeMU,
and MSExchangeADDXA.
The following table lists the responsibilities of System Attendant.

58
Internal System Attendant components and their responsibilities
Component Responsibility Comments
DSAccess Component Locating domain controllers System Attendant must find

in the network and providing domain controllers and global
other Exchange services with catalogs in the network, so
Active Directory information that the Exchange services
can access recipient and
configuration information. To
find domain controllers,
System Attendant uses ADSI
to do a server-less binding.
To proxy directory access
from other Exchange
components, such as
Exchange store and SMTP
transport engine, to
Active Directory, System
Attendant includes a
DSAccess component
(DSAccess.dll). DSAccess
also caches directory
information to reduce the
number of queries to
Active Directory. For more
information about roles of
domain controllers and global
catalogs, and DSAccess, see
Exchange Server 2003 and
Active Directory.
59
DSProxy Component Proxying legacy MAPI clients System Attendant's DSProxy

to Active Directory component (Dsproxy.dll)
refers Outlook 2000 and later
versions to a global catalog
server so that the MAPI client
can communicate with
Active Directory to get access
to the global address list.
DSProxy also relays directory
communication for older
MAPI clients that cannot be
referred directly. For more
information about DSProxy
see Exchange Server 2003
and Active Directory.
Free/Busy Component Maintaining free/busy System Attendant is involved

information for Outlook Web when publishing free/busy
Access users information in Outlook Web
Access. When a user creates
an appointment, the
Exchange store extracts the
free/busy information from the
user's calendar and sends the
data in a message to the
System Attendant mailbox.
The free/busy component
(Madfb.dll) processes these
messages and publishes the
free/busy information in the
SCHEDULE+ FREE BUSY
system public folder. For
more information about
publishing free/busy
information, see Exchange
Information Store Service
Architecture.
60
Mailbox Manager Component Managing mailboxes The mailbox manager

component enforces
message retention policies
and mailbox quotas that you
can use to manage mailbox
store sizes.
Metabase update service Replicating settings from The Directory Service to

Active Directory to the IIS metabase update service
metabase (Ds2mb.dll) is an internal
component of System
Attendant. The Metbase
Update Service replicates
protocol settings from
Active Directory to the IIS
metabase to apply Internet
protocol settings that you
configure in Exchange
System Manager to the
Internet protocol engines,
such as the SMTP service.
For more information about
the metabase update service,
61
Offline Address Book Generating offline address The offline address book
Generator books generator (Oabgen.dll)
creates address lists in the
Exchange store on an offline
address list server. Users can
then connect to this server
and download the offline
address lists. Offline address
lists provide access to
address information when a
user is working remotely and
does not have a permanent
connection to the server.
Because offline address lists
are stored in a hidden public
folder, it is possible to
replicate the offline address
lists to multiple servers.
Recipient Update Service Applying recipient policies The Recipient Update Service
and generating proxy (Abv_dg.dll) is the System
addresses Attendant component that
monitors all mail-enabled user
objects and recipient policies,
and applies recipient policies
to mail-enabled user objects.
For more information about
the Recipient Update Service,
62
Server Monitor Component Monitoring server resources System Attendant monitors

server resources at periodic
intervals and updates link
state information (LSI)
through Windows
Management Instrumentation
(WMI). System Attendant also
updates the routing table so
that the routing engine can
make informed routing
decisions based on the
current status of servers and
connectors. For more
information about link state
information, see Message
Routing Architecture.
System Attendant is also

responsible for maintaining
the message tracking logs if
message tracking has been
enabled on a server.
System Attendant Verifies computer account The computer account of an

Component configuration Exchange server must be a
member of a global security
group called Exchange
Domain Servers to grant
Exchange Server 2003 the
required access permissions
to Active Directory. System
Attendant verifies, in the
background, that the
computer account belongs to
this group.
• Exchange Information Store service The Microsoft Exchange Information

Store service is another very important component in Exchange Server 2003,
because it maintains the messaging databases that contain all server-based
mailboxes and public folders. The executable file of the Exchange Information Store
service is Store.exe, located in the \Program Files\Exchsrvr\Bin directory. The
63
corresponding registry key is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS.
The Exchange store uses Extensible Storage Engine (ESE) to maintain the messaging
databases and supports a variety of clients through corresponding store extensions. The
following figure illustrates how the various client types can access messaging data.
Exchange store architecture and supported messaging clients
MAPI clients communicate directly with the Exchange Information Store service through
MAPI RPCs. Internet clients, however, use protocol engines integrated with IIS, as
explained earlier in this section. Internet clients and Web applications communicate with
the Exchange store through IIS protocol engines. This communication takes place
through a store driver, Epoxy.dll, and store extensions, such as ExSMTP.dll or
ExIMAP.dll. The EPOXY layer is a fast inter-process communication (IPC) mechanism
based on shared memory, which is used by Drviis.dll and store extensions to coordinate
64
their processing. For example, when delivering an inbound message through SMTP,
Drviis.dll uses the Exchange installable file system to create a message item in the
Exchange store, and then communicates with ExSMTP.dll through EPOXY to instruct the
Exchange store to further process the message (that is, to place the message into the
recipient's mailbox). For more information about the interaction between Drviis.dll,
Epoxy.dll, store extensions, Store.exe and ExIFS, see Exchange Information Store
Service Architecture.
• Exchange Installable File System The Exchange installable file system is a

kernel-mode driver, implemented in ExIfs.sys, which IIS protocol engines and Web
applications can use to read and write items from and to messaging databases. To
gain access to the databases, the ExIFS file system driver must communicate with
the Exchange store. This is accomplished through a store extension (ExWin32.Dll)
and a user-mode wrapper (Ifsproxy.dll). The Exchange store, on the other hand, uses
ESE to access .stm and .edb files, which are files that reside on a drive formatted
with the NTFS file system. The following figure illustrates this architecture.
The ExIFS architecture
As mentioned in Exchange Server 2003 Technical Overview, a mailbox store or public

folder store is made up of a streaming database (.stm) and a MAPI database (.edb). The
IIS components use ExIFS to work with streaming databases, while MAPI clients, such
as Outlook, work with MAPI-based databases (.edb). A streaming database holds Internet
messages in their native format, such as MIME, while an .edb database stores e-mail
messages in MAPI format. The Exchange store must keep both the streaming databases
and the corresponding MAPI-based databases synchronized. To accomplish this, the
Exchange store must communicate with ExIFS, in addition to ESE. For example, when
allocating free space in a database, ExIFS requests space from ESE. ESE must track
which pages in the streaming database are reserved and committed. Thus, the Exchange
65
Information Store service depends on ExIFS. The registry key for ExIFS is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS. For more information
about ExIFS and the architecture of the Exchange store, see Exchange Information Store
Service Architecture.
Note:
ExIFS is the only kernel-mode component in Exchange Server 2003.
Additional Exchange Server 2003 Services

In addition to IIS protocol engines and Exchange Server 2003 core services, the following
Exchange services provide additional functionality:
• Calendar Connector The Calendar Connector service enables the sharing of

free/busy information between Exchange Server 2003 users and Lotus Notes or
Novell GroupWise users. This service depends on the event log, Exchange
Information Store service, and Microsoft Exchange Connectivity Controller. For more
information about the architecture of Calendar Connector, see Gateway Messaging
Connectors Architecture.
The executable file is Calcon.exe, which resides in the \Program Files\Exchsrvr\Bin

directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCalCon.
• Connectivity Controller The Connectivity Controller service provides support

services for Connector for Lotus Notes, Connector for Novell GroupWise, and
Calendar Connector. This service depends on the Event Log service and System
Attendant. For additional information about the architecture of Connectivity Controller,
see Gateway Messaging Connectors Architecture.
The executable file is Lscntrl.exe, which resides in the \Program Files\Exchsrvr\Bin

directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCOCO.
• Connector for Lotus Notes The Connector for Lotus Notes service enables
the transfer of messages and directory synchronization between Exchange
Server 2003 and Lotus Notes. This service depends on Event Log, Connectivity
Controller, and the Exchange Information Store service. For more information about
the architecture of Connector for Lotus Notes, see Gateway Messaging Connectors
Architecture.
The executable file is Dispatch.exe, which is started with LME-NOTES command-line

parameters to launch Lotus Notes-specific connector processes. Dispatch.exe resides in
the \Program Files\Exchsrvr\Bin directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-NOTES.
66
• Connector for Novell GroupWise The Connector for Novell GroupWise

service enables the transfer of messages and directory synchronization between
Exchange Server 2003 and Novell GroupWise. This service depends on Event Log,
Connectivity Controller, Router for Novell GroupWise, and the Exchange Information
Store service. For more information about the architecture of Connector for Novell
GroupWise, see Gateway Messaging Connectors Architecture.
The executable file is Dispatch.exe, which is started with LME-GWISE command-line

parameters to launch Novell GroupWise-specific connector processes. Dispatch.exe
resides in the \Program Files\Exchsrvr\Bin directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-GWISE.
• Exchange Event service The Exchange Event service monitors folders and
triggers events for server scripts that are compatible with Exchange Server 5.5. This
service is required only when you are running Exchange Server 5.5 compatible
applications on a server running Exchange Server 2003. It is disabled by default. This
service depends on the Exchange Information Store service. The executable file is
Events.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The registry
key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeES.
• Exchange Management service This service provides Exchange management

information using Windows Management Instrumentation (WMI). If this service is
stopped, WMI providers implemented to work in Microsoft Exchange Management,
such as message tracking and Active Directory access, will not work. For this reason,
you should leave this service running on all servers running Exchange Server, so that
you can view and set the domain controllers and global catalog servers for an
Exchange Server 2003 server, and use the message tracking center to audit
message flow through Exchange. To provide directory access, you can use
Exchange System Manager to manually configure a domain controller or global
catalog server (open the server's Properties page, then use the options on the
Directory Access tab). The servers running Exchange Server will then use the
specified servers to access the directory.
The Exchange Management service depends on the Remote Procedure Call (RPC)
service and the Windows Management Instrumentation (WMI) service. The executable
file is Exmgmt.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The
registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMGMT.
• Microsoft Exchange MTA Stacks service 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.
67
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.
Note:
You should leave the Microsoft Exchange MTA Stacks service running, so that
server monitors in their default configuration do not report a server running
Exchange Server as unavailable. For more information about server status
tracking, see Exchange System Manager Architecture.
• Router for Novell GroupWise The Router for Novell GroupWise service works
in conjunction with Connector for Novell GroupWise to transfer messages and
perform directory synchronization between Exchange Server 2003 and Novell
GroupWise. The Router for Novell GroupWise service interfaces with the Novell
GroupWise API gateway, while Connector for Novell GroupWise interfaces with
Exchange Server 2003. For more information about the architecture of Connector for
Novell GroupWise, see Gateway Messaging Connectors Architecture.
The Router for Novell GroupWise service depends on System Attendant. The executable
file is GWRouter.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The
registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeGWRtr.
• Routing Engine The Routing Engine service provides topology and routing
information to servers running Exchange Server 2003. The advanced queuing engine
within the SMTP transport subsystem uses this service to provide next-hop
information when routing messages within the Exchange organization. If this service
is stopped, optimal routing of messages is not available. For additional information on
the Routing Engine service and its role in message delivery, see SMTP Transport
Architecture.
The Routing Engine service depends on IIS Admin and runs within the Inetinfo.exe
process. This service is implemented in a file called RESvc.dll, which resides in the
\Program Files\Exchsrvr\Bin directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc.
• Site Replication Service Site Replication Service (SRS) provides directory

integration between Exchange Server 5.5 and Exchange Server 2003. SRS runs on
Exchange Server 2003 and serves as a modified Exchange Server 5.5 directory.
Exchange server 5.5 responds to SRS as another Exchange Server 5.5 directory
replication partner. SRS is automatically enabled on the first server that joins an
Exchange Server 5.5 site. When you remove the last server running Exchange
Server 5.5 from the network, you can disable SRS.
68
SRS has no service dependencies. This service is implemented in an executable file

called srsmain.exe, located in the \Program Files\Exchsrvr\Bin directory. The registry key
is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS.
The following figure illustrates how the additional services integrate with the core services of
Exchange, IIS, and the operating system.
Core and additional services of Exchange Server 2003
Tip To stop all Exchange Server 2003 services on a server, you must stop System
Attendant, IIS Admin service, ExIFS, and SRS (if this service is running), and all dependent
services. For detailed instructions about how to stop all Exchange Server 2003 services on a
server, see How to Stop All Exchange Server 2003 Services on a Server.
69
How to Stop All Exchange Server 2003

Services on a Server
This topic explains how to stop all Exchange Server 2003 services on a server.
Before You Begin

Before you perform the procedure in this topic, consider the following:
• To stop all Exchange Server 2003 services on a server. you must stop System
Attendant, IIS Admin service, ExIFS, and SRS (if this service is running), and all
dependent services. The easiest way to restart all services is to reboot the server.
Procedure
Stop all Exchange Server 2003 services on a server
1. Use the command net stop MSExchangeSA /y to stop System Attendant
and all its dependent services.
2. Use the command net stop IISAdmin /y to stop all IIS engines.
3. Use the command net stop ExIFS to stop the Exchange installable file
system (ExIFS) driver.
4. Use the command net stop MSExchangeSRS to stop SRS.
Exchange Server 2003 and Active Directory

Microsoft Exchange Server 2003 relies entirely on the Microsoft Active Directory directory
service for its directory operations. Active Directory provides all mailbox information, address
list services, and other recipient-related information. Most of Exchange 2003 configuration
information is also stored in Active Directory. System Attendant is the component in
Exchange 2003 that is responsible for managing directory access. System Attendant includes
various internal components, such as DSAccess and DSProxy, which communicate with
Active Directory and cache directory information to increase the speed with which directory
information is retrieved and to reduce the workload on domain controllers and global catalog
servers.
This section describes the directory access components of Exchange Server 2003, their
purpose, their architecture, and how the core technology works. This information can help
70
you maintain directory access and troubleshoot directory access issues. This section
discusses the following concepts:
• Extension of the Active Directory schema Exchange extends the

Active Directory schema and leverages Active Directory for recipient and
configuration information.
• Differences between domain controllers and global catalog servers A

global catalog server is always a domain controller, but the reverse is not always true.
The differences are discussed in this section, including why Exchange Server 2003
must communicate with domain controllers and global catalog servers.
• Directory Service Access component in Exchange Server 2003 The

Directory Service Access (DSAccess) component is an internal component of System
Attendant that is used to access and store directory information. DSAccess statically
or dynamically detects directory service servers in your organization.
• DSProxy component in Exchange Server 2003 DSProxy enables

communication between Active Directory and Exchange 2003 computers. DSProxy
provides both proxy and referral services to MAPI clients, such as later versions of
Microsoft Office Outlook.
• SMTP categorizer in the Exchange transport engine The SMTP categorizer

must communicate with Active Directory to resolve recipient information and
determine message restrictions during message transfer. Although the categorizer
relies on DSAccess, it also uses its own mechanism to communicate with
Active Directory.
• Recipient Update Service Exchange Server 2003 communicates with directory

servers to update recipient objects (such as mailbox-enabled user accounts or mail-
enabled groups) with e-mail addresses, according to the recipient policies defined for
the organization.
• Metabase update service The metabase update service must communicate

with Active Directory to obtain configuration settings that relate to Internet Information
Services (IIS) components, such as the Simple Mail Transfer Protocol (SMTP)
service and the World Wide Web service. It is the task of the metabase update
service to transfer these settings into the IIS metabase.
For more information about planning, designing, and deploying Exchange 2003, see the
following guides:
• Planning an Exchange Server 2003 Messaging System
• Exchange Server 2003 Deployment Guide

71
Directory Integration and Exchange Server

2003
Exchange Server 2003 information in Active Directory includes information about recipients
and configuration information about the messaging organization. Active Directory helps
provide the security subsystem for Exchange Server 2003. Active Directory security ensures
that only authorized users can access mailboxes and only authorized administrators can
modify the Exchange configuration in the organization.
The following three directory partitions in Active Directory contain Exchange-related data:
• Domain directory partition Exchange recipient and system objects are stored
in the domain directory partition in Active Directory. The domain directory partition is
replicated to every domain controller in a particular domain.
• Configuration directory partition Exchange configuration objects, such as

administrative groups, global settings, recipient policies, system policies, and address
list or address information are stored in the configuration directory partition. The
configuration directory partition is replicated to all domain controllers in the forest.
• Schema directory partition Exchange schema modifications (for example,

classes and attributes) are stored in the schema directory partition. The schema
directory partition is replicated to all domain controllers in the forest.
Note:
Not all configuration information is stored in Active Directory. Exchange also uses the
local registry, the IIS metabase, and in special situations, configuration files.
Exchange Classes and Attributes in

Active Directory
The Active Directory schema defines the object classes that can be created in the directory
and the attributes that can be assigned to each instantiation of an object. During installation
of the first Exchange 2003 server in an Active Directory forest, Exchange must modify this
schema so that Active Directory can store Exchange-specific recipient and configuration
information. The ForestPrep process in the Exchange Setup program extends the
Active Directory schema. You can also run this process explicitly by using the
Setup/ForestPrep command line to add Exchange-specific classes and attributes to the
Active Directory schema, without actually installing a server. This extra step is required if the
person installing Exchange Server 2003 does not have schema administrator rights.
The Exchange Server 2003 Setup program extends the Active Directory schema by importing
a series of .ldf files into Active Directory. Except for Exschema.ldf, all .ldf files are in the
72
\Setup\i386\Exchange directory on the product CD. Exschema.ldf is in the

\Setup\i386\Exchange\Bin directory.
The following table lists the various .ldf files that define the objects and attributes for
Exchange Server 2003.
Exchange Server 2003 installation files with Active Directory schema extensions
File Name Description
Schema0.ldf Includes schema extensions for recipient

objects, such as the definition of Exchange
extension attributes, which you can use to
assign information, not covered by any one of
the standard attributes, to recipient objects.
Schema1.ldf Includes schema extensions for

Active Directory Connector, which you can
use to integrate an Exchange Server 5.5
organization with Active Directory.
Schema2.ldf Includes schema extensions for Internet

access protocols, directory synchronization,
and Exchange store configuration objects.
Schema3.ldf Includes schema extensions for system

monitoring, Connector for Lotus Notes
configuration objects, offline address book
settings, and settings that belong to X.400
connectors.
Schema4.ldf Includes schema extensions for routing

groups, bridgehead servers, protocol
containers, messaging databases, address
list services, and Microsoft Exchange MTA
configuration objects.
Schema5.ldf Includes schema extensions for protocol

containers, routing group connectors, and
parameters that pertain to Extensible Storage
Engine (ESE).
Schema6.ldf Includes schema extensions for protocol

virtual servers, administrative groups,
messaging connectors, and the Exchange
store.
73
File Name Description
Schema7.ldf Includes schema extensions for messaging

databases and mailbox manager.
Schema8.ldf Includes schema extensions for mailbox

manager, system monitoring, public folders,
and SMTP transport configuration objects.
Schema9.ldf Includes schema extensions for Calendar

Connector, Connector for Novell GroupWise,
dynamic distribution lists, messaging folders,
and Outlook Mobile Access.
Note:
Schema1.ldf through Schema8.ldf are
identical for Exchange 2000 Server
and Exchange Server 2003.
Schema9.ldf contains the schema
extensions that are new in Exchange
Server 2003.
Exschema.ldf Adds the Object-GUID, Replication-Signature,

Unmerged-Attributes, and ADC-Global-
Names attributes to the schema to update a
pre-Exchange 2000 Service Pack 1 schema
with the information required for Exchange
Server 2003.
Note:
You can use .ldf files in conjunction with low-level Active Directory tools, such as
Ldifde.exe, to repair a damaged Active Directory schema. Troubleshooting the Active
Directory schema, however, is beyond the scope of this book. Note that schema
changes might reset the global catalog, in which case all recipient objects must be
replicated again to the global catalog. This can cause significant increases in data
traffic in large organizations.
Directory Service Access

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. A central component is required to streamline communication
with Active Directory. This component is the DSAccess module.
74
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, including System Attendant, message transfer agent, Microsoft Exchange
Information Store service, Exchange Management Service, Internet Information Services (IIS)
and 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.
Important:
DSAccess.dll is the primary DLL that implements DSAccess. To operate correctly, the
DSAccess.dll version must match the version of its companion DLLs. The companion
DLLs, Dscmgs.dll and Dscperf.dll, store event log message strings and performance
object providers, respectively.
DSAccess partitions the available directory service servers into the following three (possibly
overlapping) categories:
• Global catalog servers Exchange Server 2003 must access global catalog
servers to obtain complete address information for all recipient objects in the forest.
Only global catalog servers contain a complete replica of all objects in the domain
and a partial replica of all objects in the forest. Global catalog servers that an
Exchange server currently uses are called working global catalog servers.
Almost all Exchange Server 2003 user-context directory service transactions target global
catalogs. Regardless how many global catalog servers are located in the local
Active Directory site, a maximum of ten global catalog servers can be added to the
working global catalog list. If there are no global catalog servers in the local site, or if
none of the global catalog servers in the local site pass the suitability tests, DSAccess
uses a maximum of 200 off-site global catalog servers with the lowest costs. Because the
directory service server used for a global catalog is also itself a domain controller, this
server may be used as both types of directories.
• Domain controllers Domain controllers are used for user-context requests

when the requesting service has sufficient knowledge of the location of the requested
user object in the issued search. These domain controllers are also called working
domain controllers. Working domain controllers are domain controllers in the local
domain that can accept domain naming-context queries. Regardless of how many
domain controllers are located in the local Active Directory site, a maximum of ten
domain controllers can be added to the working domain controller list. If there are no
domain controllers in the local site, or if none of the domain controllers in the local
site pass the suitability tests, then DSAccess uses off-site domain controllers with the
lowest costs.
75
Queries to working domain controllers are load-balanced on a round robin basis to avoid
overloading a single domain controller. If the working domain controllers are not hard-
coded in the registry, the list of working domain controllers is re-evaluated and re-
generated every 15 minutes using the topology discovery process and suitability tests.
• Configuration domain controllers Exchange Server 2003 can read from

multiple domain controllers. To avoid conflicts when applying configuration changes
to Active Directory, Exchange Server 2003 writes its configuration information to a
single domain controller, called the config domain controller. When selecting a config
domain controller from the list of working domain controllers, DSAccess gives
preference to a domain controller over a global catalog server. In addition, DSAccess
preferences a directory server in the local site before using a directory server in a
secondary site.
If the config domain controller becomes unavailable to Exchange Server 2003 for any
reason, DSAccess selects another working domain controller as its config domain
controller. Every eight hours, DSAccess re-evaluates the config domain controller role by
running a set of suitability tests. If the tests are successful, DSAccess continues to use
the same config domain controller. If the tests fail, DSAccess chooses another domain
controller from the list of working domain controllers as the config domain controller.
The core components of Exchange Server 2003 rely on DSAccess to provide a current list of
Active Directory servers. For example, the message transfer agent (MTA) routes LDAP
queries through the DSAccess layer to Active Directory. To connect to databases, the store
process uses DSAccess to obtain configuration information from Active Directory. To route
messages, the transport process uses DSAccess to obtain information about the connector
arrangement.
DSAccess updates the list of available global catalogs and domain controllers as changes in
the state of the directory service are detected. This list can be shared with other directory
consumers that do not use DSAccess as their gateway for accessing the directory service (for
example, DSProxy and other components in System Attendant). The service that is
requesting this list is responsible for the detection of subsequent directory service state
changes.
Note:
Unless domain controllers and global catalog servers are hard-coded in the registry,
the list of global catalog servers and domain controllers is re-evaluated and re-
generated every 15 minutes using a topology discovery process and suitability tests.
LDAP Connection Load-Balancing and Failover

In Exchange Server 2003, DSAccess determines the Active Directory topology, opens the
appropriate LDAP connections, and works around server failures. For each available
directory service server, DSAccess opens LDAP connections solely dedicated to each
76
process that uses DSAccess. DSAccess updates these LDAP connections with directory
service state information (Up, Slow, or Down) that it detects. DSAccess uses this state
information to decide which LDAP connection to use to forward requests to Active Directory.
The set of LDAP connections to available domain controllers and global catalog servers and
their associated states forms the DSAccess profile.
DSAccess supports a load-balancing mechanism that distributes user context directory

service requests in a round robin fashion among the LDAP connections in the DSAccess
profile. Load balancing helps ensure reliability and scalability. You can statically configure all
profiles in the registry to use only a specific set of directory service servers. However, the
actual state and load balancing of these connections may differ from process to process
(profile to profile). This is not the case for configuration context requests.
Note:
Because all Exchange Server 2003 and IIS services use the same security context
(the LocalSystem account), it is possible for DSAccess to reuse the LDAP
connections from one request to another. At startup or a topology change, DSAccess
opens LDAP connections to all suitable domain controllers and global catalog servers
in the topology.
When the Microsoft Windows-based implementation of LDAP (WLDAP), returns an error on

an LDAP operation, DSAccess analyzes it and determines if it indicates that the directory
server is experiencing problems. If so, the directory server is immediately marked as
unsuitable, and the user operation is automatically retried on a different server. If there is at
least one working domain controller in the topology, DSAccess can continue with flawless
operation.
To verify the suitability of a domain controller or global catalog server, DSAccess determines
that the server is reachable over port 389 (domain controller) and port 3268 (global catalog
server) and that it resides in a domain that was prepared with DomainPrep. DomainPrep
ensures that the group policy system access control list (ACL) is configured correctly to grant
Exchange Server 2003 services access to Active Directory. Server suitability checks are
covered later in this section.
Note:
To obtain suitability reports in the application event log, you can enable diagnostics
logging for the topology category of the DSAccess service in Exchange System
Manager.
The DSAccess topology always contains two lists, the in-site list and the out-of-site list. One
list (in-site) contains servers from the local Active Directory site of the Exchange server and
the other list (out-of-site) contains servers from other Active Directory sites. Initially,
DSAccess uses only servers from the local site, but when all local servers from a certain
category (for example, global catalog servers) are not suitable, DSAccess immediately starts
using the out-of-site list. DSAccess then keeps checking the local site every five minutes and
77
fails back as soon as it is possible. User requests are retried on the out-of-site servers
immediately and seamlessly for users.
Some Exchange Server 2003 components, such as the Exchange Routing Engine service,
also register with Active Directory to be automatically informed by Active Directory of any
changes to configuration information. This notification mechanism eliminates polling, but the
event registration is per target server. If DSAccess marks the target server as down, it
reissues the event registration and informs the client process, such as the Routing Engine
service, of a change, because the monitored values could have changed during the process
of selecting a new domain controller or global catalog server.
DSAccess Topology Discovery

At startup, DSAccess uses a discovery process to identify the Active Directory topology and
assess the availability of domain controllers and global catalog servers. After startup is
complete (and every 15 minutes thereafter), DSAccess uses an almost identical process to
rediscover the topology and to check for any changes in server availability.
Note:
If you hard-code the directory servers that are used by DSAccess (as described
below), DSAccess bypasses the discovery process and checks for server suitability
only.
The following sequential list outlines the discovery process and indicates differences between
initial discovery and rediscovery:
1. The System Attendant process (Mad.exe) instantiates and initializes

DSAccess.dll during startup.
2. From the local domain, DSAccess opens an LDAP connection to a randomly

chosen domain controller. This server is referred to as the bootstrap server.
3. DSAccess reads the local registry to determine if the topology is hard-coded. If

the topology is hard-coded, the discovery process stops. If no hard-coding is
detected, DSAccess continues the discovery process.
4. DSAccess queries the bootstrap server to identify local domain controllers and
global catalog servers. DSAccess then determines server suitability and assigns
server roles.
5. DSAccess queries the bootstrap server to determine if one or more secondary

sites are connected to the local site. If secondary sites exist, DSAccess sorts the
siteLink objects for each site from lowest cost to highest cost. DSAccess places the
lowest cost sites in a secondary topology list.
6. DSAccess queries the bootstrap server to identify the domain controllers and
global catalog servers that are located in the secondary topology sites.
78
7. DSAccess identifies the full topology and compiles a list of working domain
controllers, and a list of working global catalog servers.
By default, DSAccess initialization during startup must finish within one minute; otherwise,
DSAccess stops. One minute is usually long enough for DSAccess to initialize. If initialization
takes longer than one minute, this might indicate a problem with the network or topology
configuration. Although you can extend the time-out parameter by setting a registry key, you
should first determine why initialization takes longer than expected. To configure the time-out,
use the following registry setting.
Location HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\MSExchangeDSAc
cess
Value TopoCreateTimeoutSecs
Type REG_DWORD
Description Sets the timeout value for DSAccess

initialization in seconds, such as 0x200. The
default is 0x3C seconds (1 minute).
Note:
If you set the diagnostics logging level for all categories of the
MSExchangeDSAccess service to Maximum, Exchange System Manager
automatically obtains detailed information about the initialization of DSAccess and
places that information in the application event log.
Initial Discovery and Ongoing Rediscovery

After DSAccess discovers the Active Directory topology, it determines whether the discovered
list of working domain controllers and global catalog servers is suitable for use. During initial
discovery and ongoing rediscovery, DSAccess determines server suitability by running a
series of suitability tests. Suitability tests fall into two categories: hard tests and soft tests.
Hard tests determine whether the domain controller or global catalog is a viable candidate for
use. If the server fails the hard tests, it is considered unusable, removed from the list of
discovered servers, and the soft tests are not run.
DSAccess runs the following hard suitability tests:
• Global catalog capabilities DSAccess determines if the directory server is

specifying itself as a global catalog server by determining if the
isGlobalCatalogReady attribute on the RootDSE object of the server is set to TRUE.
If the attribute is set to TRUE, then the directory server is determined to be a valid
and usable global controller.
79
• Reachability DSAccess uses Internet Control Message Protocol (ICMP) to ping

each server to verify that the server is available. DSAccess also verifies that the
directory server is reachable over port 389 (for domain controllers) and port 3268 (for
global catalog servers).
If you use ICMP to determine if a server is available, you might create a problem if all
connections in your network do not support ICMP. For example, an Exchange server
might reside in a perimeter network, which has no ICMP connectivity between the
Exchange server and the domain controllers. In this situation, you should disable the
ICMP check and set the following registry parameter to zero.
cess
Value LdapKeepAliveSecs
Type REG_DWORD
Value Data 0x0
Description DSAccess uses the ping protocol if there is no

registry key does or it is not set to 0,
For more information about the LdapKeepAliveSecs registry key, see Microsoft Knowledge
Base article 320529, "XADM: Using DSAccess in a Perimeter Network Firewall Scenario
Requires a Registry Key Setting."
Caution:
Incorrectly editing the registry can cause serious problems that may require you
to reinstall your operating system. Problems resulting from editing the registry
incorrectly may not be able to be resolved. Before editing the registry, back up
any valuable data.
• Group policy SACL permission Together with the regular access control list
(ACL) permissions, Setup grants all servers running Exchange 2003 Server security
access control list (SACL) permission to view ntSecurityDescriptor attributes.
Permission is granted through the SeSecurityPrivilege privilege. DSAccess reads the
security descriptor of the configuration directory partition object, on the server, to
verify that the SACL is readable. If the SACL cannot be read, DSAccess considers
the server not suitable.
• Critical data The directory server must be located in a domain in which

DomainPrep was run. The domain must contain the Exchange Server 2003 server
object in the Exchange configuration container.
80
• Synchronization DSAccess verifies that the server is synchronized by

determining if the isSynchronized attribute on the rootDSE object of the server is set
to TRUE.
• Netlogon DSAccess sends a DSGetDcName remote procedure call (RPC) to

the directory server to test its general suitability. If the directory server is not
synchronized, is out of disk space, or is experiencing other problems, it will not
identify itself as a directory server.
In a perimeter network, in which RPC traffic is not allowed, the NetLogon check cannot
occur. However, the NetLogon check continues to issue RPCs until it fails, which can take
a long time. Because repeated NetLogon checks decrease performance, you should stop
DSAccess from issuing NetLogon checks by creating the following registry key.
cess
Value DisableNetLogonCheck
Type REG_DWORD
Value Data 0x0
Description If the registry key does not exist or is not set

to 0, DSAccess performs the Netlogon check.
For more information, see Microsoft Knowledge Base article 320228, "XGEN: The
"DisableNetLogonCheck" Registry Value and How to Use It."
• Version of the operating system Exchange Server 2003 can use only domain
controllers and global catalog servers running Microsoft Windows Server 2003 or
Windows 2000 Server Service Pack 3 or later. DSAccess determines whether the
directory server meets these requirements.
After hard tests are complete, DSAccess runs a series of soft tests to determine which
directory servers can accommodate the additional load placed on them by Exchange
Server 2003. To make this determination, DSAccess runs the following soft suitability tests:
• DNS weight DSAccess uses the weight value of the domain controllers and
global catalog servers, as specified in each server's (SRV) resource records in DNS
to determine which server the client should prefer. A higher weight results in a higher
probability that DSAccess will choose a server. If DSAccess cannot read the weight,
it uses a default weight of 100.
• FSMO primary domain controller role owner If your topology contains

servers running Windows NT Server, the directory server with the flexible single
master operation (FSMO) primary domain controller (PDC) role will experience heavy
81
loads, making it a less than ideal candidate for use by Exchange Server 2003. For
this reason, DSAccess performs a soft suitability test to locate the PDC FSMO role
owner, so that it can remove it from the list of suitable directory servers.
• Response time DSAccess performs an LDAP query against the directory

server to check its response time. Response time greater than two seconds is
considered a soft suitability test failure.
Note:
DSAccess includes support for full round robin load balancing and failover to
another directory server, if a currently used server becomes unavailable. These
features are disabled when Exchange Server 2003 is running on a domain
controller or global catalog server.
Hard-Coding DSAccess Servers

DSAccess allows an administrator to statically configure specific domain controllers and
global catalogs for use by DSAccess, and to disable the automatic topology discovery
process. These hard-coding entries are configured using the DSAccess user interface in
Exchange System Manager, as illustrated in the following figure.
82
Directory Access tab in Exchange System Manager
On initialization, DSAccess reads the registry to determine if any domain controllers or global
catalog servers are statically configured. If any domain controllers or global catalog servers
are statically configured, the dynamic topology detection is not performed. If no static
directory servers are identified, DSAccess dynamically detects the directory service servers in
the topology.
When DSAccess is statically configured, the load-balancing and failover features in

DSAccess do not engage, and no other domain catalog or global catalog is used or detected.
As a result, if all of the statically configured domain catalogs or global catalogs are offline or
otherwise unreachable, DSAccess operations fail. If global catalogs are statically configured,
but no domain catalogs are specified in the registry, any available domain controller is
dynamically detected and used. Similarly, if domain catalogs are statically configured, but no
global catalogs are specified in the registry, any available global catalogs are dynamically
detected and used. If the config domain controller is not statically configured, it is removed
83
from the list of available domain controllers (whether this list is dynamically or statically
configured).
DSAccess Profiles
Domain controllers and global catalogs used for user-context requests are profile-dependent.
Therefore, the values in the registry for these settings are located under a
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Defau
ltsubkey. The following registry keys are required to statically configure domain controllers
and global catalog servers for use by DSAccess.
Location MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Value IsGC
Type REG_DWORD
Value Data 0x0
of DC>
Value HostName
Type REG_SZ
Value Data <name of DC>
of DC>
Value DSType
Type REG_SZ
Value Data 0
of DC>
Value PortNumber
Type REG_DWORD
84
Value Data 0x00000185 (389)
of GC>
Value IsGC
Type REG_DWORD
Value Data 0x1
of GC>
Value HostName
Type REG_SZ
Value Data <name of GC>
of GC>
Value DSType
Type REG_SZ
Value Data 0
of GC>
Value PortNumber
Type REG_DWORD
Value Data 0x00000cc4 (3268)
Specifying the Configuration Domain Controller

The config domain controller that is used by DSAccess can be set in one of the following
three ways:
85
• Statically configured in the registry The config domain controller is shared

among all profiles. For this reason, the registry settings for the configuration domain
controller are specified under the \Instance0 subkey as follows.
Location MSExchangeDSAccess\Instance0
Value ConfigDCHostName
Type REG_SZ
Value Data <Name of config DC>
Value ConfigDCPortNumber
Type REG_DWORD
Value Data 0x00000185 (389)
• Dynamically detected If a config domain controller is not specified statically,

DSAccess uses dynamic topology discovery to locate a config domain controller.
DSAccess uses the selected config domain controller for eight hours, after which it
randomly chooses a new config domain controller. DSAccess chooses a new config
domain controller before then if System Attendant is restarted or if the currently
selected config domain controller fails or shuts down.
• By System Attendant on startup In Exchange Server 2003, the System

Attendant process chooses the config domain controller only on the first service start,
which occurs during setup or upgrade. In all cases, the choice by System Attendant is
ignored if the config domain controller is statically configured in the registry.
DSAccess takes a static config domain controller entry as a suggestion. Thus, if the
config domain controller is statically configured, DSAccess prefers it for configuration
context requests. If that domain controller becomes unavailable, an alternative
domain controller is chosen from the list of working domain controllers. In this case,
DSAccess fails over the config domain controller by choosing an available domain
controller and behaving as if the config domain controller registry information is not
present.
How DSAccess Assigns Server Roles

The following examples depict different Active Directory configurations and show how
DSAccess assigns server roles in each case. In these examples, it is assumed that all
domain controllers and global catalogs are running Windows 2000 Server with Service
86
Pack 3 or later, that all suitability tests are passed equally, and that no static domain
controllers are hard-coded (that is, DSAccess performs dynamic topology discovery).
Example 1 – Simple Single Domain Topology

The following figure depicts a single forest with a single domain that is made up of two sites.
Site A contains a single domain controller and a single global catalog, and Site B contains
three domain controllers and two global catalogs.
One domain with two sites
DSAccess running on Exchange Server 2003 servers in Site A will detect the topology shown
in the following table.
Topology for Site A
Domain Controller Type Server
Config domain controller Domain controller 1 or global catalog 1
Working domain controllers Domain controller 1 and global catalog 1
Working global catalogs Global catalog 1
DSAccess running on Exchange Server 2003 servers in Site B will detect the topology shown
87
Topology for Site B
Config domain controllers Domain controllers 2, 3, and 4
Global catalog 2 or 3
Working domain controllers Domain controllers 2, 3, and 4
Global catalogs 2 and 3
Working global catalogs Global catalogs 2 and 3
In each case, the order of the listed servers is important. The servers are listed and used in
the order in which they are discovered by DSAccess and determined to be suitable.
Example 2 – Complex Domain Topology

The following figure depicts a more complex topology, which includes two domains and two
sites, with Site A spanning both domains.
Two domains with a site spanning both domains
DSAccess running on Exchange Server 2003 servers in Domain 1 and Site A will detect the
topology shown in the following table.
88
Topology for Domain 1 and Site A
Config domain controller Domain controllers 1, 2, 3, and 4
Global catalogs 1, 2, or 3
Working domain controllers Domain controllers 1, 2, 3, and 4
Global catalogs 1, 2, and 3
Working global catalogs Global catalogs 1, 3, and 2
DSAccess running on Exchange Server 2003 servers in Domain 2 and Site A will detect the
topology shown in the following table
Topology for Domain 2 and Site A
Config domain controller Domain controllers 1, 2, 3, 4
Global catalogs 1, 2, or 3
Working domain controllers Domain controllers 1, 2, 3, and 4,
Global catalogs 1, 2, and 3
Working global catalogs Global catalogs 2, 1, and 3
DSAccess running on Exchange Server 2003 servers in Domain 2 and Site B will detect the
topology as shown in the following table.
Topology for Domain 2 and Site B
Config domain controller Domain controller 5
Global catalog 4
Working domain controller Domain controller 5
Global catalog 4
Working global catalogs Global catalog 4
Once again the servers are listed and used in the order in which they are discovered and
determined to be suitable.
89
Directory Access Cache

The DSAccess cache is an in-memory cache on the Exchange server that contains
configuration and user records retrieved from Active Directory. Records in the cache are
accessed through the object's Distinguished Name (DN), Globally Unique Identifier (GUID),
or a key constructed from the scope, BaseDN, and the filter used to find this object in
Active Directory. Subsequent accesses using the same DN, GUID, or key will find the record
in the cache. As previously mentioned, DSAccess is a shared API that is used by several
processes on an Exchange Server 2003 computer. The following table lists the processes
that load DSAccess.dll into their heap and benefit from Active Directory information caching.
Processes that load DSAccess.dll
Process Description
Mad.exe Microsoft Exchange System Attendant service
Store.exe Microsoft Exchange Information Store service
EMSMTA.exe Microsoft Exchange MTA Stacks service
ExMgmt.exe Exchange Management service
RESvc.exe Exchange Routing Engine service
Inetinfo.exe or W3WP.exe IIS and worker processes
Winmgmt.exe Windows Management Instrumentation

service
The following table lists the various Exchange components that use DSAccess to acquire
user and configuration information.
Exchange component use of DSAccess
Component Uses DSAccess for
Metabase update service (DS2MB) Directory changes tracked by update

sequence number (USN)
Exchange Routing Engine (RESVC) User and configuration lookups
SMTP categorizer (SMTP CAT) List of global catalog servers in the topology
Directory Service Proxy (DSProxy) List of global catalog servers in the topology
Exchange store User and configuration lookups
WebDAV User and configuration lookups
Message transfer agent (MTA) User and configuration lookups

90
The DSAccess cache enables the directory lookups performed by these components to be
cached for a period of time. During that time, if another process requests the same
information, it can be retrieved from the DSAccess cache, instead of repeating the same
query against a working global catalog. All directory access, except Address Book lookups
from MAPI clients and certain portions of SMTP inbound and outbound routing, goes through
the DSAccess process and is cached.
By default, directory entries are cached for 15 minutes for configuration data and five minutes
for user data. The default size of the user cache is 140 megabytes (MB), and the
configuration cache is 5 MB. The number of users, the maximum number of entries, the
maximum cache size (memory), and the cache expiration time are all parameters that can
affect the optimal size and performance of the DSAccess cache.
The following registry keys (none of which are present by default) provide low-level control of
the DSAccess cache for configuration data.
Caution:
valuable data.
Value CacheTTLConfig
Type REG_DWORD
Value Data 0x384 (900 seconds)
Description Used to specify the time-to-live (TTL) for

configuration data in the cache
Value MaxEntriesConfig
Type REG_DWORD
Value Data 0 (no limit)
Description Used to specify the maximum number of

configuration data entries in the cache
The following registry keys (none of which are present by default) provide low-level control of
the DSAccess cache for user data.
91
Value CacheTTLUser
Type REG_DWORD
Value Data 0x12c (300 seconds)
Description Used to specify the time-to-live (TTL) for user

data in the cache
Value MaxEntriesUser
Type REG_DWORD
Value Data 0 (no limit)
Description Used to specify the maximum number of user

data entries in the cache
Preloading DSAccess
You should preload search filters to avoid the problem of running multiple search instances
against Active Directory concurrently, which occurs when various search filters are issued on
the same user object. You can enable preloading through the following registry keys, which
define the scope, the base distinguished name (BaseDN), and the filter of the search.
Caution:
valuable data.
The following registry values can be used to preload the DSAccess cache.
Location MSExchangeDSAccess
Value PreloadBaseDNs
Type REG_MULTI_SZ
Value Data BaseDN value (for example,

DC=contoso,DC=com)
92
Description Identifies the container object that is used as

the root for the query. This is a multi-string
setting. Each BaseDN must correlate to a
single preloaded filter. This means that
BaseDNs and filter string must match each
other exactly.
Location MSExchangeDSAccess\
Value PreloadFilters
Type REG_MULTI_SZ
Value Data A filter string, for example,

legacyExchangeDN=%
Description DSAccess reads the registry and interprets

the percent sign (%) as an open parameter,
which will be determined. When an actual
search is issued, the returned record from the
directory is parsed, and the value of this
attribute, which is specified in the preloaded
filter, is inserted in the search entry. Next,
pointers are set to the applicable user record.
As with all modifications to the registry, use
extreme caution when you are updating the
registry. In the same manner as other
Exchange services, DSAccess does not
check the validity of the Active Directory
servers that are specified in the registry and
does not recognize misspellings or other
possible mistakes there. Those values that
are populated for preloading are optimally set
for the most common Exchange searches.
A number of Exchange transactions could trigger a preloading event, but specific criteria must
be met. These preloading events occur in the following order:
1. A search of Active Directory is performed. If the following three conditions are

met in that search, the DSAccess cache is loaded:
• The distinguished name must be returned from a user-directory partition

search.
93
• The resulting distinguished name must contain the BaseDN specified in

the preloaded registry settings. For example, if the actual search specifies a
BaseDN that is more general than the preloaded BaseDN, preloading does
not occur.
• At this point, the returned record is parsed, and the attributes specified in
the preloaded search string are extracted. The attributes required for
constructing the search filter must exist. In the following example of a
multiplexed search, at least one of the attributes must exist:
(|(objectGuid=%) (msExchMailboxGuid=%))
Because of the ambiguity in the returned result, the attribute in the preloaded filter
string must not be multivalued. For example, proxyAddresses = % is not a valid
preloaded search filter, because proxyAddresses is a multivalued attribute, and
DSAccess does not know which value to use for the open value.
2. A search entry is constructed from the scope, BaseDN, attributes, and filter string
— and is linked to this distinguished name entry in the cache. For example:
[scope = Whole Subtree] / [baseDN = DC=mydom,DC=com] / [filter =

(objectClass=myclass)]
DSAccess processes future Active Directory search requests on the preloaded filters and
BaseDNs using the cache instead of Active Directory.
Directory Service Proxy

Directory Service Proxy (DSProxy) is the Exchange Server 2003 component that provides an
address book service to Microsoft Office Outlook clients. DSProxy is implemented in
DSProxy.dll and has two functions:
• To emulate a MAPI address book service and proxy requests to an

Active Directory server
• To provide a referral mechanism so that Outlook clients can directly contact

Active Directory servers
Although its name implies that it provides proxy services only, DSProxy provides both proxy
and referral services.
MAPI clients that are running versions of Outlook earlier than Outlook 2000 access the
directory through the DSProxy component. These earlier clients were designed with the
assumption that each Exchange server contains a directory service. In Exchange 2000
Server and later versions, this is no longer the case. Therefore, DSProxy emulates a directory
service so that earlier clients can function by having the Exchange 2003 server forward the
requests to Active Directory.
94
Later versions of Outlook, such as Outlook 2000 and Outlook 2002, still use a Name Service
Provider Interface (NSPI) proxy on the initial connection to Exchange Server. However, after
the client contacts the server, the DSProxy service passes a referral back to the client. From
that point on, all future directory requests are sent directly to the referral server. The referral
server in this case is the global catalog server.
Note:
In the original release of Outlook 2000, a referral is refreshed only if the global
catalog server becomes unreachable. In Outlook 2000 Service Release 2 (SR2), the
referral is refreshed every time that Outlook starts. This change prevents
Outlook 2000 from continually binding to an unsuitable global catalog server.
Outlook 2002 and later versions updates its global catalog referral whenever the
client restarts or a failure occurs.
DSProxy obtains its list of working global catalog servers from DSAccess but it does not route
its queries through DSAccess. This is because DSProxy uses the NSPI to submit MAPI
address book lookups. 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 acquires the list of working global catalogs from DSAccess and filters out global
catalogs that are not suitable.
• It proxies MAPI queries from pre-Outlook 2000 clients to the global catalog
servers, based on the number of global catalogs and the client IP.
• It refers Outlook 2000 and later version clients to global catalog servers by using
a round robin mechanism.
DSProxy at first runs as a single thread, which can support as many as 512 client
connections. DSProxy automatically spawns an additional thread for every 512 connections.
Unlike DSAccess, DSProxy has no caching mechanism. This means that every MAPI query
processed through DSProxy is sent to a working global catalog.
Exchange Server 2003 Referral Behavior before

Service Pack 2
There was a design change in Exchange Server 2003 Service Pack 2 (SP2) for how the
DSProxy service refers to Outlook clients in global catalogs. This topic explains the before
and after behavior of this change.
95
Before Exchange Server 2003 SP2, Outlook MAPI clients would receive either a referral to a
global catalog server or they would use the Exchange server to send directory-related
requests. In the scenario where the client is Outlook 2000, after the Outlook client connects to
the Exchange server, the DSProxy service passes a referral back to the client. From that
point on, all future directory requests are sent directly to the referred global catalog server.
In this scenario, the global catalog is from one of two locations:
• The global catalog is located in the same Active Directory site as the Exchange
server (typical behavior).
• The global catalog is located in an Active Directory site that is directly connected
to the Exchange server’s Active Directory site (when all in-site global catalogs are
unavailable).
In addition to honoring site membership, DSProxy prefers to use global catalog servers that
are members of the same domain as the Exchange server. If there are none available,
DSProxy uses the other global catalog servers in the Active Directory site.
This behavior presents issues in multiple-domain environments where DomainPrep has been
run against the domains. Specifically, if an Outlook client is referred to a global catalog server
that does not reside in the same domain as the mailbox-enabled user, that user will access
data that is in a read-only format. This means that updates to certain objects could fail. The
updates could be updates to the mailbox-enabled user such as delegate access or
distribution group membership.
Pre-SP2 Scenario
The forest contains three domains, each of which has been prepared for Exchange Server. All
users and distribution groups reside in the domain, UserDomain. A global catalog server from
UserDomain and ThirdDomain are members of the Exchange server’s Active Directory site.
The Outlook clients reside in a different Active Directory site. The domain of the Exchange
server is not represented and there are no global catalog servers from that domain in the
Exchange Server Active Directory site.
96
When an Outlook 2003 client connects to the Exchange server, DSProxy could potentially
refer the client to any one of the three global catalog servers in the Exchange server’s Active
Directory site, assuming that one or more of these global catalog servers are online and
reachable. Because there are no global catalog servers that are members of the Exchange
server's domain, the pre-SP2 behavior does not prefer any of the global catalog servers over
any other. DSProxy will load-balance referral requests across the available global catalog
servers to evenly distribute clients.
In considering the above design, there is a 66 percent chance that DSProxy will refer the
Outlook client to a global catalog server not in the client's home domain. For the purposes of
this discussion, assume that DSProxy refers the client to a ThirdDomain global catalog
server. In this scenario, the Outlook clients can use that global catalog server successfully for
all directory requests except the following:
• Updating membership of distribution groups that reside in UserDomain.
• Assigning delegate permissions against the mailboxes of these distribution

groups, which reside in UserDomain.
• Publishing certificates to the global address list (GAL) using the Publish to GAL
option in Outlook.
If DSProxy referred the Outlook client to the UserDomain GC1, the Outlook client could
perform the requests listed above.
For more information about pre-SP2 behavior and its potential issues, see the following
Microsoft Knowledge Base articles.
• 256976, "XCLN: How MAPI Clients Access Active Directory"
• 872897, "How to control the DSProxy process for RPC over HTTP connections in
Exchange Server 2003 sp1"
97
• 318074, ""Do not have sufficient permissions" error message occurs when you
use Outlook Address Book to manage distribution list membership"
• 329622, ""Send on behalf" permission is not assigned to a user after you

delegate access in Outlook"
Exchange Server 2003 Service Pack 2 Referral

Behavior
In Exchange Server 2003 SP2, by using a new algorithm, the referral process now tries to
provide the Outlook client with a global catalog that belongs to the same domain as the
mailbox-enabled user. The new algorithm will solve the delegation issue, if a home-domain
global catalog server exists and is reachable by the Exchange server for the mail recipient. It
may address the distribution group issue if the distribution group resides in the same domain
as the mailbox. If it does not reside in the same domain, it will not address the issue because
the global catalog contains a read-only copy of the distribution group.
How the New Algorithm Works

The Exchange Server 2003 SP2 DSProxy service tries to refer the Outlook client to a global
catalog server that is available, supports the protocol that is used by the client, and resides in
the mailbox owner’s home Active Directory domain. For DSProxy to find a global catalog
server that meets those requirements, DSProxy scores the desirability of a particular global
catalog server based on the following constraints:
• Constraint 1 A global catalog that is available (RPC ping) – 16 points
• Constraint 2 A global catalog that supports the client's protocol – 8 points
• Constraint 3 A global catalog that belongs to the user's domain – 4 points
• Constraint 4 A global catalog that is in the same Active Directory site as the
Exchange server – 2 points
• Constraint 5 A global catalog that is one of the global catalogs that the
Exchange server is currently using – 1 point
DSProxy distributes the global catalog servers that have the most points first, and
sequentially allocates resources if there is a tie.
Constraint 1 is computed every five minutes and is configurable through changing the
LdapKeepAliveSecs registry key. Constraints 2 and 3 are "dynamic" because they must be
computed every time that a client demands a referral. Constraints 4 and 5 are "static"
because they are computed one time for each global catalog and then stored.
Constraint 5 is also known as the incarnation list. When DSAccess initializes, it builds an
incarnation list of 10 in-site global catalog servers that it can use. If all in-site global catalog
98
servers are unavailable, DSAccess builds an incarnation list of 10 out-of-site servers from the
directly connected sites, starting with the site that has the lowest site link cost. Because of the
constraint ordering, DSProxy prefers servers in the incarnation list of DSAccess so that by
default, it will prefer the 10 servers that have the lowest site link cost. However, DSProxy has
a list of all global catalog servers in all directly connected sites and only uses membership in
the incarnation list to assign points to servers.
The following figure shows the scenario where there are two domains, Exchange Domain and
UserDomain.
In this scenario, the global catalog servers will be assigned the points by the DSProxy service
as shown in the following table. Be aware that the assumption is made that all global catalog
servers are up and responsive in the Exchange Active Directory site.
99
Server Active Directory site In-Use by Total points by

DSAccess? constraint value
UserDomain GC1 Client Active No 16+8+4=28

Directory site
(1, 2, 3)
UserDomain GC2 Client Active No 16+8+4=28

Directory site
(1, 2, 3)
UserDomain GC3 Active Directory site No 16+8+4=28

B
(1, 2, 3)
UserDomain GC4 Active Directory site No 16+8+4=28

B
(1, 2, 3)
Exchange Domain Exchange Active Yes 16+8+2+1=27

GC1 Directory site
(1, 2, 4, 5)
Exchange Domain Exchange Active Yes 16+8+2+1=27

GC2 Directory site
(1, 2, 4, 5)
Exchange Domain Active Directory site No 16+8=24

GC3 A
(1, 2)

GC4 A
(1, 2)

GC5 B
(1, 2)

GC6 B
(1, 2)
Note:
As you can see from the table, Exchange Domain GC7 and UserDomain GC5 are not
included because they are not directly connected to the Exchange server’s Active
Directory site. In other words, the Exchange server never uses those global catalog
servers for DSAccess or DSProxy functions.
From this example, you can see that this algorithm may prioritize an out-of-site global catalog
server over an in-site global catalog server, which differs from typical pre-SP2 DSProxy
behavior.
100
In this example, Exchange Server provides the UserDomain global catalog servers to the
Outlook clients (in a sequential manner to load-balance requests) because those global
catalog servers have a greater point calculation than the Exchange Domain global catalog
servers. This means that Exchange can now refer clients to out-of-site global catalog servers
(but only those that are directly connected to the Exchange Active Directory site) if there are
no mailbox home-domain global catalog servers available in the Exchange server’s Active
Directory site. In this particular example, the Outlook client could receive a referral to a
UserDomain global catalog server that is located in Active Directory site B or the Client Active
Directory site.
Additionally, if all the UserDomain global catalog servers were unreachable (that is, those
servers failed Constraint 1), DSProxy would refer the Outlook clients to the global catalog
servers that reside in the Exchange Active Directory site, because they have the next highest
point cost.
For more information about post-SP2 DSProxy referral, see the Exchange Server Team blog
article Exchange 2003 post-SP2 DSProxy Referral Update.
Note:
The content of each blog and its URL are subject to change without notice.
What the Exchange Server 2003 SP2 DSProxy Change Does

Not Solve
The DSProxy referral change helps the end-user only when DSProxy can find a home-
domain global catalog server. If there are no home-domain global catalog servers in the
Exchange server’s Active Directory site or in any of the Exchange server’s directly-connected
Active Directory sites, the Outlook client receives a referral to a global catalog server that
contains a read-only copy of the mailbox-enabled user. This read-only access means that the
mailbox in question cannot make delegate modifications or publish certificates to the (GAL).
Additionally, although the new behavior could solve the delegate permission and certificate
publishing issues, it might not address the mail recipient’s ability to update distribution group
membership. The distribution group must belong to the same domain as the mail recipient for
the mail recipient to update the membership. If the distribution group does not belong to the
same domain as the mail recipient, updating the membership will fail. Therefore, you may still
have to examine another solution to provide all users with the capability to update group
membership.
Implications of the DSProxy Referral Behavior

The following items must be reviewed in your infrastructure:
• Unless there is prior consideration with regard to network design, this change
may cause clients to be referred to incorrect global catalog servers from a network
101
perspective (latency, bandwidth, usage, number of hops). We recommend that you

consider network implications before implementation.
• To ensure that Exchange Server continues to provide in-site global catalog

referrals, you may need to add global catalog servers to the Exchange Active
Directory site for those domains that contain mailboxes residing on the Exchange
servers in that Active Directory site.
SMTP Categorizer
The SMTP categorizer (also referred to as the categorizer) is a component of the Exchange
Server 2003 transport engine. When a message is submitted to the transport process, the
categorizer uses the header information on the message to query Active Directory for
information about how and where the message must be delivered. For example, from an
SMTP address such as Ted@contoso.com, the categorizer identifies the
Exchange Server 2003 server that contains the user's mailbox and determines how to route
the message to that server. The categorizer also expands distribution lists and applies per-
user limits to messages. For more information about the architecture of the SMTP transport
engine, see SMTP Transport Architecture.
The categorizer relies on DSAccess for the list of Active Directory servers that it should use
for lookups. However, like DSProxy, the categorizer uses its own mechanism to read
information from Active Directory, only after it has the server list.
There are two types of categorizers. One is the base categorizer, which is installed with the
IIS SMTP transport stack, and the other is the Exchange categorizer, which is installed with
Exchange. The base categorizer is implemented in Aqueue.dll. The base categorizer
performs some basic functions, such as using LDAP queries to resolve recipient information
against Active Directory. It also performs efficient batching, sending a number of queries as
one. The base categorizer can also perform distribution list expansion. It has the SMTP
forwarding features, and it triggers categorizer server events. Exchange Server 2003
enhances the basic categorizer by installing a DLL called PhatCat.dll. The PhatCat.dll adds to
the functionally provided by the base categorizer. It does not replace the base categorizer
default functionality, but it does extend the base categorizer functionality for its own use.
The architecture of the Exchange categorizer is shown in the following figure.

102
The architecture of the Exchange categorizer
Message Categorization and Active Directory

When the message is entered into the pre-categorization queue, the categorizer selects the
message for processing. The categorizer resolves the message sender by searching for the
address in the proxyAddresses attribute in Active Directory. The categorizer also resolves the
message recipients by searching for the addresses in the proxyAddresses attribute in
Active Directory. If the list of recipients includes a distribution group, it expands the group to
include those members, if distribution group expansion is allowed on the server. Otherwise,
Exchange transfers the message to the expansion server specified in the distribution group
for group expansion.
The categorizer also checks to verify that the mail attribute exists in Active Directory, and
stamps the mail attribute as the SMTP address. The categorizer is also responsible for
applying per-sender and per-recipient limits and then marking recipients appropriately. The
categorizer then applies per domain, outbound and inbound Internet message format settings
to sender and recipients, and then sets appropriate flags for the IMAIL conversion properties.
You can configure message format settings in Exchange System Manager when you select
the Global Settings container.
For local delivery, the categorizer marks the recipient as local by setting a per-recipient
property on a message indicating the destination server for each recipient. The usual format
of this property is the fully qualified domain name (FQDN) of the recipient's server. The
homeMDB attribute of the recipient indicates on which server the recipient's mailbox resides.
103
The categorizer operations are run as a series of transport event sinks inside the categorizer
event portion of the advanced queuing engine. The base categorizer includes ten event sinks.
The following seven event sinks are used to query Active Directory:
• Register This event sink is called to initialize itself at the beginning of message
categorization.
• BeginMessageCategorization This event sink is called once for each

message submitted to the categorizer.
• EndMessageCategorization This event sink is called to signify the end of

message categorization.
• BuildQuery This event sink is called once for each user who must be verified in
the directory.
• BuildQueries This event sink is called once for each batch lookup. In each of
these scenarios, the categorizer builds an LDAP-compliant filter for the user.
• SendQuery This event sink sends the batch lookup. It runs the directory server
work under the Request attributes. It performs an asynchronous LDAP lookup on a
directory server.
• SortQueryResult This event sink matches the results returned from

Active Directory to individual users.
The following three event sinks are used on a per-user basis and after post-directory service
lookup events:
• ProcessItem This event sink resolves addresses. For example, if a local MAPI
client submits a message, the MAPI client resolves all other addresses, such as
X.400, X.500 DN, Legacy-Exchange-DN, and SMTP addresses, and returns them on
the mail message.
• ExpandItem This event sink adds more recipients to the message, for example,
in the case of message journaling, distribution group expansion, and content
conversions. This is the server event that adds members, such as the expansion in
SMTP forwarding.
• CompleteItem This event sink performs its processing when all other
categorizer event sinks have completed their work. This event sink takes the status
codes that previous event sinks have returned and maps these codes to the
recipients of the e-mail message. Error codes then cause the advanced queuing
engine to generate non-delivery reports (NDRs) for affected recipients.
The Exchange categorizer components in PhatCat.dll extend the IIS categorizer by adding
the following three event sinks:
• Register Sink This event sink initializes the Exchange categorizer components,
but it also initializes DSAccess, the routing engine, and the store driver code. If any
one of these fail, then PhatCat.dll will fail to initialize itself.
104
• BuildQuery This event sink verifies whether the user resides in the DSAccess
cache. If the verification is affirmative, it returns an ICategorizerItemAttributes object.
This bypasses the directory service lookup code for the IIS categorizer. Processing
continues with the ProcessItem event.
• ProcessItem Exchange PhatCat has a special code to handle contacts and

one-off on a special case basis. In this scenario, only the target address of context is
added to the e-mail message.
Recipient Update Service and Exchange

Server 2003
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 2003-specific 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:
• 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.
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
105
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.
However, users who are subject to a different policy do not have their e-mail addresses
re-generated automatically. To update the addresses on those users to match the current
policy, you must use the Apply Now command to apply the current policy.
If you change only the e-mail addresses on a policy, the default behavior of Recipient
Update Service does not change. It updates new and modified objects only. You must
change the filter on the policy to cause Recipient Update Service to query automatically
106
for all users who match that policy and to update all of them. However, even if you
change the filter on the policy, and Recipient Update Service queries for all users,
Recipient Update Service does not re-generate the users' existing e-mail addresses to
match the new recipient policy settings. Instead, new e-mail addresses are added.
When you apply a policy, Exchange System Manager populates the gatewayProxy
attribute on the Recipient Update Service objects with each address from the applied
policy. The gatewayProxy attribute acts as an action list. For example, the gatewayProxy
attribute on your Recipient Update Service objects might be populated with a list of
values similar to the following values:
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}X400:c=us;a= ;p=Organization;o=Exchange;
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}SMTP:@contoso.com
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}smtp:@fabrikam.com
These values contain the objectGUID attribute of the policy, followed by the addresses on
the policy. Note that two of the address types are in uppercase text. This indicates that
these are primary proxy addresses. The one SMTP address type that is in lowercase text
is a secondary proxy address.
Based on the action list, Recipient Update Service updates the proxy addresses on all
users that match the corresponding policy filter. To apply the policy to all users, you also
must modify the filter on the policy (the purportedSearch attribute), by either adding or
removing a space. This modification causes Recipient Update Service, the next time it
runs, to query for all objects that match this policy, instead of querying for new changes
only. After Recipient Update Service completes the recipient update, the addresses
corresponding to that particular policy are removed from the gatewayProxy action list.
Note:
Recipient Update Service re-generates or removes existing addresses on a
recipient only when the action list is populated with those address types.
Metabase Update Service

Metabase update service, also referred to as the directory service/metabase synchronization
process, or DS2MB (because this process is implemented in DS2MB.dll) is a component in
Exchange Server 2003 that is used to synchronize several Exchange configuration settings in
Active Directory with counterpart settings in the IIS metabase. The function of DS2MB is to
replicate configuration information from Active Directory to the local IIS metabase.
The DS2MB process copies entire subtrees from Active Directory, without changing the
shape of the subtree. This is a one-way write from Active Directory to the metabase; the
metabase never writes to Active Directory. The DS2MB process does not add or compute any
attribute when copying. The paths in the metabase are called keys. Properties can be set at
107
each key, and each property can have attributes that customize that property. All identifiers
that are present in the directory service image of the subtree are required in the metabase,
including identifiers such as KeyType. In addition, the Relative Distinguished Name of the
object in the directory is mapped directly to the key name in the metabase.
DS2MB Operations
The metabase update is a subprocess that is launched when System Attendant is started.
The operation of SMTP, POP3, IMAP4, Outlook Web Access and Outlook Mobile Access 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. As soon as the change is replicated to the configuration domain controller, the
change should be replicated to the metabase by DS2MB. DS2MB tracks changes to directory
objects based on update sequence numbers (USNs).
Exchange System Manager Architecture

Exchange System Manager is a Microsoft Management Console (MMC)-based tool that
provides administrators with a graphical user interface (GUI) to manage the configuration of
Exchange 2000 Server or Exchange Server 2003 organizations. However, Exchange System
Manager is more than a single snap-in. It is a system of stand-alone snap-ins and extension
snap-ins, which all run in the MMC process (MMC.exe). These snap-ins are saved in a pre-
configured MMC file named Exchange System Manager.msc. This file is located in the
\Program Files\Exchsrvr\Bin directory. You can start it from the Microsoft Exchange program
group in the Start menu, using the System Manager shortcut. You can also add the Exchange
System snap-in to custom MMC-based tools. The Exchange System snap-in represents the
core component of Exchange System Manager.
This section discusses the following concepts:
• MMC Integration Because all Exchange System Manager snap-ins are based
on MMC, you must understand how these snap-ins integrate with MMC.
• Communication with the Microsoft Active Directory directory service Most

Exchange Server 2003 configuration objects reside in Active Directory. Therefore,
you must know both what these objects are and how Exchange System Manager
communicates with Active Directory to access these objects.
• Communication with the Exchange store Storage groups, messaging

databases, and individual mailboxes and public folders are Exchange store
components. When you configure these components, Exchange System Manager
communicates with the Exchange store through MAPI or the Distributed Authoring
108
and Versioning (DAV) protocol. To determine which servers in a computer network

you can manage from a single console, you must understand these communication
mechanisms.
• Integration with Windows Management Instrumentation (WMI) Exchange

System Manager communicates with WMI providers to display dynamic information,
such as a list of messages currently waiting for delivery in a message queue. To
understand how monitoring tools work, such as the message queue viewer or the
message tracking center, you must know when and how Exchange System Manager
communicates with WMI providers and related services
• Configuration of Exchange Server 2003 services Exchange System

Manager is also a service configuration program, which you can use to set service-
specific parameters in the registry on an Exchange server. For example, when
specifying diagnostics-logging levels, Exchange System Manager must access an
Exchange server's registry database.
• This section assumes that you are familiar with Active Directory and the basic
concepts of managing an Exchange Server 2003 organization. It also assumes that
you know how to install Exchange System Manager on a dedicated workstation.
For more information about how to install Exchange System Manager and how to manage an
Exchange Server 2003 organization efficiently, see the Exchange Server 2003 Administration
Guide.
Integration with Microsoft Management

Console
When you install Exchange System Manager on a server running Exchange Server 2003 or a
management workstation, the Setup program registers the Exchange MMC snap-ins in the
local registry, to make them available in the MMC tool. Snap-ins are implemented in
Component Object Model (COM) in-process server dynamic-link libraries (DLLs). In contrast
to a stand-alone application that runs as a separate process, an in-process server DLL
exposes one or more COM objects and runs within the process of the client application that
uses these objects. For example, MMC snap-ins run in the process of MMC.exe. Snap-ins
must be registered in the registry in the following keys:
• HKEY_CLASSES_ROOT\CLSID Each snap-in is assigned a GUID that identifies the

snap-in as a unique COM class object within an in-process server DLL. These
identifiers, known as class identifiers (CLSIDs), must be registered for each object in
the CLSID registry key. For example, {1B600AEA-10BA-11d2-9F28-00C04FA37610} is the
CLSID of the SystemMgr Class. The SystemMgr Class can be found in an in-process
server DLL named Exadmin.dll, which is located in the \Program Files\Exchsrvr\Bin
directory. (Most Exchange snap-ins are in this DLL.) The entries under the CLSID
109
registry key define the threading model for the COM classes, the ProgID, the version
number of the COM class, and more.
• HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\SnapIns To define COM

components as MMC snap-ins, CLSIDs must be registered under the SnapIns key.
For example, if you search for a CLSID key of {1B600AEA-10BA-11d2-9F28-
00C04FA37610} under the SnapIns key (that is, the CLSID of the SystemMgr Class),
you find that this entry belongs to the Exchange System snap-in, which is the core
snap-in of Exchange System Manager. The following table lists the entries for snap-
ins under the SnapIns key.
Registry parameters for MMC snap-ins
Parent Key Parameter Type Comments
{CLSID} NameString REG_SZ The NameString value

specifies the display
name of the snap-in,
as it appears in the
MMC user interface
when adding a snap-
in to a console. For
example,
Namestring=Exchan
ge System defines
the display name for
the Exchange System
snap-in.
110
{CLSID} About REG_SZ The About value

contains the CLSID of
the object that is used
to provide an icon, a
description, and the
About dialog box for
the snap-in. For
example, About=
{1B600AEB-10BA-
11d2-9F28-
00C04FA37610}
points to a specific
CLSID. If you look up
this CLSID under
HKEY_CLASSES_ROOT\CL
SID, you find that this
is the CLSID for the
AboutSystemMgr
class, which also
resides in
Exadmin.dll.
111
{CLSID} NameStringIndirect REG_SZ The

NameStringIndirect
value provides a
resource DLL name
and string identifier,
as an indirect way to
retrieve the name of
the snap-in. For
example,
NameStringIndirect=
@C:\\Program
Files\\Exchsrvr\\bin\\
exadmin.dll,-12577
specifies the name of
the Exchange System
snap-in, as found in
Exadmin.dll. If
NameStringIndirect
does not exist, or if its
value data does not
lead to a successful
string load, MMC then
uses the NameString
value as the name
string.
112
{CLSID}\ StandAlone N/A N/A An existing

StandAlone key
indicates that the
snap-in is a stand-
alone snap-in. You
can add stand-alone
snap-ins to an MMC
console in the
Add/Remove Snap-
in dialog box. You can
also add stand-alone
snap-ins to subnodes
of other snap-ins,
using the stand-alone
snap-in in the same
way as an extension
snap-in.
Extension snap-ins do
not have a StandAlone
key. Therefore, the
snap-in cannot be
added to an MMC
console without first
adding a stand-alone
snap-in that provides
the nodes that the
extension snap-in is
designed to extend.
For example, the
Exchange Information
Store extension snap-
in extends the System
Manager snap-in.
Therefore, you can
add only this
extension snap-in
when you add the
System Manager
snap-in to your MMC
console. Extension
snap-ins are listed as
available extensions
113
{CLSID}\ NodeTypes {CLSID} N/A Nodes refer to the

configuration objects
in the MMC console
tree. For example, in
Exchange System
Manager, the
individual server
objects in the Servers
container under an
administrative group
are a specific node
type. Node types are
registered in the
NodeTypes key.
The NodeTypes key

contains subkeys that
are the GUIDs of the
node types. MMC
uses these GUIDs to
enumerate the node
types of the snap-in
and then uses that list
of node types to
obtain the extension
snap-ins for those
node types. The set
of extension snap-ins
then appears as
available extensions
for the snap-in in the
Extensions tab of the
Add/Remove Snap-
in dialog box.
• KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes All extensible node types

have their own subkey (that is, the GUID of the node type) registered under the
MMC\NodeTypes key. Each GUID key contains an Extensions subkey. The Extensions
key contains additional subkeys that represent the actual types of extensions that this
node type can have. Each extension type subkey contains values that represent the
CLSIDs of the snap-ins that extend that node type. For example, the Exchange Post
Office Protocol version 3 (POP3) container object (GUID {F54E0C6b-11FF-11d2-
114
9F28-00C04FA37610}) is an extensible node type of the Exchange Protocols snap-

in.
Likewise, the key \NodeTypes\{F54E0C6b-11FF-11d2-9F28-00C04FA37610} has an

Extensions subkey that lists the CLSID of the Exchange POP3 extension snap-in in the
ContextMenu and NameSpace subkeys. This indicates that the Exchange POP3 extension
snap-in extends the namespace and the context menu in Exchange System Manager for
the Exchange POP3 container object. The namespace is the hierarchy of all objects that
can be managed through an MMC console.
Exchange Server 2003 Snap-ins and Snap-in

Extensions
As discussed in the previous section, stand-alone and extension snap-ins create the
Exchange System Manager user interface. Extension snap-ins can extend the features of
stand-alone snap-ins or other extension snap-ins. This modular architecture enables
developers to implement specific management features. It also enables administrators to
create custom management consoles. For example, you can put the Exchange Message
Tracking Center snap-in in a custom MMC console and provide this snap-in to a messaging
administrator who is responsible solely for message tracking.
The following table lists the available Exchange Server 2003 snap-ins and their possible
snap-in extensions.
Exchange Server 2003 snap-ins and snap-in extensions
Snap-in Snap-in Extension In-process server Description

DLL
Exchange Message Not applicable Exadmin.dll Provides access to

Tracking Center the message-tracking
center. This is a
stand-alone snap-in.
115

DLL
Exchange Protocols Not applicable Exadmin.dll Implements the

Protocols container
and provides empty
sublevel nodes that
additional extension
snap-ins can use to
enhance the user
interface in Exchange
System Manager.
The Exchange
Protocols snap-in is
an extension snap-in
of the Exchange
System stand-alone
snap-in. This snap-in
is also an extension
snap-in of the
Exchange Servers
extension snap-in.
Exchange HTTP Exadmin.dll Enables management

of the HTTP protocol
and HTTP virtual
servers.
Exchange IMAP4 Imapmgr.dll Enables management

of the Internet Mail
Access Protocol
version 4 (IMAP4)
and IMAP4 virtual
servers.
Exchange NNTP Nntpmgr.dll Enables management

of the Network News
Transfer Protocol
(NNTP) and NNTP
virtual servers.
Exchange POP3 Pop3mgr.dll Enables management

of POP3 protocol and
POP3 virtual servers.
116

DLL
Exchange SMTP Exps.dll Enables management

of Simple Mail
Transfer Protocol
(SMTP) and SMTP
virtual servers.
Exchange X.400 Exadmin.dll Enables management

of the local message
transfer agent (MTA)
and X.400 protocol
settings.
Exchange Servers Not applicable Exadmin.dll Enables the

management of
storage-specific
settings on an
Exchange server.
The Exchange
Servers snap-in is an
extension snap-in of
the Exchange System
stand-alone snap-in.
117

DLL
Exchange DXA Exadmin.dll Enables checking of

directory
synchronization
settings when you run
Microsoft Exchange
Connector for
Microsoft Mail on a
server with an earlier
version of Exchange.
Note:
Configuring
Exchange 20
00 Server
resources
using
Exchange
Server 2003
System
Manager is
not
supported.
Make sure
you use
Exchange 20
00 System
Manager to
configure
directory
synchronizati
on with
Microsoft
Mail.
Exchange Exadmin.dll Enables the

Information Store management of
storage groups,
mailbox stores, and
public folder stores.
118

DLL
Exchange Monitoring Exadmin.dll Enables you to

examine the state of
Exchange servers
and messaging
connectors between
routing groups.
Exchange Protocols Exadmin.dll As mentioned earlier

in this table, this
snap-in implements
the Protocols
container and
provides empty
sublevel nodes that
the Exchange HTTP,
Exchange IMAP4,
Exchange NNTP,
Exchange POP3,
Exchange SMTP, and
Exchange X.400
extension snap-ins
use to enhance the
user interface in
Exchange System
Manager.
Exchange Queue Exadmin.dll Provides access to

Viewer the queue viewer in
Exchange System
Manager, which
provides
management
interfaces for SMTP,
MTA, X.400, and
other connector
queues.
119

DLL
Exchange System Not applicable Exadmin.dll The core MMC snap-

in of Exchange
System Manager.
This stand-alone
snap-in implements
the user interface
from which an
administrator
manages global
settings and server
properties. It also
provides additional
nodes that the
remaining snap-ins
can use to extend the
user interface.
Exchange Address Exadmin.dll Enables management

Lists of address lists,
including global
address lists and
offline address books.
Exchange Address Exadmin.dll Enables management

Templates of address templates.
Exchange Calendar Exadmin.dll Enables management

Connector of Calendar
Connector instances.
Calendar Connector
enables the
synchronization of
free/busy information
between Exchange
users and Lotus
Notes or Novell
GroupWise users.
120

DLL
Exchange cc:Mail Exadmin.dll Enables checking the

configuration of
Connector for Lotus
cc:Mail running on
Exchange 2000
Server systems.
Note:
Configuring
Exchange 20
00 Server
resources
using
Exchange
Server 2003
System
Manager is
not
supported.
Make sure
you use
Exchange 20
00 System
Manager to
configure
Connector for
Lotus cc:Mail.
121

DLL
Exchange DXA Exadmin.dll Enables checking of

directory
synchronization
settings when running
Connector for
Microsoft Mail on a
server with an earlier
version of Exchange.
Note:
Configuring
Exchange 20
00 Server
resources
using
Exchange
Server 2003
System
Manager is
not
supported.
Make sure
you use
Exchange 20
00 System
Manager to
configure
directory
synchronizati
on with
Microsoft
Mail.
Exchange Folders Exadmin.dll Enables management

of public folders and
public folder trees.
Exchange Exadmin.dll Enables management

GroupWise of Connector for
Connector Novell GroupWise.
122

DLL
Exchange Exadmin.dll Enables management

Information Store of storage groups,
mailbox stores, and
public folder stores.
Exchange Mailbox Exadmin.dll Provides access to

Recovery Center Mailbox Recovery
Center, which you can
use to recover
individual mailboxes
from a backup.
Exchange Message Exadmin.dll Provides access to

Tracking Center and use of Message
Tracking Center.
Exchange Monitoring Exadmin.dll Provides access to

the monitoring and
status features for
managing
connectivity between
routing groups.
123

DLL
Exchange MSMail Exadmin.dll Enables checking the

configuration settings
of Connector for
Microsoft Mail running
on Exchange 2000
servers.
Note:
Configuring
Exchange 20
00 Server
resources
using
Exchange
Server 2003
System
Manager is
not
supported.
Make sure
you use
Exchange 20
00 System
Manager to
configure
Connector for
Microsoft
Mail.
Exchange Notes Exadmin.dll Provides access to

Connector the Connector for
Lotus Notes
configuration settings.
124

DLL
Exchange Protocols Exadmin.dll As mentioned earlier

in this table, this
snap-in implements
the Protocols
container and
provides empty
sublevel nodes that
the Exchange HTTP,
Exchange IMAP4,
Exchange NNTP,
Exchange POP3,
Exchange SMTP, and
Exchange X.400
extension snap-ins
use to enhance the
user interface in
Exchange System
Manager.
Exchange Queue Exadmin.dll Provides access to

Viewer the queue viewer in
Exchange System
Manager, which
provides
management
interfaces for SMTP,
MTA, X.400, and
other connector
queues.
Exchange Recipient Exadmin.dll Enables management

Policies of recipient policies,
which Recipient
Update Service uses
to assign recipient
information, such as
e-mail addresses, to
user accounts.
125

DLL
Exchange Schedule+ Exadmin.dll Enables checking the

Free/Busy Connector configuration settings
of the Schedule+
Free/Busy Connector
on servers running
Exchange 2000
Server.
Note:
Configuring
Exchange 20
00 Server
resources
using
Exchange
Server 2003
System
Manager is
not
supported.
Make sure
you use
Exchange 20
00 System
Manager to
configure
Schedule+
Free/Busy
Connector.
Exchange Servers Exadmin.dll Enables the

management of
storage-specific
settings on an
Exchange server.
126
Building Custom Exchange Management

Consoles
To create custom management consoles based on Exchange snap-ins, you can use either
Exchange System or Exchange Message Tracking Center stand-alone snap-ins in the MMC
console. You cannot, however, create an MMC console for public folder administration with
only the Exchange Folders extension snap-in. You must first add the Exchange System
stand-alone snap-in to the console. However, when you add the Exchange System snap-in,
you provide administrator access to global settings and server properties, which you may not
want to provide. Fortunately, there is a solution to this dilemma.
Instead of adding separate snap-ins to the console, you can add the full Exchange System
snap-in and then locate the object in the MMC namespace that you want to provide, such as
the Public Folders node. When you right-click this node, you can select the New Window
from Here command from the context menu. This will open a subwindow with the selected
node as the root of the hierarchy. You can then close the subwindow that shows all nodes
and save the console in its current state in an .msc file.
MMC consoles can run in one of two modes: author mode or user mode. You can use author
mode to create new consoles or modify existing consoles. You use user mode to work with
existing consoles for system administration. There are three levels of user mode:
• User mode - full access When running a console in this mode, the user can
use all available functionality of the snap-ins, but the user cannot add or remove
snap-ins or save changes to the console.
• User mode - limited access, multiple window When running a console in this
mode, the user cannot add or remove snap-ins or save changes to the console. The
user also cannot close any windows that were open when the console author last
saved the console.
• User mode - limited access, single window Running a console in this mode,
the user cannot add or remove snap-ins or save changes to the console. The user
also cannot open additional subwindows.
The following figure shows a custom console for public folder management.
127
A console for public folder management in user mode
You can use the MMC command line switch /a to open a saved console in author mode and
make changes to saved consoles. When you open saved consoles using the /a switch, they
are opened in author mode, regardless of their default mode. However, this does not
permanently change the default mode setting. When you do not specify the /a switch, MMC
opens console files according to their default mode settings.
Note:
Do not add the StandAlone key to the registry settings of an extension snap-in to
convert the snap-in to a stand-alone snap-in. Extension snap-ins depend on nodes
and features exposed by their parent snap-ins and cannot function correctly as stand-
alone snap-ins.
Managing Configuration Information in

Active Directory
When you add the Exchange System snap-in to a custom console, a Change Domain
Controller dialog box appears. From this dialog box, you can select a domain controller from
a domain in the forest of the Exchange Server 2003 organization, or you can accept the
default configuration to connect to any writable domain controller. Access to Active Directory
128
is required to get to the configuration information of an Exchange Server 2003 organization,

which resides in the configuration directory partition, as explained in Exchange Server 2003
Note:
You can manage an Exchange Server 2003 organization only from a computer that is
a member of a domain that is trusted by the domain controllers in the forest
containing the servers running Exchange Server 2003.
Binding to a Domain Controller

Exchange System Manager uses Active Directory Service Interfaces (ADSI) to communicate
with Active Directory. ADSI relies on Lightweight Directory Access Protocol (LDAP). If you
specify a specific domain controller in the Change Domain Controller dialog box, a direct
LDAP connection to that domain controller is established when you open Exchange System
Manager. Alternatively, if you accept the default configuration (no domain controller specified),
ADSI performs a serverless bind to a domain controller.
Serverless binding is the process in which ADSI uses the locator service implemented by the
Netlogon service to find the best domain controller to use. This domain controller is always
located in the domain associated with the current security context of the user who connects to
Active Directory. Each domain controller registers its host name in the Domain Name System
(DNS) and its NetBIOS name using a transport-specific mechanism, for example, Windows
Internet Name Service (WINS). The locator service locates the name, and then sends a
datagram to the domain controller that registered the name. For NetBIOS domain names, the
datagram is a mailslot message. A mailslot is a mechanism provided by the operating system
for one-to-one or one-to-many interprocess communications (IPC). For DNS domain names,
the datagram is an LDAP User Datagram Protocol (UDP) search. Each responding domain
controller indicates that it is currently operational.
Note:
NetBIOS is still required for Exchange Server 2003. Therefore, you must not
decommission installed WINS servers in your network. For example, Exchange
System Manager might select NetBIOS for remote procedure call (RPC)-based
communication with an Exchange server, if defined in the RPC protocol binding order.
The RPC protocol binding order is defined in a REG_STRING registry parameter
named Rpc_Binding_Order, located under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider. The default
value includes NetBIOS:
ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp. However,
communication with domain controllers is based on LDAP and does not require
NetBIOS or WINS.
129
As indicated in the following figure, the locator service prefers domain controllers in the local
Active Directory site and connects to the first domain controller that responds. When the
locator service sends a datagram to the domain controller, the domain controller looks up the
Internet Protocol (IP) address of the client in the Configuration/Sites/Subnet container in
Active Directory, to find a subnet object that corresponds to the client's IP address region.
The siteObject property of the subnet object reveals the distinguished name of the site that
contains the client, for example: CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=fabrikam,DC=com. The domain controller responds
to the datagram with the distinguished name of the site that contains the client, together with
an indicator of whether this domain controller covers that site. If the domain controller does
not cover that site, and the locator service has not yet tried to find a domain controller in the
client's site, the locator service tries again to find a domain controller in the local site. After a
domain controller has been located, an LDAP connection to Active Directory is established,
and the connection information is cached, so that subsequent connections from the same
application do not require a repeat of the serverless bind algorithm. The bind cache contains
connection handles to the appropriate servers, in addition to connection characteristics, such
as encryption and authentication information.
Serverless binding to a domain controller
Note:
A serverless bind is the preferred connection method, because it balances requests
from multiple clients between multiple domain controllers, and it is able to switch to
another domain controller automatically when a domain controller becomes
unavailable.
130
The Exchange Organization in the Configuration

Directory Partition
Most of the configuration settings that you can manage using Exchange System Manager are
stored in directory objects in the configuration directory partition in Active Directory. The
hierarchy of configuration objects that appears in the console tree of Exchange System
Manager closely matches the hierarchy of directory objects in the configuration directory
partition. Only small differences exist. For example, in an organization with only one
administrative group and one routing group, you can display the configuration objects in a
hierarchy with or without administrative and routing groups. To do this, you select or clear the
Display routing groups and Display administrative groups check boxes on the General
tab in the properties of the Exchange organization object (that is, the root object in the
console tree of Exchange System Manager). Nevertheless, administrative and routing group
containers always exist in the configuration directory partition.
The following figure illustrates the hierarchy of directory objects from the configuration
directory partition (displayed in Active Directory Sites and Services) compared to the
hierarchy of configuration objects in Exchange System Manager (with administrative and
routing groups enabled).
Hierarchies of directory and configuration objects
Exchange System Manager arranges the configuration objects from the configuration
directory partition in the console tree, according to the following general categories:
131
• Global Exchange objects Global Exchange objects are objects that define
Internet message formats and other settings that affect the whole Exchange
organization. For example, the Mobile Services object defines settings for Exchange
ActiveSync and Microsoft Office Outlook Mobile Access that apply to all recipients in
the Exchange organization. The directory objects that correspond to these
configuration objects reside in the Global Settings container, under the Exchange
organization container in the configuration directory partition.
• Recipient objects Recipient objects define rules that determine the e-mail
addresses that Recipient Update Service assigns to mailbox-enabled and mail-
enabled recipient objects. Recipient objects also determine how server-based
address lists are generated. Using the configuration objects in the Recipients
container in Exchange System Manager, you can customize details and address
templates to change the address book user interface in Outlook.
The Recipients container in Exchange System Manager consolidates directory objects

from a number of containers in the configuration directory partition. Address list definition
objects and Recipient Update Service objects are in the Address Lists container, objects
for details and address templates are in the Addressing container, and objects for policies
that define e-mail addresses for mailbox-enabled and mail-enabled recipients are in the
Recipient Policies container, under the Exchange organization object in Active Directory.
• Administrative and routing group objects Administrative and routing group

objects do not provide access to any configuration parameters in Exchange System
Manager. Instead, they are used to define the administrative topology and the
message routing topology of an Exchange organization. For example, you use
administrative groups to split the management of Exchange servers and resources.
With routing groups, you can streamline message transfer between different sites
and locations. For more information about administrative and routing group planning,
see Planning an Exchange Server 2003 Messaging System.
• Server objects Server objects contain the settings that apply to individual
Exchange servers in the messaging organization. Server objects also hold additional
configuration objects for storage groups and messaging protocols. When displaying
the properties of a server object, Exchange System Manager consolidates
information from a variety of information sources on the various property tabs. Server
configuration objects correspond to server directory objects in the configuration
directory partition that resides in the Servers container, under an administrative
group.
• System policy objects You can use system policy objects to simplify system
administration by configuring parameters for multiple Exchange servers through a
single configuration object, such as mailbox store, public folder store, or server
settings. However, by default, system policy objects do not exist. To create a system
policy, you first must add a specific System Policies container to your administrative
group. To do this, right-click the administrative group, point to New, and then select
132
System Policies Container. Then, to create either a Mailbox store policy, Public
store policy, or Server policy, right-click the System Policies container and
configure your policy. For more information about configuring the mailbox store,
public folder store, or server properties, see the Exchange Server 2003
Administration Guide.
• Folder hierarchies Folder hierarchy objects can be found in the Folders

container, under an administrative group. Each hierarchy object in this container
refers to a particular public folder tree in the Exchange store. A public folder tree can
be replicated across public stores on multiple Exchange servers. However, the
hierarchy objects reside in the Folder Hierarchies container, under an administrative
group in the configuration directory partition.
Note:
The Tools node in Exchange System Manager does not correspond to a directory
object in the configuration directory partition. The Tools node provides access to
extension snap-ins, such as Message Tracking Center, which in turn might access
objects in Active Directory to persist configuration information.
Exchange System Manager and Permission

Settings
The permissions model of Exchange Server 2003 relies completely on the Microsoft Windows
security model. The permissions model is structured on the Exchange organization object
and administrative groups in the configuration directory partition. When you right-click the
organization object or administrative group in the console tree of Exchange System Manager,
you can select the Delegate control command to start Administration Delegation Wizard.
Using Administration Delegation Wizard, you can assign to an Exchange administrator one of
the three following roles:
• Exchange Full Administrator This role grants the administrator full control
over the Exchange organization. However, the Receive As and Send As permissions
are specifically denied. Therefore, an Exchange full administrator cannot impersonate
another user in the Exchange organization. For example, an administrator who does
not have Send As permission cannot send e-mail messages on behalf of another
user.
• Exchange Administrator This role grants the administrator similar permissions

to those of an Exchange full administrator but denies Modify Owner and Modify
Permissions permissions. Therefore, an Exchange administrator can manage all
settings of an Exchange organization, but cannot change the security settings.
• Exchange View Only Administrator This role grants the administrator

permissions to Read All Properties, List Contents, Read Permissions, and View
Information Store status. For example, Exchange View Only administrator
133
permissions are required for mailbox administrators who must mailbox-enable or

mail-enable user accounts, but who are not responsible for Exchange server
management.
The following table lists the key differences among the various Exchange administrator roles.
Key differences between Exchange administrator roles
Administrator Role Modify Security Manage Exchange View Exchange

Settings Configuration Configuration Settings
Settings
Exchange Full Yes Yes Yes

Administrator
Exchange No Yes Yes

Administrator
Exchange View Only No No Yes

Administrator
Enabling the Security Tab for Objects in

Exchange System Manager
Administration Delegation Wizard is used to grant roles to individual Exchange administrators
or groups at the organization or administrative group level. However, Administration
Delegation Wizard does not display all security settings and sometimes might even display an
incomplete administrator list. This is because Administration Delegation Wizard tracks
administrators to whom it grants Exchange administrator roles, in an attribute of the
Exchange organization object in Active Directory. This attribute is named msExchAdmins.
However, Administration Delegation Wizard does not track administrators with permissions
inherited from higher-level containers in the configuration directory partition. For example, by
default, Enterprise Administrators have full permissions across the entire configuration
directory partition. This is because the full permissions setting is inherited from the root
Configuration container to all child containers. However, Administration Delegation Wizard
does not list these administrators as Exchange Full Administrators, because they are not
listed in the msExchAdmins attribute. Permissions inheritance is explained in "Permissions
Inheritance and Exchange System Manager" later in this topic.
Moreover, if you assign a security group the Exchange Full Administrator role at the
organization level, later you cannot use Administration Delegation Wizard to downgrade
members of that group to the Exchange View Only Administrator role for a specific
administrative group. This is because Administration Delegation Wizard does not deny
permissions granted through security settings inherited from parent containers. If you use
Administration Delegation Wizard to assign individual members the Exchange View Only
134
Administrator role for an administrative group, Administration Delegation Wizard lists these
accounts as Exchange View Only Administrator accounts. However, these accounts retain
their Exchange Full Administrator role, which is inherited through their group membership
from the organization level. To examine actual security settings, you must enable the
Security tab for the organization and administrative group objects in Exchange System
Manager. To do this, set the ShowSecurityPage registry parameter, as shown in the following
table.
The ShowSecurityPage registry parameter
HKEY_CURRENT_USER\Software\Microsoft
\Exchange\ExAdmin
ShowSecurityPage
Value Name
REG_DWORD
Data Type
1
Value
Description This setting affects only the user who is

currently logged on. If the ShowSecurityPage
value is not present or is set to 0, the Security
tab appears on the following objects only:
• Address lists
• Global address lists
• Mailbox stores
• Public folder stores
• Top level public folder hierarchies
If the ShowSecurityPage value is set to 1, the

Security tab appears on all objects in
Exchange System Manager. Changes occur
immediately. You do not have to restart
Exchange System Manager.
Caution:
valuable data.
135
Permissions Inheritance and Exchange System

Manager
If you examine the security settings for an Exchange organization, in Exchange System
Manager on the Security tab, you notice that security settings are assigned to several
system accounts and groups, in addition to those accounts that you specifically assigned an
Exchange administrator role. The following table lists these default accounts and their
permissions.
Default accounts with permissions in an Exchange organization
Account Permitted Denied
ANONYMOUS LOGON • Create Named None

Properties in the
Information Store
• Create Public
Folder
• Execute
• List Contents
• List Object
• Read
• Read
Permissions
• Read Properties
Authenticated users • Read Properties None
• List Object
136
Domain Admins (root domain) • Read • Receive As
• Write • Send As
• Execute
• Delete
• Read
Permissions
• Change
Permissions
• Take Ownership
• Create Children
• List Contents
• Add/remove Self
• Read Properties
• Write Properties
• List Objects
• Create Public
Folder
• Create Top Level

Public Folder
• Modify Public
Folder Admin ACL
• Modify Public
Folder Replica List
• Open Mail Send

Queue
• Read Metabase
Properties
• Administer
Information Store
• Create Named
Properties in the
Information Store
• View Information
137
Enterprise Admins • Full Control • Receive As
• Send As
Everyone • Create Named None

Properties in the
Information Store
• Create Public
Folder
• Execute
• List Contents
• List Objects
• Read
• Read
Permissions
• Read Properties
Exchange Domain Servers • Full Control None
Most permissions settings are inherited by the Exchange organization object from parent
containers in the hierarchy of the configuration directory partition. For example, Enterprise
administrators are granted the Full Control permissions at the root container of the
configuration directory partition. Because permissions are by default inherited by all child
objects in the configuration directory partition, including the Exchange organization container,
Enterprise Administrators are also Exchange Full Administrators.
You cannot use Exchange System Manager to examine security settings for parent
containers in the configuration directory partition, but you can examine the actual settings
using the ADSI Edit tool. Figure 4.4 shows the security settings for the Enterprise Admins
group, as they are applied to the configuration container. The following figure also illustrates
that these settings are applied to the configuration container and all child objects, including
the Exchange organization.
138
Security settings for Enterprise Administrators as they appear in ADSI Edit
Permissions inheritance is a feature that facilitates the assignment of permissions in the

configuration directory partition of Active Directory. For example, in Exchange System
Manager, Administration Delegation Wizard relies on permissions inheritance to assign
Exchange administrator roles to accounts and groups at the organization and administrative
group level. When it assigns the Exchange Full Administrator role to an administrator account
at the organization level, Administration Delegation Wizard grants the account Full Control
permissions at the parent container, named Microsoft Exchange (Figure 4.4). Therefore, full
control is applied to both the child container, named Active Directory Connections, and the
Exchange organization. However, accounts assigned administrative permissions at the
administrative group level are granted Read permissions at the organizational level also, so
that these administrators can display the configuration information in Exchange System
Manager. For more information about Administration Delegation Wizard and permission
assignments in an Exchange organization, see the Exchange Server 2003 Security
Hardening Guide.
Managing Exchange Store Resources

Active Directory is not the only communication partner of Exchange System Manager. Various
Exchange System Manager snap-ins also communicate with the Exchange store. These
enable you to display real-time information about Exchange store resources and to manage
public folders. Exchange System Manager uses MAPI to display mailbox statistics and client
139
logons. It uses Distributed Authoring and Versioning (DAV) protocol to display and manage
public folder resources.
MAPI-Based Communication
The following figure illustrates the difference between mailbox store and public folder store
objects in Active Directory and Exchange System Manager. In Active Directory Sites and
Services, mailbox store and public folder store objects are represented by leaf nodes that do
not contain child objects. In Exchange System Manager, however, mailbox store and public
folder store objects are represented as nodes in the console tree. They contain several child
containers, such as Logons, Mailboxes or Public Folders, Public Folder Instances,
Replication Status, and Full-Text Indexing.
Mailbox and public folder store objects in Active Directory Sites and Services and
Information Obtained Through the

IExchangeManageStore Interface
The child containers under mailbox store and public folder store objects are virtual containers
that do not exist in Active Directory or elsewhere. To display these containers, Exchange
140
System Manager must communicate with the Exchange store through the
IExchangeManageStore interface, which is an internal MAPI-based interface. This MAPI
communication is dynamic in nature and occurs when you expand a particular mailbox store
or public folder store in Exchange System Manager. You cannot display the child containers
of a mailbox store or public folder store if the mailbox store or public folder is dismounted.
Communication through MAPI also occurs when you add mailbox stores or public folder
stores to an Exchange server, when you display the properties of an individual mailbox store
or public folder store, and when you mount or dismount mailbox stores or public folder stores.
Note:
MAPI-based communication requires you to work with an Exchange System Manager
account that is a member of the local Administrators group. This gives you Write
permissions to the \System32 directory on the local computer. This is required so that
Exchange System Manager can create a dynamic MAPI profile. Communication with
an Exchange server cannot take place through MAPI without a MAPI profile.
Exchange System Manager calls the following IExchangeManageStore methods to obtain

dynamic information about mailbox and public folder stores:
• GetMailboxTable The GetMailboxTable method obtains information about all

mailboxes in a mailbox store. This method returns a pointer to a MAPI IMAPITable
interface, which contains information about all the mailboxes in the specified
Exchange store. Each row in this MAPI table represents an individual mailbox. The
columns in the table provide detailed information about the mailbox, such as the
name, number of messages, message sizes, the Windows user account name of the
last user to log on to the mailbox, and the date and time when the user last logged
on. Additionally, columns indicate whether a mailbox is currently within storage limits.
• GetPublicFolderTable The GetPublicFolderTable method obtains information

about all public folders in a public folder store. This method returns a pointer to a
MAPI IMAPITable interface, which contains information about all public folders in the
specified Exchange store. Each row in this MAPI table represents an individual public
folder. The columns in the table provide detailed information about the public folder,
such as the name, number of associated messages, sizes (in bytes) of all associated
messages, number of associated messages with attachments, number of cached
columns and categorizations on the public folder, number of public folder contacts,
date and time that the replica of a public folder was accessed, and date and time that
an object in the public folder was last modified.
Tip:
You can display all information obtained for a mailbox store or public folder store. For
detailed instructions, see How to Display All Information Obtained for a Mailbox Store
or Public Folder Store.
141
Exchange System Manager and MAPI-Based

Clients
Because Exchange System Manager uses MAPI to obtain dynamic information from the
Exchange store, do not install MAPI-based clients, such as Microsoft Outlook, on an
Exchange server or workstation running Exchange System Manager. Exchange System
Manager uses Mapi32.dll to communicate with the Exchange store. Mapi32.dll represents a
core component of the MAPI subsystem and is located in the Winnt\System32 folder. If you
install Microsoft Office Outlook 2000 or later on the same computer that contains Exchange
System Manager, the MAPI subsystem moves to the Program Files\Common
Files\System\Mapi\1033\NT folder. Typically, Outlook installs a stub version of MAPI in the
Winnt\System32 folder, which then routes MAPI calls to the Outlook implementation. If you
replace the Exchange Server 2003 version of Mapi32.dll with the Outlook implementation,
your system could experience version conflicts in the MAPI subsystem and could cause
Exchange System Manager to fail.
Note:
If you must install Outlook and Exchange Server 2003 on the same computer, for
example, because a non-Microsoft solution, such as a MAPI-based backup program,
requires Outlook components, first read Microsoft Knowledge Base article 266418,
"Microsoft does not support installing Exchange Server components and Outlook on
the same computer."
DAV-Based Communication
To create, manage, and delete public folder resources, Exchange System Manager
(specifically the Public Folders snap-in) uses DAV to communicate with the Exchange store.
DAV is an HTTP-based protocol. Therefore, access to the Exchange store is provided
through the World Wide Web Publishing service (w3svc). DAV commands, such as
PROPFIND, SEARCH, DELETE, MOVE, COPY, and OPTIONS, are encoded using XML.
Note:
Exchange System Manager uses DAV for public folder management, because DAV is
the only remotable protocol in Exchange Server 2003 that works with MAPI-based
and general-purpose public folder hierarchies.
DAV-Based Communication and HTTP Virtual

Directories
By default, Exchange Server 2003 creates the following HTTP virtual directories on an
Exchange server:
142
• Exchweb Stores graphics and additional files required for Microsoft Office
Outlook Web Access for Exchange Server 2003. This is a standard virtual directory
that points to the \Program Files\Exchsrvr\Exchweb directory on the server's hard
disk.
• Exchange Used by Outlook Web Access for mailbox access. This virtual
directory binds to the URL \\.\BackOfficeStorage\<server's fully qualified domain
name>\mbx.
• Public Used by Outlook Web Access for public folder access. This virtual
directory binds to the URL \\.\BackOfficeStorage\<server's fully qualified domain
name>\public folders.
• Exadmin Used by Exchange System Manager to administer public folders. This

virtual directory binds to the URL \\.\BackOfficeStorage.
For Exchange System Manager, the most important HTTP virtual directory is the Exadmin
virtual directory. Exadmin provides access to all public folder hierarchies, also named public
folder trees, on an Exchange server. This access is enabled because Exadmin points directly
to the BackOfficeStorage namespace. To provide access to all mailbox and public folder
stores on an Exchange server, the Exchange OLE DB (ExOLEDB) provider registers the
BackOfficeStorage namespace with the OLE DB RootBinder. When you expand the public
folder hierarchy or create, manage, or delete public folders in Exchange System Manager,
communication occurs through the Exadmin virtual directory.
Exchange System Manager also uses other HTTP virtual directories. For example, Exchange
System Manager uses the Public virtual directory to display the content of MAPI-based public
folders. The Public virtual directory exists on all Exchange servers. However, if you create an
additional general-purpose public folder tree and associate it with an additional public store,
Exchange System Manager cannot display public folder contents until you create a virtual
directory to provide HTTP-based access to this hierarchy. For more information about how to
create and configure public folder hierarchies and stores, see the Exchange Server 2003
Administration Guide.
The following figure shows the content of a public folder, as it appears in Exchange System
Manager.
143
The content of a MAPI-based public folder in Exchange System Manager
Exchange System Manager and the Exadmin

Virtual Directory
Most of the interaction between the Public Folders snap-in in Exchange System Manager and
the Exchange store is done through the Exadmin virtual directory. Exadmin relies on the
ExOLEDB provider, which is a component that is not remotable. Exchange System Manager
must access the Exadmin virtual directory on the Exchange server that hosts the public store
associated with the public folder hierarchy. This server is determined with information
obtained from the directory object that corresponds to the public folder hierarchy. The
following figure illustrates how Exchange System Manager communicates with an Exchange
store through the Exadmin virtual directory.
144
Communicating with a public store through the Exadmin virtual directory
Exchange System Manager performs the following steps when it connects to the Exadmin
virtual directory:
1. Obtains list of Exchange stores from hierarchy object Exchange System

Manager reads the msExchOwningPFTreeBL attribute of the public folder hierarchy
object in Active Directory. This determines the list of Exchange servers that host
public stores associated with the public folder hierarchy.
Tip:
You can see the Exchange stores as listed in the msExchOwningPFTreeBL
attribute when you display the properties of the public folder hierarchy in
Exchange System Manager. The stores are listed on the General tab, under
Public stores associated to the folder tree.
2. Selects target server and retrieves Exadmin binding information Exchange

System Manager selects a server that contains a replica of the public folder hierarchy
and then reads the configuration information of that server's Exadmin virtual directory.
The Exadmin virtual directory is represented in Active Directory by a directory object,
named Exadmin, which resides under the server's default HTTP virtual server,
named Exchange Virtual Server. The msExchServerBindings attribute of that
directory object contains the TCP port number that Exchange System Manager must
use to connect to the Exadmin virtual directory on the Exchange server that hosts the
public folder hierarchy. If this attribute is not set, Exchange System Manager uses the
default TCP port 80.
145
Note:
If you are running Exchange System Manager locally on an Exchange server that
hosts a public store associated with the public folder hierarchy, Exchange System
Manager tries to connect to the local server first.
3. Uses binding information to connect to the Exadmin virtual

directory Exchange System Manager uses the TCP port number obtained from the
msExchServerBindings attribute to connect to the Exadmin virtual directory on the
selected Exchange server. It then requests a list of all top level public folders in the
hierarchy. In the HTTP User-Agent header of the HTTP request, Exchange System
Manager identifies itself as an Exchange Admin client. Internet Information Services
(IIS) authenticates the client and returns the list of top level public folders to
4. Displays the top level public folders Exchange System Manager displays the
top level public folders as container objects in the console tree, under the public
folder hierarchy. This step is not illustrated in the figure above.
Note:
By default, only the top level folders in the interpersonal message (IPM) subtree
are displayed, but you can also display the folders in the non-IPM subtree, if you
right-click the hierarchy object and then select View System Folders.
Connecting to a Specific Exchange Server

You can associate a public folder hierarchy with public folder stores from multiple Exchange
servers. When you do this, the hierarchy is replicated between these public stores
automatically. This replication makes sure that all public folder stores are aware of all public
folders in the hierarchy. Therefore, you can connect to any one of these Exchange servers to
manage public folder resources. In fact, changing from one server to another enables you to
verify that all public stores have a consistent view of the hierarchy. For example, you might
want to do this when diagnosing problems related to hierarchy replication. For detailed
instructions about how to connect to a specific Exchange server, see How to Connect to a
Specific Exchange Server in Exchange System Manager.
Note:
Exchange System Manager always connects directly to the Exchange server that
hosts the public store associated with the selected public folder hierarchy. You cannot
connect to a public store through a front-end server.
146
Exchange System Manager and the Default Web

Site
Whether you specify a public folder store to connect to or let Exchange System Manager
make the choice for you, the connection mechanisms remain the same, as discussed earlier
in this section. However, the Exadmin virtual directory must be located on the Exchange
server in the default Web site of IIS. In IIS Manager, make sure that IP Address is set to (All
Unassigned), TCP port is set to 80, and that Host header value is not specified. This is
because Exchange System Manager attempts to connect to TCP port 80 by default and
specifies the name of the Exchange server in the Host header value of the HTTP requests. If
you specify a Host header value for the default Web site in IIS Manager that is other than the
server name, Exchange System Manager cannot access the Exadmin directory. Therefore,
you receive an error message that states that the operation failed due to an invalid format in
the HTTP request. You cannot manage public folder resources, although you might be able to
access public folders in Outlook Web Access. For more information about issues with
accessing the Exadmin virtual directory, see Knowledge Base article 325920, "Error Message
When You View Public Folders in Exchange System Manager."
Note:
You cannot change the Host header value that Exchange System Manager uses
when it connects to the Exadmin virtual directory. Exchange System Manager always
uses the NetBIOS name of the target Exchange server. Therefore, the Web site must
define the server's NetBIOS name in the Host header value parameter or define no
value.
However, you can assign the default Web site that hosts the Exadmin virtual directory a
dedicated IP address and a custom TCP port using IIS Manager. When you display the
properties of the Web site, specify an IP address or custom TCP port on the Web Site tab.
Exchange System Manager tries to connect to TCP port 80 first. If this connection attempt
fails, Exchange System Manager communicates with the IIS Admin service on the Exchange
server through remote procedure calls (RPCs), to determine the required port number. The
IIS Admin service returns the custom port number to Exchange System Manager, because it
is registered in the IIS metabase. Exchange System Manager then registers the custom port
in the msExchServerBindings attribute of the Exadmin directory object. After this, Exchange
System Manager connects to the Exadmin virtual directory, as discussed earlier in this
section.
Communication with the IIS Admin service fails if RPCs are not supported between the
Exchange server and the computer that is running Exchange System Manager. For example,
a firewall blocking access to the RPC Endpoint Mapper through TCP port 135 might prevent
this communication. In this case, Exchange System Manager cannot determine the custom
port dynamically. It is best to use the default port number 80 for the Exadmin virtual directory.
147
Note:
Using Exchange System Manager over network connections that do not support
RPCs is not supported.
The Exadmin Virtual Directory and SSL

Encryption
The Exchange Server 2003 version of Exchange System Manager fully supports Secure
Sockets Layer (SSL). Therefore, you can install an SSL certificate on your Exchange server
and enforce SSL encryption over HTTP, which protects Exchange Server 2003 virtual
directories, such as Public and Exadmin. Enforcing a secure communications channel is a
good idea if the Exchange server and the computer that is running Exchange System
Manager must communicate with each other over a public or untrustworthy network segment.
The following figure illustrates how the process of connecting to an Exadmin virtual directory
through HTTP over SSL (HTTPS) works.
Connecting to Exadmin through HTTPS

148
When connecting to the Exadmin virtual directory over HTTPS for the first time, Exchange
System Manager performs the following steps:
1. Exchange System Manager tries to connect over HTTP, as explained earlier in

this section.
2. Because HTTPS is required for the Exadmin directory, the Web server responds
to the HTTP request with an HTTP status code of 403 – Forbidden.
3. Exchange System Manager queries the IIS Admin service through RPCs for
SSL-specific information, such as the SSL port that must be used to connect to the
Web site that hosts the Exadmin virtual directory. The IIS Admin service returns this
information to Exchange System Manager.
4. Exchange System Manager connects to the Exadmin virtual directory through
HTTPS and displays the list of public folders in the hierarchy.
Note:
The security certificate that you register for the Web site that hosts the Exadmin
virtual directory must list the local Exchange server's fully qualified domain name
(FQDN) as the Web site's common name. Also, the computer that is running
Exchange System Manager must trust the certificate authority that issued the
SSL certificate. Otherwise, Exchange System Manager displays an error
message that states that the SSL certificate is incorrect, and does not display the
public folder hierarchy.
5. Exchange System Manager writes the SSL port number in the

msExchSecureBindings attribute of the directory object that corresponds to the
Exadmin virtual directory. On subsequent connections, you do not have to run the
algorithm to obtain the SSL port number from the server.
How to Display All Information Obtained for

a Mailbox Store or Public Folder Store
This topic explains how to display all information obtained for a mailbox store or public folder
store in the details pane of Exchange System Manager.
Procedure
Display all information obtained for a mailbox store or public folder store
1. Right-click the child container of interest (for example, Mailboxes or
Logons).
149
2. Point to View.
3. Select Add/Remove Columns.
4. In the Add/Remove Columns dialog box, add all entries from the Available
columns list to the list of Displayed columns.
5. Click OK.
How to Connect to a Specific Exchange

Server in Exchange System Manager
This topic explains how to connect to a specific Exchange server in Exchange System
Manager. You may want to do this when diagnosing problems related to hierarchy replication.
Changing from one server to another enables you to verify that all public stores have a
consistent view of the hierarchy.
Procedure
Connect to a specific Exchange server in Exchange System Manager
1. Right-click the public folder hierarchy object (for example, Public Folders) in
2. Select Connect to.
3. Select the target public folder store that you want from the Select a Public
Store dialog box.
Integration with Windows Management

Instrumentation
Exchange System Manager is also a Windows Management Instrumentation (WMI)
management application. WMI communicates with the Windows Management
Instrumentation service (Winmgmt) to access dynamic Exchange system information. WMI is
a subsystem of Microsoft Windows Server 2003, which provides a language-independent
programming model to query and control management information in an enterprise
150
environment. All WMI interfaces are based on Component Object Model (COM). Therefore,
the communication between Exchange System Manager and Winmgmt is based on RPCs.
WMI is based on a three-tier model that includes management applications, the Common
Information Model (CIM) object manager, and WMI providers.
The following figure illustrates the general architecture of WMI.
Three-tier WMI architecture
Management applications, which consume WMI data, are at the top of the WMI architecture.
Exchange System Manager is an example of a WMI management application. You can also
create custom applications and scripts to process WMI data. The management applications
use one common API, WMI, to communicate with the CIM object manager in the middle tier.
The CIM object manager provides the programmable object classes that represent the
underlying information sources.
The CIM object manager is implemented in the WMI service in Windows Server 2003. The
WMI service maintains its own database, named the CIM database, to track which WMI
classes are available and which provider is responsible for supplying instances of those
classes. The class definitions are stored in the CIM database. Static data can also be stored
in the CIM database and retrieved without a provider. However, the WMI subsystem is
designed to obtain dynamic information about a managed system, such as Exchange
Server 2003. This is accomplished completely through WMI providers.
151
WMI providers are at the bottom of the WMI architecture. WMI providers access the CIM
object manager through a set of standardized COM interfaces and act as intermediate agents
between the managed system and the CIM object manager. WMI providers extract
management information from the underlying managed system. They then map this
information to object classes that the CIM object manager presents to the WMI management
applications. Exchange Server 2003 includes many WMI providers and classes. For more
information about these classes, see the WMI documentation in the Exchange SDK.
Exchange System Manager uses the following WMI providers:
• ExchangeDsAccessProvider This WMI provider enables Exchange System

Manager to communicate with the DSAccess component to view and set domain
controllers and global catalog servers, which DSAccess uses to access
Active Directory information. Exchange System Manager communicates with the
ExchangeDsAccessProvider when you click the Directory Access tab in the
Exchange Server 2003 server properties.
The ExchangeDsAccessProvider is implemented in the Microsoft Exchange Management

service (MSExchangeMGMT). If this service is stopped, the ExchangeDsAccessProvider
is unavailable, and you cannot view or change the list of domain controllers and global
catalogs that are used by DSAccess on that Exchange server. However, DSAccess does
not require Exchange Management service to function. DSAccess continues to use the
predefined list of domain controllers and global catalog servers or determines these
dynamically. For more information about DSAccess, see Exchange Server 2003 and
Active Directory.
• ExchangeMessageTrackingProvider This WMI provider gives information

about messages routed through the transport engine of an Exchange server that is
enabled with message tracking. Message tracking is a feature that enables you to
follow the paths of messages as they are transferred through your Exchange
organization. By default, message tracking is disabled. You can select message
tracking for each server from the server's General tab. With message tracking
enabled, status information is written to daily log files, which are stored in the
\Program Files\Exchsrvr\<servername>.log directory (for example, \Program
Files\Exchsrvr\Server01.log). The log file name follows the scheme
<YYYYMMDD>.LOG (for example, 20040321.LOG). Tracking log files are tabulator-
separated text files that are shared for network access on all Exchange servers. The
share name is <SERVERNAME>.LOG.
You can analyze message-tracking information in a text editor when you open message
tracking log files directly, or in the Exchange Message Tracking Center snap-in.
Exchange Message Tracking Center is available as a stand-alone snap-in. It is available
in Exchange System Manager, under the Tools node, and can also be used separately in
custom MMC tools. In Exchange Server 2003, Message Tracking Center reads tracking
information from the ExchangeMessageTrackingProvider on the local computer. If remote
servers are used for the message transfer, the ExchangeMessageTrackingProvider on
152
the local server communicates with the ExchangeMessageTrackingProvider on the

remote servers. In this way, the message path is tracked from server to server across the
Exchange organization and complete information is returned to Message Tracking
Center.
ExchangeMessageTrackingProvider is also implemented in the Microsoft Exchange

Management service. If this service is not running on the local server running Exchange
Server 2003, ExchangeMessageTrackingProvider is unavailable, and Message Tracking
Center does not work. If the Exchange Management service is not running on a remote
server running Exchange Server 2003, incomplete message tracking information might
be returned. However, for backward-compatibility for Exchange 2000 Server, Message
Tracking Center can also access the message tracking network shares directly, using the
Windows Server 2003 Message Block (SMB) protocol.
The following figure illustrates how the Exchange providers and the Exchange Management
service integrate with the WMI subsystem.
Exchange providers in the WMI subsystem

153
Service Configuration in Exchange System

Manager
To support remote updating of configuration settings stored in the registry, Exchange System
Manager requires the Remote Registry service to be running on all Exchange servers. For
example, when you display the properties of a server object in Exchange System Manager
and switch to the Diagnostics Logging tab to view or set the event logging level for the
various categories of Exchange services, Exchange System Manager accesses registry
settings for the corresponding services through the registry API. The categories that appear
for a service on the Diagnostics Logging tab correspond to REG_DWORD parameters stored
in the Diagnostics subkey of the Exchange service, under
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. The following figure illustrates this
relationship for the DSAccess component.
154
Diagnostics logging settings in Registry Editor and in the Properties dialog box for a
server object in Exchange System Manager
The Remote Registry service is bypassed when you work with registry settings on the local
computer. However, if you want to set the diagnostics logging level for an Exchange server
remotely, Exchange System Manager must first use the RegConnectRegistry function of the
registry API to establish a connection to the registry key that you want on the remote
computer. For this function call, the Exchange administrator must have access permissions to
the Remote Registry service. Otherwise, the Remote Registry connection cannot be
established.
Caution:
155
valuable data.
The default configuration for Windows permits only local Administrators remote access to the
registry. To make sure that Exchange administrators can remotely administer an Exchange
server, System Attendant automatically adds those accounts that have an Exchange
administrator role to the access control list (ACL) of the WinReg registry key and grants them
Full Control permissions. This key can be found under the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers.
With the required permissions for the Remote Registry service, the Exchange administrator
can establish a remote connection to the target registry. However, this does not mean that the
Exchange administrator is also permitted to read or write settings of other registry keys. For
example, an administrator might have Full Control permissions for the WinReg key, but no
permissions for the MSExchangeMTA key in the services control database. In this case,
Exchange System Manager could connect to the remote server's registry but might not be
able to list the services or diagnostics categories on the Diagnostics Logging tab. To make
sure that an Exchange administrator can read and write settings for Exchange services,
System Attendant grants Exchange administrators Full Control permissions for the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services key. All subkeys under this
registry key inherit the permissions settings. For more information about the registry settings
for Exchange services, see Exchange Server 2003 Services Dependencies.
Note If Exchange System Manager cannot access the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services key on an Exchange
server, either because a connection to the Remote Registry service cannot be established or
because you do not have sufficient access permissions, you receive an error message that
states that the network path was not found, and you cannot manage the server.
Message Routing Architecture

When a message is routed, it moves from sender to recipient according to a set of message
routing rules. A message route can include multiple hops. A hop is a node along the routing
path. In the routing architecture of a Microsoft Exchange Server 2003 organization, the nodes
along the message route are represented by routing groups. Messaging connectors connect
the nodes, or routing groups, to each other in the internal messaging environment. An
Exchange organization might also be connected to an external messaging environment, such
as the Internet, using messaging connectors that enable messages to enter or leave the
Exchange organization.
• Key elements of the Exchange Server 2003 routing topology You must be
able to identify the components that comprise the message routing topology of an
156
Exchange organization in order to understand the fundamentals of message routing

in Exchange Server 2003.
• Exchange Server 2003 message handling Before examining the actual

routing mechanisms in Exchange Server 2003, you must understand how
Exchange 2003 routes messages that are addressed to recipients who reside on the
same Exchange server as the sender and recipients who reside on other Exchange
servers in the same routing group, in other routing groups, or on external messaging
systems.
• Exchange Server 2003 message routing Exchange Server 2003 uses link
state information to make dynamic routing decisions, rather than routing decisions
based on a static routing table. To understand dynamic message routing in
Exchange Server 2003, you must understand how Exchange Server 2003 selects
message routes and how changes to the routing topology influence the message
routing process.
• Propagation of link state information Procedures must exist to replicate link

state information between Exchange servers. These procedures ensure that each
server has accurate information about the whole organization. With this information,
the server can recalculate the optimal path to any destination in the messaging
environment according to the current state of the routing topology. You must
understand how servers propagate changes to the message routing topology across
an Exchange Server 2003 organization. In addition, you must understand the details
of the link state table (the table that contains the routing information) and the
algorithm that is used to replicate link state information between Exchange servers.
• Backward Compatibility with Exchange Server 5.5 Several routing issues

arise when you integrate Exchange Server 2003 into an Exchange Server 5.5
organization. You must understand these issues to understand how Exchange
Server 5.5 can use Exchange Server 2003 connectors and vice versa.
This section assumes that you are familiar with routing group topology design and the
configuration of messaging connectors. For more information on transport and routing, see
the Exchange Server 2003 Transport and Routing Guide.
Exchange Server 2003 Message Routing

Topology
The following figure illustrates an Exchange Server 2003 organization routing topology with
multiple internal routing groups connected through routing group connectors and a connector
that connects the Exchange organization to an external messaging system. In this topology,
routing group A represents a central routing hub. All messages to remote routing groups
(routing groups B and C) and the non-Exchange messaging system are routed through
157
routing group A. Multiple bridgehead servers are deployed in routing group A to provide
redundant message transfer paths.
An Exchange Server 2003 message routing topology
The message routing topology shown in the figure above includes the following key
components:
• Routing groups These are logical collections of servers, used to control mail
flow and public folder referrals. Routing groups share one or more physical
connections. In a routing group, all Exchange servers communicate and transfer
messages directly to one another, using Simple Mail Transfer Protocol (SMTP) virtual
servers. In a native mode organization, routing groups can include servers from
different administrative groups. However, in a mixed mode organization, routing
groups cannot span multiple administrative groups, due to backward compatibility
with Exchange Server 5.5. This is because the routing topology in Exchange 5.5 is
defined by sites, and sites provide the functionality of both the administrative group
and the routing group.
Tip:
SMTP works well over any type of TCP/IP connection. Therefore, a routing group
does not necessarily define regions on a computer network with high network
bandwidth. Routing groups can span slow network connections, if the connection
158
is permanent and reliable. For example, if all servers in Figure 5.1 can
communicate directly through TCP/IP, you might consolidate all Exchange
servers into one routing group, thus eliminating four of the five bridgehead
servers and all routing group connectors. This significantly streamlines the
routing group topology. In Figure 5.1, the bridgehead server running a connector
to the non-Exchange messaging system must remain connected to the external
messaging system. Note, however, that all servers in a routing group periodically
poll the routing group master. Gaining control over server-to-server
communication might require you to implement multiple routing groups, which
might be especially important if communication over wide area network (WAN)
connections generates costs. For more information about the design and
configuration of routing group topologies, see Exchange Server 2003 Transport
and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=26041).
• Routing group connectors A routing group connector enables message

transfer between two routing groups. The following Exchange connectors can be
used to establish message transfer paths between routing groups:
• Routing group connectors A routing group connector provides a one-

way connection path in which messages are routed from servers in one
routing group to servers in another routing group. Routing group connectors
use Simple Mail Transfer Protocol (SMTP) to communicate with servers in
connected routing groups. Routing group connectors provide the best
connection between routing groups.
Note:
The Routing Group Connector (note the capitalization) is a specific type of
connector that can only be used to connect routing groups with each other.
Other connectors that can connect routing groups are the SMTP connector
and X.400 connector. However, these connectors can also be used to
connect an Exchange organization to an external messaging system through
SMTP or X.400. To avoid confusion, this guide uses "Routing Group
Connector" to refer to the specific connector that can only be used between
routing groups and "routing group connector" to refer to all types of
connectors that can be used to connect routing groups.
• SMTP connector An SMTP connector can be used to connect routing

groups, but this is not recommended. SMTP connectors are designed for
external message delivery. SMTP connectors define specific paths for e-mail
messages that are destined for the Internet or an external destination, such
as a non-Exchange messaging system.
• X.400 connectors Although you can use X.400 connectors to connect

routing groups, X.400 connectors are designed to connect servers running
Exchange with other X.400 systems or to servers running Exchange
Server 5.5 outside an Exchange organization. A server running
159
Exchange Server 2003 can then send messages over this connector using
the X.400 protocol.
Note:
X.400 connectors are available only in Exchange Server 2003 Enterprise
Edition.
• Connectors to non-Exchange messaging systems These connectors

support message transfer and directory synchronization between Exchange and non-
Exchange messaging systems. When appropriate connectors are implemented, the
user experience is similar on both messaging systems and the transfer of messages
and other information between the Exchange and non-Exchange messaging system
is transparent to the user. However, some message properties might be lost during
message conversion from an Exchange format to a non-Exchange format, or vice
versa.
• Mailbox servers A mailbox server is an Exchange server configured to host

mailboxes. Users can access their mailboxes through a variety of clients, such as
Microsoft Office Outlook, Microsoft Office Outlook Web Access, Microsoft Office
Outlook Mobile Access, Post Office Protocol version 3 (POP3)-based clients, and
Internet Message Access Protocol version 4rev1 (IMAP4)-based clients. In the
Exchange Server 2003 routing topology, mailbox servers are typical sources and
destinations of e-mail messages.
• Bridgehead servers A bridgehead server is a connection point that performs

message transfer from one routing group to another routing group, or to an external
messaging system. In large organizations, bridgehead servers are often separated
from mailbox servers to avoid performance bottlenecks. Mailbox servers create
bottlenecks due to increased processing requirements during peak messaging hours.
Bridgehead servers are identified as local or remote bridgehead servers, as follows:
• Local bridgehead servers This server hosts a connector and uses it to

transfer messages. When you create a connector, you designate at least one
Exchange server as a bridgehead server. You can also designate multiple
bridgehead servers for load balancing, performance, and redundancy. For
example, the default option for routing group connectors is Any local server
can send mail over this connector. In this case, all Exchange servers in
the local routing group can use the connector to transfer messages.
• Remote bridgehead servers The remote bridgehead server, specified in a

connector configuration, is the server (in the connected routing group or non-
Exchange messaging system) that receives all messages transferred over a
connector. Routing Group Connector can have multiple remote bridgehead servers
(that is, remote virtual SMTP servers). SMTP connector and X.400 connector,
however, can have only one remote bridgehead server per connector instance.
Remote bridgeheads are also named target bridgeheads.
160
Exchange Server 2003 Message Handling

Message transfer in Exchange 2003 is primarily the task of the SMTP service. Note that the
Exchange 2003 SMTP transport engine is involved in all message handling, regardless of the
final destination of the message. A message might be destined to a user on the same server,
another server in the same routing group, a server in another routing group, or a server in an
external messaging system. The following figure shows the SMTP transport architecture of
Exchange Server 2003. For detailed information about the components in the SMTP transport
engine and their responsibilities, see SMTP Transport Architecture.
161
The Exchange Server 2003 transport architecture
In Exchange Server 2003, the SMTP transport engine handles messages as follows:
1. A message is received through SMTP, remote procedure calls (RPCs), X.400, or

MAPI transfer protocols, as outlined in the following table.
162
Incoming message transfer protocols
Transfer Protocol Comments
SMTP Exchange 2000 and Exchange Server 2003

servers communicate with each other through
SMTP. Non-Exchange hosts and POP3 and
IMAP4 clients also use SMTP to transfer
messages to a server running Exchange
Server 2003. These messages are received
through the SMTP protocol service, which
saves them in the \Exchsrvr\Mailroot\vsi
1\Queue folder on the file system before
transferring them to the pre-submission
queue. Each virtual SMTP server on an
Exchange 2003 server maintains its own
subdirectory under the Exchsrvr\Mailroot\
folder. For example, the path of the default
virtual SMTP server's mailroot folder is
\Exchsrvr\Mailroot\vsi 1.
Another way to submit messages to the

SMTP service is to use the \Pickup
subdirectory under the virtual SMTP server's
mailroot folder. Because the message file
must be in RFC-822 format for the SMTP
service to obtain and successfully process the
message, this message transfer is also
considered to be SMTP-based.
163
RPCs Exchange 5.5 servers communicate with each

other in the local site through RPCs.
Exchange 5.5 message transfer agents
(MTAs) use RPCs to transfer e-mail
messages to each other in the local site,
without requiring a definition of a messaging
connector. If Exchange Server 2003 is
deployed in an existing Exchange 5.5 site,
messages are exchanged with Exchange 5.5
through RPCs using the Microsoft Exchange
MTA Stacks service.
When using a site connector, Exchange 5.5

servers in different sites also communicate
with each other using RPCs. Exchange 2003
can communicate with a site connector if you
deploy a routing group connector that
connects to an Exchange 5.5 server in a
remote site. In this case, the routing group
connector automatically switches to RPCs,
instead of SMTP, for backward compatibility
with Exchange 5.5.
X.400 If you want to exchange messages with a

remote X.400 message transfer agent (MTA),
an X.400 connector must be configured. As
mentioned earlier, you can also use X.400
connectors to connect routing groups to each
other in your Exchange organization. The
Microsoft Exchange MTA Stacks service
receives incoming X.400 messages and
passes them to the Exchange store. The
Exchange store driver then places the
messages in the pre-submission queue. For
more information about X.400 architecture,
see X.400 Transport Architecture.
164
MAPI MAPI-based clients, such as

Microsoft Outlook, in addition to MAPI-based
messaging connectors, such as Connector for
Lotus Notes and Connector for Novell
GroupWise, communicate directly with the
Exchange store. For example, MAPI-clients
put outgoing messages in the Outbox folder
of the user's mailbox and then notify the
Exchange store to transfer the message.
However, MAPI-based messaging connectors
use an MTS-IN folder in the Exchange store
as their incoming message queue. MAPI-
based messaging connectors convert inbound
messages into Exchange format and then
place them in the MTS-IN folder. Either way,
the MAPI message is put in the Exchange
store, and the Exchange store driver then
puts the message in the pre-submission
queue. For more information about MAPI-
based messaging connectors, see Gateway
Messaging Connectors Architecture.
2. The pre-submission queue is the entry point in the advanced queuing engine.
When a message is put into the pre-submission queue, custom SMTP processing
code, such as event sinks for antivirus screening, processes the message. The
advanced queuing engine then moves the message to the pre-categorization queue,
so that the categorizer, an internal component of the SMTP transport engine, can
process it further.
3. The categorizer resolves both recipient and sender addresses, expands any
mail-enabled groups, checks restrictions, applies per-sender and per-recipient limits,
and more. If the recipient's mailbox resides in the local Exchange Server 2003
organization, the categorizer marks the recipient as local by setting a per-recipient
property indicating the fully qualified domain name (FQDN) of the recipient's home
server. This is an important routing step. Later, the advanced queuing engine uses
the recipient's home server FQDN to determine the message transfer path.
4. After categorization, the advanced queuing engine puts the message in the post-
categorization queue. Now, a distinction must be made between messages for local
recipients and messages for recipients on remote systems, as follows:
• Local delivery For local recipients, routing is skipped. The mailbox store
that holds the target mailbox is stamped on the message and the advanced
165
queuing engine transfers the message to the Local Delivery queue. From the
Local Delivery queue, the Exchange store driver obtains the message and
puts it in the mailbox of the recipient.
• Remote delivery The routing engine must process all messages to non-
local recipients, because the SMTP transport engine must find an available
transfer path for the destination. Correspondingly, the advanced queuing
engine transfers the message to the pre-routing queue, calls the routing
engine, and then passes the destination address (that is, the FQDN of the
recipient's home server for internal recipients or the SMTP domain name for
external recipients) to the routing engine. The routing engine returns the next
hop that the message will use to the caller and classifies the next hop, as
listed in the following table.
Hop types for remote delivery
Hop Type Comments
The next hop is to the local server This indicates that the transport engine must
pass the message to the Exchange MTA for
transfer, either through RPCs to an
Exchange 5.5 server in the local routing
group, through an X.400 connector to a
remote X.400 MTA, or through a MAPI-based
messaging connector, such as Connector for
Lotus Notes or Connector for Novell
GroupWise, to a non-Exchange messaging
system.
The next hop is to a server in the local routing This indicates that the transport engine must
group pass the message to the default virtual SMTP
server for transfer to the destination over
SMTP.
The next hop is to a server in a remote This indicates that the transport engine must
routing group pass the message to a routing group
connector on the local Exchange server. It
must be noted, however, that this type applies
only to messages transferred over SMTP. If
you use X.400 connectors to connect routing
groups, the transport engine passes the
messages to the Exchange MTA (that is, the
next hop is to the local server).
166
Hop Type Comments
The next hop is to a server outside the This indicates that the transport engine must
Exchange organization pass the message to an SMTP connector or
virtual SMTP server that can transfer the
message to the external messaging system.
Again, this hop type only refers to
destinations reachable through SMTP. If the
message is destined to a non-Exchange
messaging system connected through a
MAPI-based connector that is controlled by
the Exchange MTA, the transport engine
passes the messages to the Exchange MTA
(that is, the next hop is to the local server).
The next hop is to a server that is currently This indicates that a destination path exists,
unreachable but that this path is currently unavailable. The
transport engine retains the message until the
transfer path is available again or until the
message expires and must be returned to the
sender with an NDR.
The next hop is to a server that is This indicates that no final destination path
unreachable exists, and the transport engine returns the
message to the sender with an NDR.
5. The advanced queuing engine caches the next hop type information and
destination, and moves the message to a corresponding link queue. Link queues are
dynamic and are managed by Queue Manager. The name of each link queue
matches its remote delivery destination.
Note:
Link queues exist and are available in the Queue viewer of Exchange System
Manager only when messages are waiting for transfer to the corresponding
destination. Queue Manager expires a link queue about a minute after the last
message in the link queue is transmitted.
6. Messages in link queues other than the Exchange MTA queue are transferred
using the SMTP protocol engine. However, messages in the Exchange MTA queue
are transferred to the Exchange MTA outbound message queue in the Exchange
store, which is a system folder named MTS-OUT. The Exchange store driver
performs this task. The Exchange MTA obtains the message and then communicates
with the routing engine through MTARoute.dll to determine the appropriate and
available connector. If the message is for a connector to a non-Exchange messaging
system, the Exchange MTA places the message in that connector's outbound
167
message queue in the Exchange store (the connector's MTS-OUT folder). Otherwise,
the MTA transfers the message directly using RPCs or an X.400 connector. For more
information about the Exchange MTA, see X.400 Transport Architecture.
Exchange Server 2003 Message Routing

For messages to non-local recipients, the routing engine must provide the advanced queuing
engine with information about the next hop host on the transfer path of the destination and
the next hop type, as discussed in the previous section. The next hop host is the actual
routing address and the next hop type determines how the advanced queuing engine handles
the message. To provide this vital information, the routing engine must have a complete view
of the whole routing topology, including all routing groups and their servers, routing group
connectors, and connectors to external messaging systems. In Exchange Server 2003, this
information is available in Active Directory directory service.
Message Routes and Link State Table

Every Exchange 2003 server maintains its own routing table, called the link state table,
dynamically in memory, based on Active Directory and link state information, as follows:
• Routing-related Active Directory information This information is stored in

attributes of the organization object, routing group objects, connector objects, and
server objects. These objects reside in the configuration directory partition and define
the routing topology of the entire Exchange organization.
Note:
Administrative groups are not part of the routing topology in an Exchange
organization.
• Link state information This information specifies whether each connector in

the routing topology is available (up) or unavailable (down). Link state information is
dynamic and might change when a connector experiences transfer problems or when
transfer issues are resolved. For more information about link state changes and the
propagation of link state information across an Exchange organization, see Link State
Propagation.
Initializing the Link State Table

Upon startup, each Exchange server initializes its link state table with the following
information from Active Directory:
• Organization object The routing topology boundary is the Exchange

organization. That is, the link state table does not include any information about
168
external bridgehead servers or messaging connectors in an external messaging

system. As far as the routing engine is concerned, the routing topology ends at the
connector to the external messaging system. Accordingly, the routing engine reads
the GUID that is registered in the objectGUID attribute of the Exchange organization
object in Active Directory and stamps the link state table with this GUID to identify the
organization to which this routing information belongs.
• Routing group objects The routing engine enumerates all routing groups that
exist in any administrative groups and queries each routing group for all object
attributes, including the msExchRoutingGroupMembersBL attribute that contains a
list of all routing group member servers. The routing engine places this information in
the link state table. The routing engine also places the servers together with the
GUID of the server's routing group in a server cache in memory. Each entry in the
server cache is a server FQDN appended by the server's routing group GUID.
Another important routing group attribute is the msExchRoutingMasterDN attribute, which

points to the distinguished name of the routing group master in the selected routing
group. For more information about the tasks and responsibilities of the routing group
master, see the discussion later in this section.
• Messaging connector objects The routing engine enumerates all child objects
with an object type of msExchconnector that exist in the Connections container of
each routing group. The msExchconnector objects in the Connections container are
the routing group connectors and connectors to external messaging systems
configured in the routing group. The routing engine reads all attributes from these
connector objects to determine address spaces, cost values, restrictions, and more.
The routing engine places the information for each connector in the link state table.
This enables messages to destinations outside the local routing group to be routed.
The process continues until the routing engine identifies all directly and indirectly connected
routing groups and queries for the configuration details of their messaging connectors. When
this process ends, the routing engine has a complete view of all available transfer paths
across the Exchange organization. All links are assumed to be up and available for message
transfer. Following the initialization of the link state table, the routing engine communicates
with the Microsoft Exchange Routing Engine service on the local server to obtain dynamic link
state information that reflects the current state of each connector. The Exchange Routing
Engine service connects to the routing group master in the local routing group through TCP
port 691 to retrieve this information. For more information about link state information, see the
section, "Examining the Link State Table," later in this topic.
Routing Engine and Exchange Routing Engine

Service
The routing engine in the transport subsystem and the Exchange Routing Engine service
have different roles. The Exchange Routing Engine service does not perform any message
169
routing. The Exchange Routing Engine service communicates link state information between
servers that are running Exchange 2000 Server and Exchange Server 2003 in the local
routing group. The Exchange Routing Engine service is implemented in resvc.dll, which
resides in the \Program Files\Exchsrvr\bin\ directory. The service name is RESvc. For more
information about the Microsoft Windows services of Exchange Server 2003, see Exchange
Server 2003 Services Dependencies.
The Exchange Routing Engine service is an intra-routing group link state communication
service, instead of a routing engine. The actual routing engine that the SMTP advanced
queuing engine and Exchange MTA use to route messages is implemented in a file that is
named reapi.dll. For the Exchange MTA, some additional code is in mtaroute.dll. Therefore,
when the Exchange Routing Engine service is stopped, both the advanced queuing engine
and Exchange MTA still use the code in reapi.dll to route messages. Only dynamic updates to
the link state table are not received any longer.
Note:
Although not generally recommended, you can disable the Exchange Routing Engine
service on all servers that are running Exchange Server 2003 in an organization. The
code in reapi.dll can still initialize the link state table on each server with information
from Active Directory, but there are no dynamic updates to the link state table. In this
case, Exchange Server 2003 performs static message routing.
Examining the Link State Table

The link state table is a small, in-memory database that is not stored on disk. To examine the
entries that the routing engine uses to make routing decisions, you can use the
Exchange Server 2003 WinRoute tool (Winroute.exe), which is available for download from
the Downloads for Exchange Server 2003 Web site.
Note:
The WinRoute tool also shipped with Exchange 2000 Server, but it is best to
download and use the Exchange Server 2003 version of this tool on all
Exchange 2000 and Exchange Server 2003 servers in your organization.
The WinRoute tool connects to the link state port, TCP port 691, on the selected Exchange
server and extracts the link state table. The information in this table is a series of GUIDs and
American Standard Code for Information Interchange (ASCII) text that represent routing
groups, routing group members, and connectors in the routing groups. The link state table
also includes information about the configuration of each connector. The information fields in
the link state table are separated by parentheses as follows:
'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group
Addresses' (Routing Group Members) (Connectors in Routing Group (Connector
configuration))).
170
The following is a shortened example of a link state table (all but one routing group removed):
d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623
(489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2
c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D
{4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;*
{55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-
4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 )
( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {}
{23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative
Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B 0 0 0 0 ffffffff ffffffff 0
1 0 () 0 () 0 () 0 () ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400
{23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) BH () TARGBH
( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE
UP)))
(... next routing group... (... next routing members...) (... connectors in routing
group (... connector configuration..)))
The following table maps this information to the various information fields in the link state
table.
Information in the link state table
Field Value Comments
Organization objectGUID d38082e7c9ecd74dbff32bada8 The GUID that is registered

932642 in the objectGUID attribute
of the Exchange
organization object in
Active Directory.
171
MD5 Digest d037d6eaf2fa7cd10934aca433 An MD5 digest or hash

390623 value. This is an encrypted
signature that represents the
version number for the link
state table. Based on this
information, routing engines
can determine whether they
have the same link state
information. If the
information differs, routing
engines exchange OrgInfo
packets to determine which
server has the most up-to-
date information. The
OrgInfo packet contains the
link state table, with all
details and states of the
routing topology. The
propagation of link state
information is discussed
later in this section.
Routing Group objectGUID 489416bfa3a4ff459b8f4403f2 The GUID that is registered

0cad0d in the objectGUID attribute
of the routing group object to
which the routing
information belongs. This
GUID follows next in the link
state table.
172
Routing Group Master 1650c1fe32aef740be236e1089 The GUID that is registered

objectGUID e0da6a in the objectGUID attribute
of the server that acts as the
routing group master in this
routing group.
The routing group master

within each routing group is
responsible for maintaining
and communicating link
state information to all
routing group members.
Only one routing group
master exists per routing
group. For more information
about the role of the routing
group master, see the
discussion later in this
section.
173
Version Info 8 0 2 The values 8 0 2 are the

c2da71f9b39ec748aaf44119a2 major, minor, and user
bdcb36 versions of the link state
information. The routing
engine uses this version
information to classify
updates to the link state
information, as follows:
• Major
updates Represen
t routing topology
changes, such as
connector
configuration
changes (that is,
adding or deleting a
connector, adding or
deleting an address
space on a
connector, or
designating a new
server as the routing
group master).
• Minor
updates Represen
t changes to the
availability of a
virtual server or
connector. For
example, the state
of a connector might
change from up to
down if the
connector's source
bridgehead server is
unavailable.
• User
updates Represen
t changes that occur
when services are
started or stopped
174
Routing Group Addresses {26}*.489416BF-A3A4-FF45- Maps SMTP, X.400, X.500,

9B8F-4403F20CAD0D and address information to
{4c}c=DE;a= individual routing group
;p=TailspinToys;o=Exchange GUIDs. The routing engine
;cn=489416BF-A3A4-FF45- uses this information to
9B8F-4403F20CAD0D;* generate an internal server
{55}/o=TailspinToys/ou=Fir cache, which is used to
st administrative identify the routing group of
Group/*/489416BF-A3A4- each server in the routing
FF45-9B8F-4403F20CAD0D topology. The server cache
is an internal table of the
routing engine.
For example, assume that

SERVER01 in a routing
group named First Routing
Group has an FQDN of
SERVER01.TailspinToys.co
m. According to the routing
group address definition, the
routing engine creates an
entry for SERVER01 in the
server cache, as follows:
SERVER01.TailspinToys.com.
489416BF-A3A4-FF45-9B8F-
4403F20CAD0D.
During a routing event,

when the advanced queuing
engine passes the FQDN to
the routing engine, the
routing engine looks up the
server cache, finds the entry
for
SERVER01.TailspinToys.co
m, and quickly determines
the target routing group. The
principle is the same for
X.400 and X.500 addresses;
only the address information
is more complex.
175
Routing Group Members ( Contains a list of all servers

1650c1fe32aef740be236e1089 that belong to the routing
e0da6a YES 1 1b20 group and identifies their
{10}0701000000000101 ) state. Note, however, that
the routing engine does not
use this information for
message routing. As
discussed earlier in this
section, the routing engine
uses the server cache.
The routing group members
are listed in the Routing
Group Members () list for
the purposes of system
monitoring. You can view
this information in Exchange
System Manager, when you
open the Tools node, then
Monitoring and Status,
and then Status.
The server status entries in

the Routing Group Members
() list contain the following
information:
• The objectGUID
of the server:
1650c1fe32aef740b
e236e1089e0da6a
• Whether the
member is
connected to the
routing group
master. YES
indicates that the
server is connected.
• Server version
number: 1
• Build version:
1b20 hex = 6944
• User data:
176
Connectors in Routing ( Starting at the next open

Group aa582d35e9621c4ca8ae57aa33 parenthesis, each connector
d953a1 ( CONFIG )) that belongs to the routing
group is listed in a separate
entry that includes the
connector's objectGUID and
the configuration information
that the routing engine uses
to make message routing
decisions.
The connector configuration

information in the link state
table has the following
fields:
Connector objectGUID aa582d35e9621c4ca8ae57aa33 The GUID that uniquely

d953a1 identifies the connector in
the Exchange organization.
177
Connector Type {4}SMTP Following the CONFIG

keyword, this field identifies
the connector type. The type
can be SMTP, X.400, Notes,
or Exchange Development
Kit (EDK). The Notes and
EDK types refer to instances
of a MAPI-based messaging
connector connecting to a
non-Exchange messaging
system. For more
information about MAPI-
based connectors, see
Gateway Messaging
Connectors Architecture.
Tip:
The number in curly
brackets is not an
identifier. This
number indicates
the string length of
the field value in
hexadecimal format.
Note:
There is no explicit
type for routing
group connectors.
Routing group
connectors use
SMTP to transfer
messages.
178
Source Bridgehead Address {} This field can have one of

three values:
• No value If no
source bridgehead
server is specified,
then any server in
the local routing
group can use this
connector to transfer
messages. This
applies to routing
group connectors if
the option Any local
server can send
mail over this
connector is used.
• A connector
GUID For SMTP
connectors and
routing group
connectors, you can
specify specific local
bridgehead servers,
in which case the
Source Bridgehead
Address field lists
the connector GUID
appended by an
"_S" (without the
quotation marks), to
indicate a source
bridgehead, such
as:
{23}_76290a25817c0643a
1a6999e669b1d5f_S
The local bridgehead

servers are then listed
later in the BH field in
the connector
information.
• A bridgehead
179
Destination Bridgehead {23}_aa582d35e9621c4ca8ae5 As with the Source

Address 7aa33d953a1_D Bridgehead Address field,
this field can have one of
three values:
• No
value X.400
connectors and
MAPI-based
connectors do not
have a destination
bridgehead server in
the link state table.
These connectors
use connector-
specific information
to determine their
target system, such
as the remote host
name in the stacks
configuration of an
X.400 connector.
• A connector
GUID For routing
group connectors,
the Destination
Bridgehead Address
field lists the
connector GUID
appended by a "_D"
(without the
quotation marks) to
indicate a
destination
bridgehead. In this
case, the target
bridgehead servers
are listed later in the
TARGBH field in the
connector
information.
• A bridgehead
180
Legacy Distinguished Name {63}/o=TailspinToys/ou=Fir This is the distinguished

st administrative name of the connector in
Group/cn=Configuration/cn= legacy Exchange 5.5
Connections/cn=RGC RG A <- directory format. The value
> RG B corresponds to the
legacyExchangeDN attribute
of the connector object in
Active Directory.
Schedule ID 0 The Schedule ID field is not

used and is always set to 0.
The advanced queuing
engine and Exchange MTA
query Active Directory to
determine the activation
schedule of a connector.
181
Restrictions 0 0 0 ffffffff ffffffff 0 The Restrictions field

1 0 () 0 () 0 () 0 () identifies the scope of the
connector, message size
restrictions, and other
constraints, as follows:
• The scope of
the connector is
identified by the first
digit. A value of 0
indicates that the
scope is
"Organization." A
value of 1 indicates
that the scope is
"Routing Group."
Note:
Routing group
connectors always
have a scope of
"Organization."
Connectors to
external messaging
systems can be
restricted to the
local routing group.
• The next digit

indicates whether
triggered delivery is
configured. A value
of 0 means no
triggered delivery. A
value of 1 means
that the remote host
must trigger the
message transfer
(for example,
TURN/ETRN).
• The third digit

identifies the
message type (high,
182
Address Spaces ARROWS ( {2}RG Each connector has at least

{20}83bd0e29fad06d4eb8b00f one associated address
aab3265cd5 1 {4}X400 space. The routing engine
{23}c=DE;a= uses this information to
;p=TailspinToys;o=Exchange determine possible
; 1 ) connectors for a particular
message by comparing the
recipient addresses with
available address space
information.
In the link state table, the
ARROWS () list contains the
individual address spaces
that belong to the connector.
Each address space entry
contains the following three
pieces of information:
• Address space
type The address
space type
determines the
format of the
address space
information that
follows in the next
position. For
example, an X.400
address space
requires address
space information in
a valid X.400 format.
An SMTP address
space, on the other
hand, contains parts
of an SMTP domain
name. For routing
group connectors,
the address space
type is RG, which
stands for a routing
group objectGUID.
• Address
183
Source Bridgeheads BH () The BH field lists the local

bridgehead servers for the
connector and their status
information. Bridgehead
servers are identified using
the following three pieces of
information:
• Bridgehead
Server
objectGUID The
GUID of a virtual
SMTP server, which
is specified in the
connector
configuration as a
local bridgehead
server.
• Bridgehead
Server
Status Information
that indicates the
availability of the
bridgehead server,
as follows:
CONN_AVA
IL The
bridgehead
server is
available.
VS_NOT_S
TARTED A
virtual
SMTP
server is
stopped or
is not
started.
184
Destination Bridgeheads TARGBH As with the BH () list, the

( 766a192b43bfc3459ee85608 TARGBH () list contains the
d65a98a9 CONN_AVAIL destination bridgehead
{19}server01.TailspinToys. servers for a connector. This
com ) list is particularly important
for routing group
connectors, which can have
more than one remote
bridgehead server.
In the example, the following

information identifies the
remote bridgehead server:
• Bridgehead
Server
objectGUID 766a19
2b43bfc3459ee85608d
65a98a9
• Bridgehead
Server
Status CONN_AVAIL
• Virtual Server
FQDN {19}server0
1.TailspinToys.com
185
Status STATE UP The status of the connector.

This field can have two
possible values:
• STATE
UP Indicates that
the connector is
available.
• STATE
DOWN Indicates
that the connector is
unavailable.
The connector state is

derived from the state of the
connector's source
bridgehead servers. A
connector is STATE UP only
if at least one source
bridgehead server is
available (CONN_AVAIL). If
none of the connector's
source bridgehead virtual
servers is started
(VS_NOT_STARTED) or the
source bridgeheads cannot
establish a connection
(CONN_NOT_AVAIL), the
connector state is STATE
DOWN.
Note:
For a connector to
be marked as down,
all local bridgehead
servers for this
connector must be
unavailable. Routing
group connectors
configured to use
the option Any local
server can send
mail over this
186
Note:
The WinRoute tool provides an intuitive view of the routing topology and link state
table by resolving the GUIDs in the link state table to names in a format that you can
read, if the tool has access to Active Directory. The upper pane of the WinRoute
program window displays the interpreted data, the middle pane lists all existing
address spaces, and the lower pane displays the raw information from the link state
table. For more information about the WinRoute tool, see tools downloads at Tools for
Exchange Routing Path Selection

In an organization with multiple routing groups, various routes might lead to the same
destination. Typically, the most efficient (that is, the shortest or cheapest) route is used for
message transfer, and additional routes stand by, in case the best route is temporarily
unavailable. For example, in the topology shown in the following figure, multiple transfer
routes exist between all routing groups.
187
A routing topology with five routing groups
Note:
Message routing should follow the physical network topology. If the underlying
network topology is designed in a true hub-and-spoke arrangement (with routing
groupA as the hub), it makes little sense to define routing group connectors as shown
in the figure above. Instead, routing groups B, C, D, and E should be connected
directly to routing groupA, and all inter-routing group message transfer should be
routed through routing groupA. In a genuine hub-and-spoke arrangement, there are
no alternate message paths, and the routing path selection is straightforward. For the
explanations in this section, however, it is assumed that the physical network
topology is a mesh that follows the arrangement of routing group connectors shown.
The routing engine uses the following information to determine the best route:
188
• Address space When configuring routing group connectors, you associate

possible destinations with messaging connectors by using the Connected Routing
Groups tab in the connector properties. However, the routing group connector does
not provide this tab. Because this connector is used only to connect to routing
groups, the routing engine can determine the routing group address spaces from the
connector configuration.
Routing group GUIDs and RG address spaces
Address spaces can be added to a connector through the Address Space tab. As
mentioned in the "Information in the link state table" table, address spaces consist of an
address type, such as RG, SMTP, X400, MSMAIL, or CCMAIL, an address , and a cost
value. The cost value that you assign to an address space is an important routing
criterion. The routing engine uses the Dijkstra shortest-path algorithm to make routing
decisions. This algorithm is based on cost values.
189
• Connector scope Connectors to external messaging systems might be

restricted to the connector's routing group, in which case only users in the local
routing group of the connector are permitted to use this connector. By default, all
connectors have a scope of Entire Organization.
Note:
Routing group connectors are always available across the whole organization.
• Restrictions The routing engine determines the message size, priority, and
message type (that is, system or non-system message). The routing engine
compares these properties with available connector restriction information. It then
excludes those connectors that cannot transfer the message due to effective
connector restrictions from the list of potential connectors.
• Status Only available connectors are included in the route selection process.
The status field of each connector indicates whether the connector is available
(STATE UP) or unavailable (STATE DOWN).
Routing Path Selection Process

To select the best route to the destination, the routing engine calculates the shortest transfer
route from the source routing group to the destination routing group across the Exchange
organization, using the Dijkstra shortest-route algorithm. The routing engine then determines
the next hop on the shortest route that the advanced queuing engine should use for message
transfer.
The routing path selection is a two-step process:
1. The advanced queuing engine calls the GetMessageType method on the

IMessageRouter interface of the routing engine. In the GetMessageType method, the
advanced queuing engine passes the message to the routing engine in the form of a
MailMsg object.
In this step, the routing engine performs the following processes:
a. It checks message-trace information to detect loops. If a message loop is

detected, the message is dropped with an NDR to the sender.
b. It reads or recalculates (if necessary) the current organization topology

(that is, it determines the list of shortest routes to all destinations in the
routing topology, starting from the local routing group).
c. It checks and possibly refreshes restriction information about connectors

in the link state table.
d. It determines all connectors to the message destination in the

organization topology, and then analyzes message characteristics and
190
connector restrictions to exclude all those connectors that must not be used
to transfer the message.
e. It computes a filter value for the message, which uniquely defines the
message type. The message type identifies the actual path that messages
with similar characteristics can use. The message type is cached. Therefore,
the routing engine does not recalculate the filter value for subsequent
messages with similar characteristics.
Note:
The advanced queuing engine maintains a separate message queue for
each message type.
f. It creates associated message types. An associated message type is
similar to the actual message type, but is calculated with relaxed restrictions.
Associated message types enable the SMTP transport subsystem to return
extended error codes if a transfer path is not available for the actual
message type because of connector restrictions.
g. It returns the index of the cached message type to the advanced queuing
engine.
2. The routing engine determines the next hop on the shortest route. To complete
this step, the advanced queuing engine calls the GetMessageType method on the
IMessageRouter interface. The most important information that the advanced
queuing engine passes to the routing engine at this point is the destination address
and the message type ID. For recipients in the Exchange organization, the
destination address is the FQDN of the recipients' home server. The routing engine
determines the destination routing group from the server cache, checks the available
route for the message type, and returns the next hop on the route to the destination
routing group to the advanced queuing engine. The advanced queuing engine can
then transfer the message to the next hop on the way to the destination.
Dijkstra's Shortest-Path Algorithm

To make correct routing decisions, the routing engine must know the shortest routes to all
possible destinations in the routing topology. The routing engine must find the shortest routes
from all available transfer routes to all destinations in a complex routing topology. This
problem is known as the single-source shortest paths problem.
The following figure shows that even in a relatively straightforward routing topology, many
routes can exist from one routing group to any other routing group. The figure shows the
routing group connectors from Figure 5.4 in simplified form, with their default cost values of 1.
191
Routing group connectors with default cost values
In 1959, Professor Edsger Dijkstra solved the single-source shortest paths problem by
developing an algorithm that locates, in a single calculation, the shortest paths from a given
source to all points in a topology.
The routing engine uses the Dijkstra algorithm, as follows:
1. It is assumed that the routing topology representing all the paths from one routing
group to all other routing groups is a spanning tree. This determines that the topology
must include all routing groups and routing group connectors, and that there are no
loops between routing groups. Therefore, paths in the routing topology that allow a
message to return to the source routing group are illegal transfer paths and are not
included in the calculation.
2. Based on Dijkstra's algorithm, the routing engine maintains two sets of routing
groups. The first set includes all groups for which the shortest path from the source
routing group has already been determined. The second set includes all remaining
routing groups. At first, the set of routing groups for which the shortest paths from the
source routing group have already been determined is empty. As long as there are
routing groups remaining that have not been processed, the routing engine performs
Steps 3 through 6, as follows.
192
3. The routing engine sorts the remaining routing groups according to the current
best estimate of their distance (that is, the sum of cost values) from the source
routing group.
4. It then adds the closest routing group to the set of routing groups for which the
shortest paths have been determined.
5. The routing engine then updates the costs of all the routing groups connected to
that routing group (if this improves the best estimate of the shortest path for each of
the remaining routing groups) by including the cost value of the connector between
those routing groups in the distance value.
6. It updates the predecessor for all updated routing groups. The list of
predecessors eventually defines the shortest path from each routing group to the
destination routing group.
The following steps illustrate how the routing engine finds the shortest paths from routing
group A to all other routing groups in the routing topology:
1. The calculation begins at routing group A because in this example the source is
routing group A. The distance value of routing group A to itself is zero. The distance
value of all other routing groups has not been determined.
2. Routing group A is added to the set of routing groups for which the shortest paths
from the source routing group have been determined. Then, the distance value of all
routing groups adjacent to routing group A is updated with the cost values of their
connectors. The predecessor (indicated by the source of the black arrows) for all
these routing groups is then updated. The predecessor is routing group A.
best estimate of their distance from the source routing group. It adds the closest
routing group to the set of routing groups for which the shortest paths have been
determined. Because routing groups B and C have the same distance value, the
routing engine selects one routing group at random. This example assumes that the
routing engine selects routing group B.
4. The routing engine calculates the distance value of all remaining routing groups
adjacent to routing group B, by combining the cost value of the connector between
routing group B and the adjacent routing group with the distance value of routing
group B. It updates the distance value of an adjacent routing group only if the
calculated distance value is smaller than the value that is already assigned to the
routing group, and only then updates the predecessor (indicated by black arrows).
The neighbors of routing group B are routing groups C, D, and E. The current distance
value of routing groups C and D is not defined. Therefore, their distance value is updated
with the cost values of their connectors, plus the distance value of routing group B (1+1).
Then the predecessor (indicated by the source of the black arrows) for all these routing
groups is updated. The predecessor is routing group B.
193
Routing group C is not updated, because the sum of the distance value of routing group
C and the connector cost (1+1) is larger than the current distance value of routing group
C.
best estimate of their distance from the source routing group and adds the closest
routing group to the set of routing groups for which the shortest paths have been
determined. The algorithm now picks routing group C, because this routing group has
the smallest distance value.
6. The routing engine calculates the distance value of all remaining routing groups
adjacent to routing group C, by combining the cost value of the connector between
routing group C and the adjacent routing groups with the distance value of routing
group C. It updates the distance value of an adjacent routing group only if the
calculated distance value is smaller than the value that is already assigned to the
routing group, and only then updates the predecessor (indicated by black arrows).
The remaining routing groups that are neighbors of routing group C are routing groups D
and E (routing groups A and B were already processed).
The current distance value of routing groups D and E is 2. This value is smaller than the
sum of the connector cost and distance value of routing group C (1+2). Therefore, the
distance value and predecessor list of routing groups D and E are not updated.
7. The routing engine sorts the remaining routing groups (routing groups D and E)
according to the current best estimate of their distance from the source routing group
and adds the closest routing group to the set of routing groups for which the shortest
paths have been determined.
Because routing groups D and E have the same distance value, the routing engine
selects one routing group at random. This example assumes that the routing engine
chooses routing group D.
The only remaining neighbor is routing group E, which has a current distance value of 2.
This value is smaller than the sum of the connector cost and distance value of routing
group D (1+2). Therefore, the distance value and predecessor list of routing group E are
not updated.
The last routing group that has not been added to the list of routing groups for which the
shortest paths have been determined is routing group E. There are no remaining
adjacent routing groups. Therefore, the calculation of the shortest path is complete. The
shortest paths from routing group A to any other routing group in the topology have been
determined.
194
Message Transfer Load Balancing

If multiple paths with the same cost value exist, the routing engine selects a transfer path at
random, as outlined in the previous steps. However, the routing engine does not perform load
balancing. As explained earlier, the routing engine caches the message type information that
refers to the shortest path a message can take to its destination. Therefore, all messages of
the same type travel the same path, even if another path with the same cost value exists (for
example, "routing group A > routing group B > routing group E" and "routing group A >
routing group C > routing group E").
Load Balancing between Routing Groups

True load-balancing between routing groups can be achieved only by using one Routing
Group Connector with multiple bridgehead servers.
The following table lists the load-balancing configurations that you can use between routing
groups.
195
Possible configurations between routing groups
Possible configuration Comments
A single routing group connector with With these types of connectors, the routing
multiple source or multiple destination engine returns the connector GUID in the
bridgehead servers, or both. next hop information for the advanced
queuing engine. The advanced queuing
engine then randomly selects the
bridgehead server that must be used,
thereby load-balancing the message
transfer across all bridgehead servers.
If a message reaches a source bridgehead

server of a routing group connector with
multiple source bridgehead servers, the
message is not rerouted to any other
source bridgehead server. After the
message reaches the routing group
connector, message transfer to the
destination routing group is direct.
Therefore, users who have mailboxes on
the bridgehead server always use the local
server for message transfer to the
destination routing group.
Note:
It is best to specify multiple source
and destination bridgeheads for a
single routing group connector
between two routing groups. This
practice improves load-balancing
and redundancy.
196
Possible configuration Comments
Multiple connectors with the same address In this type of configuration, true load
space (or connected routing group), same balancing is not achieved. Load balancing
weight (cost), and each with a single is performed only to the extent of selecting
source and destination bridgehead server a connector initially for a given message
type. The routing engine determines the
message type one time, caches this
information, and then routes all messages
of the same type over the same connector.
The second connector is used only if the
first connector fails. However, a second
server might select the second connector
and in this way balance the load to some
extent.
Note:
It is not a good practice to use
multiple connector instances
between routing groups for load
balancing, because true load
balancing cannot be achieved.
Multiple connectors with the same address If you want to configure connectors to fail
space (or connected routing group), over automatically, you can create two
different weights (cost), and each with a separate connectors on different
single source and destination bridgehead bridgehead servers, each with a different
server cost. Link state for a connector is
determined by its local bridgehead server. If
the bridgehead server on the preferred
connector with the lowest cost is
unavailable, the connector is considered to
be unavailable and the routing automatically
chooses the second connector. When the
bridgehead server that is hosting the
connector with the lowest cost becomes
available, Exchange servers then begin
using it again.
197
Load Balancing between Connectors and

External Systems
Depending on the scenario, there are a few ways to achieve load balancing across SMTP
connectors.
• If you want to load-balance outbound requests across multiple servers in the

sending organization, configure multiple source bridgeheads.
• If you want to load-balance traffic across multiple destination servers, either have
the destination administrator configure DNS correctly (using a suitable configuration
of MX and A records), or specify multiple smart host addresses on the connector.
Or, if you want to ensure failover resiliency, create multiple SMTP connectors scoped with the
same address space, different costs, and different source bridgeheads. If the bridgehead
server on the preferred connector with the lowest cost in unavailable, the connector is
considered unavailable and routing automatically chooses the second connector. If you use
two connectors with the same cost, Exchange servers will randomly select which bridgehead
server and connector that they will use. Then if this bridgehead server becomes unavailable,
they will fail over to the second connector. However, once the first bridgehead server
becomes available, the servers will not fail back to this server because the route has the
same cost as the server that they are already using.
The connector configuration in the following figure, for example, is not load-balanced for
failover configuration because the address spaces do not match. Messages sent to external
users in a .NET domain always travel over the SMTP connector with the .NET address space.
This is because the routing engine chooses the most detailed address before evaluating
costs.
A connector configuration that does not provide load balancing or fault tolerance
198
Note:
If restrictions exist on the connector with the *.NET address space, and the
restrictions prevent certain messages from crossing this connector (for example,
because the sender is denied message transfer over this connector), the routing
engine returns the message to the sender with an NDR. The routing engine does not
fall back to the second connector for those messages. The most detailed address
space determines which connectors can be used to transfer a message. Connectors
with less detailed address spaces are excluded from the route calculation.
Message Rerouting Based on Link State

Information
If a connector cannot transfer messages, the advanced queuing engine notifies the routing
engine of a link failure. This might cause the routing engine to mark the connector as down, in
which case all queued messages are rerouted.
The routing engine considers a connector as down if one of the following conditions is true:
• The routing engine cannot establish a connection to at least one of the

connector's source bridgehead servers, and there is no TCP/IP connection to
port 691 between the routing group master and the source bridgehead servers.
Unavailable source bridgehead servers are marked as VS_NOT_STARTED in the
link state table.
• None of the source bridgehead servers can transfer the message to a destination
bridgehead server successfully. Source bridgehead servers that cannot transfer
messages to the destination are marked as CONN_NOT_AVAIL.
Note:
If you use X.400 connectors, and the connector cannot transfer messages, the
Exchange MTA informs the routing engine that a link failure occurred. The state of the
source bridgehead server is then CONN_NOT_AVAIL. X.400 connectors can have
only one source bridgehead server.
Message Rerouting
To guarantee efficient message transfer, the routing engine informs the advanced queuing
engine and Exchange MTA immediately of any link state changes. To avoid sending
messages along broken paths, all queued messages must be routed again. This process is
named rerouting. In rerouting, the advanced queuing engine discards all cached next hop
information, because this information is no longer valid. Each message that is currently
waiting to be transferred is passed to the routing engine again, to recalculate the next hop.
This can be a resource-intensive task.
199
The following figure shows a rerouting example in which the bridgehead server in routing
group E is down. No messages can reach this routing group currently. When the routing
engine recalculates the shortest paths for messages to recipients in routing group E, it
discovers that no path is available. Connectors marked as down are excluded from the
routing process. Therefore, routing group E is currently isolated.
Broken routing group connectors
Because no valid path exists, the routing engine cannot determine a valid next hop for
messages that are waiting to be transferred to routing group E. The routing engine informs
the advanced queuing engine, in the next hop type information, that the next hop is currently
unreachable. The advanced queuing engine must retain the message until at least one
transfer path becomes available, or until the message expires and is returned to the sender
with an NDR.
Note:
If only one connector to a routing group exists, and there are no alternative paths, the
link state is always marked as available to reduce the number of link state changes in
the routing topology. Exchange Server 2003 queues the messages and sends them
when the route becomes available again.
200
Rerouting and Address Spaces

As with load-balancing, Exchange Server 2003 reroutes messages only over connectors that
have the same address space. For example, you can create two separate connectors on
different bridgehead servers, each with the same address space but different costs. If the
preferred connector becomes unavailable, the routing engine automatically selects the
second connector, until the primary connector becomes available again.
Note:
The routing engine does not reroute messages from a connector with a specific
address space to a connector with a less specific address space, because the routing
engine considers this a different destination. The messages remain on the source
bridgehead server until the connector with the detailed address space becomes
available.
If there are restrictions on the connector with the .NET address space, and the restrictions
prevent certain messages from crossing this connector, for example because the sender is
denied message transfer over this connector, the routing engine returns the message to the
sender with an NDR. The routing engine does not fall back to the second connector for those
messages. The most detailed address space determines which connectors can be used to
transfer a message. Connectors with less detailed address space are excluded from the route
calculation.
Connector Recovery
The routing engine determines that a connector is available again in one of the following
ways:
• VS_NOT_STARTED The routing group master establishes a connection to TCP

port 691 on the source bridgehead server. The source bridgehead server is marked
as CONN_AVAIL, and because at least one source bridgehead server is available for
the connector, the connector state switches to STATE UP.
• CONN_NOT_AVAIL For unavailable connectors, the source bridgehead servers

continue to retry connection at 60-second intervals, even if no messages are waiting
for transfer. When a connection is established, the advanced queuing engine or the
Exchange MTA reports to the routing engine an outbound connection success from
the source bridgehead server. The routing engine then switches the source
bridgehead server to CONN_AVAIL and the connector to STATE UP.
Rerouting and Activation Schedules

All connector types permit you to configure a schedule for the connector so that you can
transfer e-mail messages at specific times. Connectors can be configured to be always
201
active, to become active only at specified times, or to be never active, in which case the
connector does not transfer messages until the connector schedule is changed again. You
can also configure a connector as remote initiated, which means that the connector does not
initiate a connection itself. Instead, it waits for a remote server to connect and trigger the
message transfer.
The connector schedule affects the message transfer only. It does not affect message
routing. The routing engine considers connectors with any schedule type as available if they
are STATE UP. Therefore, messages might even be routed to connectors for which the
activation schedule is set to never. Link state changes and rerouting do not occur for these
connectors. Messages wait in the connector's queue until the activation schedule is changed.
The same is true for remote initiated connectors. Messages are not rerouted while they are
waiting for their retrieval.
Tip:
If you want to avoid message routing to a connector, set its maximum message size
to 1 Kilobyte (KB).
Link State Propagation

To guarantee efficient and reliable message routing, Exchange servers must have up-to-date
information in their link state table. This information must accurately reflect the state of all
bridgehead servers and messaging connectors. To propagate link state information to all
servers in an Exchange organization, a propagation protocol known as link state algorithm
(LSA) is used.
Propagating link state information among all servers has the following advantages:
• Each Exchange server can select the optimum message route at the source
instead of sending messages along a route on which a connector is unavailable.
• Messages no longer bounce back and forth between servers, because each
Exchange server has current information about whether alternate or redundant routes
are available.
• Message looping no longer occurs.
Link State Algorithm

The propagation of link state information differs within and between routing groups. Within
routing groups, reliable TCP/IP connectivity is assumed, and servers communicate with each
other over direct TCP/IP connections. Across routing groups, however, direct TCP/IP
connections might not be possible. Across routing groups, Exchange Server 2003 propagates
link state information through SMTP or X.400.
202
Exchange Server 2003 propagates link state information as follows:
• Intra-routing group LSA Within a routing group, the routing group master
tracks link state information and propagates it to the remaining servers in the routing
group. The remaining servers are also named member nodes or routing group
members. When a member node is started and has initialized its routing table with
information from Active Directory, it establishes a TCP/IP connection to port 691. It
then authenticates with the routing group master and obtains most recent information
about the state of all links in the routing topology. All intra-routing group connections
require two-way authentication. The connection remains so that master and
subordinate node can communicate with each other whenever link state changes
occur.
Master and subordinate in a routing group
Within a routing group, Exchange Server 2003 updates link state information as follows:
a. When the advanced queuing engine or the Exchange MTA determines a

problem with a bridgehead or routing group connector, it informs the local
routing engine, as explained in "Message Rerouting Based on Link State
Information" in Exchange Server 2003 Message Routing.
b. The local routing engine, acting as a caching proxy between the routing
group master and the advanced queuing engine or Exchange MTA, forwards
the link state information to the routing group master over the link state
connection to TCP port 691.
c. When the routing group master is informed of an update, it overwrites the

link state table with the new information. Based on this new information, the
routing group master creates a new MD5 hash, inserts it into the link state
table, and then propagates the new information to all servers in the routing
group. Again, communication takes place over TCP port 691.
Note:
An MD5 hash is a cryptographic block of data derived from a message by
using a hashing algorithm that generates a 128-bit hash from a list of blocks
203
with 512 bits. The same message always produces the same hash value
when the message is passed through the same hashing algorithm.
Messages that differ by even one character can produce very different hash
values.
d. The routing group master sends the whole link state table (that is, the
OrgInfo packet) to each routing group member. Each routing group member
compares the MD5 hash of the new OrgInfo packet with the MD5 hash in its
own link state table and determines if the local server has the most up-to-
date information.
e. If the MD5 values are different, the routing group member processes the
OrgInfo packet. After replacing the link state table in memory, the routing
group member sends a short reply to the routing group master, now also
referencing the new MD5 hash value.
f. The routing group master processes this information, discovers that the
routing group member is updated, and sends a short acknowledgment to the
routing group member.
g. Every five minutes thereafter, the routing group member polls the master
to query for up-to-date routing information. Master and member node
compare their MD5 hash values to determine if changes occurred.
Note:
All servers within a routing group must communicate with the routing group
master through a reliable TCP/IP connection.
• Inter-routing group LSA Link state information is communicated indirectly

between routing groups, using bridgehead servers and routing group connectors. To
send link state information to another routing group, the routing group master
communicates the link state information in the form of an Orginfo packet, which it
sends to the routing group's bridgehead server over TCP port 691. The bridgehead
server then forwards this information to all the bridgehead servers in other routing
groups to which it connects, using the various routing group connectors it hosts.
If the communication between routing groups is SMTP-based (that is, Routing Group
Connector or SMTP connector), link state information is exchanged before regular
message transfer by using the extended SMTP command, X-LINK2STATE, as follows:
a. The source bridgehead server establishes a TCP/IP connection to the

destination bridgehead over TCP port 25.
b. The bridgehead servers authenticate each other using the X-EXPS GSS
API command.
c. After connecting and authenticating, link state communication begins

using the X-LINK2STATE command.
204
d. First, the bridgehead servers compare their MD5 hashes to detect any
changes to link state information. Then the local bridgehead server uses the
DIGEST_QUERY verb to request the MD5 hash from the remote bridgehead
server. The DIGEST_QUERY verb contains the GUID of the Exchange
organization and the MD5 hash of the local bridgehead server.
e. The remote bridgehead server now compares its MD5 hash to the MD5
hash received through the DIGEST_QUERY verb. If the hashes are the
same, the remote bridgehead server sends a DONE_RESPONSE verb to
indicate that the link state table does not require updating. Otherwise, the
remote bridgehead server sends its entire OrgInfo packet.
f. After receiving the OrgInfo packet, the remote and local bridgehead
servers reverse roles and the local bridgehead server sends its own OrgInfo
packet to the remote bridgehead server. Both bridgehead servers transfer the
received OrgInfo packet to their routing group masters. The routing group
master determines whether to update the link state table with the information
from the OrgInfo packet. A higher version number indicates a more recent
OrgInfo packet.
Note:
Routing group masters never accept information about their local routing
group from a routing group master in a remote routing group.
g. After the exchange of OrgInfo packets, the remote bridgehead server

starts transferring e-mail messages, or issues a Quit command to end the
SMTP connection.
For details about SMTP communication between servers running Exchange Server 2003,
see SMTP Transport Architecture.
Note:
When you link routing groups by means of an X.400 connector, link state information
is exchanged between the MTAs as part of typical message transmission. A binary
object, called the Orginfo packet, is sent in a system message to the receiving MTA
before interpersonal messages are transferred. The receiving MTA then transfers the
Orginfo packet to the local routing engine, which communicates the transfer to the
routing group master.
An LSA Example
The following figure illustrates how the link state algorithm works in an Exchange organization
that contains multiple routing groups. The figure illustrates an environment that contains an
unavailable bridgehead server in routing group E. Also, the bridgehead servers in the other
routing groups have not received the information that there is a routing problem.
205
An organization with an unavailable bridgehead server, before link state changes
Exchange Server 2003 discovers the routing problem in the following way:
1. A user in routing group A sends a message to a recipient in routing group E.
2. The routing engine chooses the path shown in Figure 5.9. Therefore, the
message is transferred to the bridgehead server in routing group B.
3. The bridgehead server in routing group B tries a direct transfer to the bridgehead
server in routing group E. Because the remote bridgehead is unavailable, the try fails.
After three consecutive connection tries, the routing group connector's local
bridgehead server is marked as CONN_NOT_AVAIL. Because there are no more
bridgeheads in the connector configuration, the connector is marked as STATE
DOWN.
206
First connector down
4. The bridgehead server in routing group B connects to its routing group master
through TCP port 691 and transmits the new link state information. The master
incorporates the information into the link state table and notifies all servers in the
routing group about the change.
5. The link state change causes a rerouting event in routing group B.

Exchange Server 2003 can select from two paths with the same cost values. In this
example, the message is sent to routing group C, because the routing engine
randomly chooses this transfer path.
6. Before the actual message is transferred, the bridgehead servers in routing

group B and routing group C compare their MD5 hashes. Because the MD5 hashes
do not match, the servers exchange link state information. The bridgehead server in
routing group B informs its remaining adjacent remote bridgehead servers (routing
groups A, C, and D) about the link state changes.
7. The bridgehead server in routing group C connects to its routing group master
through TCP port 691 and transmits new link state information. The routing group
master incorporates the information in the link state table and notifies all servers in
the routing group about the change. All servers in routing group B and C now know
that the routing group connector between routing group B and routing group E is
unavailable.
207
8. The bridgehead server in routing group C tries a direct transfer to the bridgehead
server in routing group E. Because the remote bridgehead is unavailable, the
connection try fails. After three connection tries, the connector is marked as STATE
DOWN.
Second connector down
9. The bridgehead server in routing group C connects to its routing group master
master incorporates the information in the link state table and notifies all other
servers in the routing group about the change.
10. The link state change causes a rerouting event in routing group C. The message
is sent now to routing group D, because the routing engine still sees an available
transfer path from routing group D to routing group E. The bridgehead server in
routing group C informs its remaining adjacent remote bridgehead servers (routing
groups A, B and D) about the link state changes.
11. The message is transferred to routing group D, but before the actual message
transfer, the bridgehead servers in routing group B and C compare their MD5 hashes
and exchange link state information.
12. The bridgehead server in routing group D connects to its routing group master
208
master incorporates the information into the link state table and notifies all servers in
the routing group about the change. All servers in routing group D now know that the
routing group connectors between routing groups B and E and routing groups C
and E are unavailable.
13. The bridgehead server in routing group D tries a direct transfer to the bridgehead
server in routing group E, but because the remote bridgehead is unavailable, the
connection try fails. After three connection tries, the connector is marked as STATE
DOWN.
Third connector down
14. The bridgehead server in routing group D connects to its routing group master
through TCP port 691 and transmits new link state information. The master
incorporates the information into the link state table and notifies all servers in the
routing group about the change.
15. The link state change causes a rerouting event in routing group D. Because no
additional transfer paths are available to routing group E, the message remains in
routing group D, until at least one transfer path is available. The message is
transferred to routing group E as soon as the bridgehead server in routing group E is
available.
209
16. The bridgehead server in routing group D informs its remaining adjacent remote
bridgehead servers (routing groups B and C) about the link state changes. These
routing groups then propagate the link state changes to routing group A.
Link State Changes and Link State Propagation

The link state table contains version information for each routing group in the form of major,
minor, and user version numbers. Major version changes have highest priority, followed by
minor changes, and changes to user version numbers.
Exchange Server 2003 detects link state changes in the following way:
• Major version number Major changes are actual physical changes in the
routing topology. For example, you create a major change when you add a new
connector to the routing group or change a connector configuration. To receive
notification of major changes to its routing group in the routing topology, the routing
group master registers with Active Directory for change notifications using DSAccess.
The configuration domain controller sends these notifications to the Exchange server,
according to the standard Lightweight Directory Access Protocol (LDAP) change
notification process. When a routing group master receives an update to the routing
topology from the configuration domain controller, it sends the updated information to
all member servers in its routing group. It also notifies all bridgehead servers in
remote routing groups, as explained earlier in the section "Link State Algorithm." For
more information about the role of DSAccess and the configuration domain controller
on Exchange 2003, see Exchange Server 2003 and Active Directory.
• Minor version number Minor changes are changes in link state information,
such as a connector changing from a STATE UP to STATE DOWN. Unreliable
network connections, however, could lead to a situation in which connectors are
frequently marked up and down, which causes extra link state updates across the
Exchange organization. A substantial increase in processing overhead may occur,
because of extra route resets and message rerouting. By default, Exchange
Server 2003 mitigates oscillating connectors by delaying link state changes for a
period of ten minutes. During this period, changes that occur are consolidated and
then replicated across the organization in one batch. However, an oscillating
connection can still generate link state traffic if changes occur for extended periods of
time.
You can increase or decrease the update window through the following registry
parameter.
Location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\RESvc\Parameters\
StateChangeDelay
Value
210
Type REG_DWORD
Value Data Interval in seconds between link state

updates. Default is ten minutes. The
maximum is seven days. Setting this
parameter to 0 can be useful when
troubleshooting connection failures.
Failures are then immediately reflected on
connector states.
You can also prevent the routing group master from marking down its connectors by
setting the following Registry key. This can be helpful, especially in hub-and-spoke routed
scenarios, in which each destination can be reached only through a single connector.
Message rerouting cannot occur if alternate connectors are not available.
SuppressStateChanges
Value
Type REG_DWORD
Value Data A value of 0x1 disables link state changes.
• User version number User updates include minimal changes, such as when
the routing group master changes, when services are started or stopped on an
Exchange server, when another server is added to the routing group, or when a
member server loses connectivity to the routing group master.
Changing the Routing Group Master

The first server installed in the routing group is automatically designated as the routing group
master. If this server fails or is taken offline, link state information is no longer propagated in
the routing group. All servers in the routing group continue to operate on the earlier
information. When the routing group master is available again, it reconstructs its link state
information. The routing group master begins with all servers and connectors marked as
unavailable. It then discovers any unavailable servers and updates members within the
routing group.
If you shut down a routing group master for more than a brief time, you should nominate a
different routing group master to avoid inefficient message routing. In Exchange System
Manager, expand the desired routing group and select the Members container. In the details
pane, right-click the server that you want to promote to the routing group master, and then
select Set as Master.
211
Note:
Changing the routing group master represents a major link state change. In a link
state change, link state information is propagated across the organization, and all
Exchange servers must reroute their messages. Therefore, do not change the routing
group master frequently.
Conflicts Between Routing Group Masters

Only one server is recognized in a routing group as the routing group master. This
configuration is enforced by an algorithm in which (N/2) +1 servers in the routing group must
agree and acknowledge the master. N denotes the number of servers in the routing group.
Therefore, the member nodes send link state ATTACH data to the master.
Sometimes, two or more servers mistake the wrong server as the routing group master. For
example, if a routing group master is moved or deleted without choosing another routing
group master, msExchRoutingMasterDN, the attribute in Active Directory that designates
the routing group master, might point to a deleted server, because the attribute is not linked.
This situation can also occur when an old routing group master refuses to detach as master,
or a rogue routing group master continues to send link state ATTACH information to an old
routing group master. In Exchange Server 2003, if msExchRoutingMasterDN points to a
deleted object, the routing group master relinquishes its role as master and initiates a
shutdown of the master role.
Take the following steps to resolve this issue:
• Check for healthy link state propagation in the routing group on port 691. Verify
that a firewall or SMTP filter is not blocking communication.
• Verify that no Exchange service is stopped.
• Check Active Directory for replication latencies, using the Active Directory
Replication Monitor tool (Replmon.exe), which is included in Microsoft Windows
Server 2003.
• Check for network problems and network communication latencies.
• Check for deleted routing group masters or servers that no longer exist. In these
instances, a transport event 958 is logged in the application log of Event Viewer. This
event states that a routing group master no longer exists. Verify this information by
using a directory access tool, such as LDP (ldp.exe) or ADSI Edit (adsiEdit.msc).
These applications are included in the Windows Server 2003 support tools.
212
Backward Compatibility with Exchange

Server 5.5
Exchange Server 5.5 relies on Gateway Address Routing Table (GWART) to select routes in
an Exchange organization. This method uses a distance vector routing algorithm, which is
susceptible to routing loops in certain situations. Exchange Server 2003, however, uses a link
state table that is stored in memory, together with Dijkstra's shortest path algorithm, to select
routes. However, for backward compatibility, Exchange 2003 must generate a GWART, so
that Exchange 5.5 servers can use Exchange 2003 connectors. Also, the routing engine must
incorporate existing Exchange 5.5 connectors in the link state table, so that
Exchange Server 2003 servers can use these transfer paths.
Generating the GWART

The Exchange MTA generates the GWART. The Exchange MTA communicates with the
routing engine through the routing interface wrapper, MTARoute.dll, to obtain routing
information. It then writes this information to the gatewayRoutingTree attribute of an object
named legacy GWART, which resides in the administrative group of the Exchange server.
The MTA also updates the GWARTLastModified attribute to indicate the most recent
changes. The Site Replication Service (SRS) replicates the GWART object to the
Exchange 5.5 directory. After this, Exchange 5.5 servers can include Exchange Server 2003
connectors in their routing decisions.
Routing Issues in Mixed Mode

Site Replication Service also replicates Exchange Server 5.5 connector information to
Active Directory. Therefore, servers running Exchange Server 2003 can route messages
across Exchange Server 5.5 connectors. This allows Exchange Server 2003 users to send
messages over any existing connectors, such as connectors not available in Exchange
Server 2003. This includes connectors such as Connector to Microsoft Mail for PC Networks.
The functionality of routing groups in a mixed-mode environment, in which some servers are
running Exchange Server 2003 or Exchange 2000 Server, while other servers are running
Exchange Server 5.5, is limited in the following ways:
• Routing groups cannot span multiple administrative groups. This is because the
routing topology in Exchange Server 5.5 is defined by sites. Sites in Exchange
Server 5.5 provide the functionality of both the administrative group and the routing
group in Exchange Server 2003. This difference in routing topology limits the
functionality of routing groups in a mixed-mode environment.
• You cannot move servers between routing groups that exist in different
administrative groups.
213
• Exchange Server 5.5 connectors with a local scope are available to all
Exchange 2003 users in the organization, because this connector scope has no
counterpart in Exchange Server 2003. In Exchange Server 5.5, you can specify
connector availability at three different levels: organization, site, and server location.
In Exchange Server 2003, only the organization and routing group (site) scopes are
available.
Topology Updates
Because Exchange Server 5.5 servers do not use a link state table, routing groups with a
routing group master running Exchange Server 5.5 (that is, sites without a server running
Exchange Server 2003) do not send topology updates. To address this issue, routing group
masters periodically obtain the routing group topology for all Exchange Server 5.5-controlled
routing groups from Active Directory and then replicate this information across the
Exchange Server 2003 routing topology.
You can configure the following registry key on a routing group master to determine when the
routing engine reads topology information from Active Directory.
ReloadOsInterval
Value
Type REG_DWORD
Value Data Interval in seconds between reloading of

topology information from Active Directory.
Broken Link State Propagation

Servers running Exchange 2003 do not expect servers running Exchange 5.5 to exchange
link state information with them. However, when a bridgehead server running Exchange 5.5 in
an Exchange routing group is replaced with a server running Exchange 2003 and is
designated as a bridgehead server, the routing group begins to participate in the propagation
of link state information. It no longer has a major version number of zero. A major version
number of zero indicates a server that does not participate in link state information or does
not exchange link state information. All servers running Exchange 5.5 have a version number
of zero, because they do not exchange link state information.
When a routing group propagates link state information, its major version number increases.
Bridgehead servers in other routing groups expect to receive link state changes from this
routing group. However, a problem occurs if you revert the bridgehead server to Exchange
Server 5.5, because the bridgehead server then has no link state table. Other servers still
214
expect the bridgehead server running Exchange Server 5.5, formerly the bridgehead server
running Exchange Server 2003, to participate in link state propagation. Therefore, other
servers wait for this server to give them updated link state information. When this occurs, this
routing group becomes isolated and does not participate in dynamic link state updates in the
organization.
The following figure illustrates a situation in which this isolated routing group can be
problematic. Specifically, because the Exchange 5.5 bridgehead server in the Exchange 5.5
routing group was formerly and Exchange 2000 or Exchange 2003 bridgehead server, the
other servers expect it to participate in link state propagation. In Figure 5.13, the Exchange
Server 5.5 Internet Mail Connector and Exchange Server 2003 SMTP connector both use a
single smart host to route mail to the Internet. The smart host becomes unavailable.
Therefore, the bridgehead server running Exchange Server 2003 marks the route through its
SMTP connector as unavailable. However, because the bridgehead server expects the server
running Exchange 5.5 to send link state information about its routing groups and connectors,
it assumes that the route through Internet Mail Connector is available and attempts to deliver
messages through this route. After one failure, the server running Exchange 2003 detects a
possible loop and does not attempt delivery through this route.
Servers running Exchange 5.5 and Exchange 2003 connecting to a smart host
Link state propagation can also be broken if a firewall that is blocking link state propagation is
added to the system. For example, ports 25 and 691 are required within a routing group and
port 25 is required between routing groups. Also, the Extended Simple Mail Transfer Protocol
(ESMTP) command X-LINK2STATE must not be blocked by a firewall.
To resolve this problem, the following solutions are available:
• Upgrade the Exchange 5.5 bridgehead server to an Exchange 2000 or

Exchange 2003 server, or use another Exchange 2000 or Exchange 2003 server to
send link state information for this routing group again. Either of these options
provides the preferred and simplest resolution.
215
• To reset non-connected routing groups to link state major version number 0, shut
down all Exchange servers in your organization simultaneously, and then restart all
Exchange servers.
• Configure the firewall so that link state propagation is not prevented.
For more information about isolated or disjointed routing groups and the major version
numbers, see Microsoft Knowledge Base article 842026, "Routing status information is not
propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003."
SMTP Transport Architecture

The transport subsystem of Microsoft Exchange Server 2003 is a collection of Component
Object Model (COM)-based engines that integrate seamlessly with the Simple Mail Transfer
Protocol (SMTP) service of Microsoft Windows 2000 Server and Microsoft Windows
Server 2003. Because Exchange Server 2003 must extend the Windows SMTP service with
its own components, you can run the Exchange Server 2003 Setup program only on a
computer running Windows Server 2003 that has the SMTP service installed. It is important
to understand that Exchange components, such as the advanced queuing engine,
categorizer, and routing engine, do not only extend the SMTP service, but also replace SMTP
components with Exchange-specific components. The extended version of the SMTP service
supports:
• Extended SMTP commands for efficient communication between Exchange

servers
• Integration with Microsoft Active Directory directory service for message

categorization and routing
• Integration with the Exchange store for local delivery
• Message tracking for analyzing message paths in your Exchange organization
• SMTP service design The SMTP service runs in the Inetinfo process and when
extended through Exchange event sinks, processes all inbound and outbound
messages. When messages pass through the transport subsystem, SMTP makes
heavy use of Internet Information Services (IIS) resources. You must understand the
SMTP service design to understand how the entire Exchange 2003 transport
subsystem works.
• Advanced queuing engine The advanced queuing engine is a core

component in the SMTP transport subsystem and the main dispatcher of transport
events. You must understand the tasks of the advanced queuing engine to
understand the interaction between core SMTP transport components and Exchange
event sink extensions.
216
• Transport components These components process each message after it is

received from a remote host or a messaging client. In Exchange Server 2003, all
messages must pass through the SMTP transport subsystem. This includes
messages sent through MAPI clients, such as Microsoft Office Outlook 2003,
Microsoft Office Outlook Web Access, Distributed Authoring and Versioning (DAV)
protocol, X.400, and any Exchange Development Kit (EDK)-based connectors, even
if the SMTP protocol is not involved, and even if recipients have their mailboxes in
the same mailbox store as the sender. If you stop the SMTP service on a server
running Exchange Server 2003, all message transfer and delivery stops on that
server. You must understand Exchange Server 2003 message handling to
understand how transport event sinks process each message.
• Store drivers Exchange Server 2003 implements an Exchange store driver so

that the SMTP service can obtain outbound messages from the Exchange store and
deliver inbound messages to Exchange recipients. You must understand the store
driver implementation to identify the physical location of messages as they pass
through the transport subsystem.
• Protocol extensions Protocol extensions implement Exchange-specific SMTP

protocol commands, also called extended SMTP verbs. To understand Exchange-
specific SMTP protocol features, you must understand how the protocol extensions
are implemented.
• Logging and message tracking Protocol logging, event logging, and message
tracking are features that you can use to analyze the details of message transfer. You
must understand the implementation of these features, especially in troubleshooting
situations.
This section assumes that you are familiar with the general concept of message handling in
Exchange Server 2003. For more information about message handling, see Message
Routing Architecture. This section also assumes that you are familiar with the concepts of
configuring virtual SMTP servers, SMTP connectors, and routing group connectors. For more
information about these concepts, see the Exchange Server 2003 Transport and Routing
Guide.
SMTP Service Design

The core SMTP protocol engine is implemented in SMTPSvc.dll, which resides in the
\WINDOWS\system32\inetsrv directory. This protocol engine runs as unmanaged code in the
IIS Inetinfo process and handles incoming and outgoing SMTP connections at the session
layer. The following figure illustrates that the SMTP service is located in the Session,
Presentation, and Application layers according to the Open Systems Interconnection (OSI)
model of the International Organization for Standardization (ISO).
217
Inetinfo process and SMTP service in the OSI model
Note:
Unmanaged code refers to code that is executed directly by the operating system,
outside the Microsoft .NET Framework common language runtime (CLR).
Unmanaged code provides its own memory management, type checking, and
security support. Managed code receives these services from the common language
runtime.
Internet Information Services (IIS) Integration

The fact that the SMTP service runs in the Inetinfo process indicates that the Exchange
Server 2003 transport subsystem shares IIS resources with other services that also run in IIS,
such as the Post Office Protocol version 3 (POP3) service, Internet Mail Access Protocol
version 4 (IMAP4) service, and Exchange Routing Engine service (RESvc). Inetinfo.exe is the
core IIS process, and the IIS Admin service controls Inetinfo.exe. This is explained in
Exchange Server 2003 Services Dependencies.
Asynchronous Thread Execution

One of the most important resources that the SMTP service shares with all other services in
the Inetinfo process is Asynchronous Thread Queue (ATQ). This is a pool of threads that IIS
218
uses to handle all incoming network connection requests. A thread is an instance of code
execution within a process. A process consists of a virtual address space, processor context,
and at least one thread. Threads are created by using the CreateThread() method of the
operating system and run within the virtual address space of the calling process (that is, the
IIS Inetinfo process).
In asynchronous processing, each thread runs in the Inetinfo process without waiting for other
threads to finish their processing. In synchronous processing, threads run after each other in
a synchronized way (code execution is blocked at a function call until the function is
complete). To synchronize asynchronous threads (for example, to avoid conflicts because of
concurrent access to a particular resource), the operating system provides synchronization
objects. An example of a synchronization object for a particular resource is an event object for
a Windows socket. The SMTP service uses event objects to receive notifications of incoming
SMTP connections. A Windows socket is an IP address combined with a port number. The
default port to reach the SMTP protocol engine is TCP port 25. Combined with the IP address
of the Exchange server that is running the SMTP service, this port number forms the socket
of the default SMTP virtual server, for example: 192.168.1.100:25.
Note:
Only the default SMTP virtual server exists on an Exchange server. The default
SMTP virtual server accepts incoming connections on TCP port 25 for all IP
addresses of the server. You can change this configuration in Exchange System
Manager, from the General tab, in Default SMTP Virtual Serverproperties.
Handling Incoming SMTP Connections

The Inetinfo process handles incoming SMTP connections as follows:
1. When you start the SMTP service, the Inetinfo process initializes the SMTP
virtual server's socket in TCP/IP to listen for incoming connection requests. To
support multiple concurrent connections through the same virtual server, the socket is
initialized in non-blocking mode for overlapped I/O operations. By default, an SMTP
virtual server can accept almost an unlimited number of incoming network
connections (although the actual physical limit is about 5000).
Note:
In Microsoft Windows Server 2003, the server can handle only about 2,000
concurrent connections. In Windows Server 2003 Service Pack 1, the default is
increased from 2,000 to 5,000 and can be increased even more through a setting
in the metabase.
2. The Inetinfo process creates a synchronization object to inform the operating

system that it is interested in receiving a network event notification for incoming
connections over the socket. ATQ is associated with this synchronization object so
219
that a thread from this thread pool can be notified when the synchronization object
signals an incoming network connection.
3. The TCP/IP transport stack receives an incoming SMTP connection and signals
this event to the Inetinfo process. Now a thread from ATQ can run to read data from
the SMTP socket.
Note:
The Inetinfo process can create additional threads in ATQ to ensure a sufficient
number of threads available to listen for incoming connection requests. To tune
IIS performance, you can specify the maximum number of threads that can be
created in the system through the following registry parameter.
Set\Services\InetInfo\Parameters
Value PoolThreadLimit
Type REG_DWORD
Value Data 0 - 4,294,967,295 (unlimited)
Description PoolThreadLimit is a hard limit that includes

all IIS pool threads.
4. The IIS thread runs the code in SMTPSvc.dll and responds to the incoming client
request with a server greeting, named an SMTP banner, such as: 220
server01.TailspinToys.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0
ready at Sun, 21 Mar 2004 23:48:47 +0100.
5. The SMTP conversation progresses as the remote SMTP host transfers the
message. Each time an SMTP command is received, a thread from ATQ runs the
SMTP protocol code in SMTPSvc.dll and triggers events in the SMTP service that
cause code in other DLLs to run. For example, the NTFS store driver writes the
message in the form of a file into the virtual SMTP server's \Queue folder on the file
system.
6. After the current SMTP command is processed, the Inetinfo process places the
thread that was used to perform the SMTP processing back into ATQ to listen for new
incoming commands or new connection requests. IIS reuses existing threads to avoid
the overhead of creating a new thread each time a new command or connection
request is received.
7. The remote host issues a Quit command, and the SMTP service releases the
connection.
220
Note:
The time to live (TTL) of inactive threads in ATQ is 24 hours. The Inetinfo process
has at least two threads in ATQ at any one time to respond to incoming
connection requests.
Limiting the Number of SMTP Threads

By default, the SMTP service can use up to 90 percent of the available threads in ATQ.
Because this thread pool is shared with other IIS services that might also run on the same
server, such as File Transfer Protocol (FTP), POP3, RESvc, and IMAP4 services, a high
SMTP load can lead to a performance bottleneck in the Inetinfo process. This can cause the
FTP, POP3, RESvc, or IMAP4 service to fail.
To avoid this situation, you can reserve an adequate number of threads for other IIS services
by limiting the percentage of threads that the SMTP service can use. This is accomplished
using the following registry parameter.
Location HKEY_LOCAL_MACHINE\System\CurrentControl
Set\Services\SMTPSVC\Queuing
Value MaxPercentPoolThreads
Type REG_DWORD
Value Data The default is 0x5A (90%)
Description Limits the percentage of ATQ threads that

the SMTP service can use. The
recommended setting is:
MaxPercentPoolThreads = 90/(2*Number of
SMTP virtual server instances)
You can also increase the overall number of threads in the Inetinfo process using the
following registry parameter, if sufficient memory is available for the additional threads.
Value AdditionalPoolThreadsPerProc
Type REG_DWORD
Value Data The default is 0x5A (90%)

221
Description Determines additional pool threads per

processor that the Inetinfo process creates
when the SMTP service is started. The
recommended setting is:
AdditionalPoolThreadsPerProc =
((9/(MaxPercentPoolThreads/100))–4)/2
Note:
If the
AdditionalPoolThreadsPerProcvalu
e is greater than 200, you must
increase the value of the
PoolThreadLimit parameter under
HKEY_LOCAL_MACHINE\
System\CurrentControlSet\Servic
es\InetInfo\Parameters\. Set the
PoolThreadLimit to at least the
same value as
AdditionalPoolThreadsPerProc.
Component Object Model-Based SMTP

Extensions
The SMTP protocol supports sending multiple messages during a single session. Delivery or
relay for one message can proceed while the next message is transmitted. The SMTP "end of
mail data" indicator (that is, a carriage return line feed followed by a period, followed by
another carriage return line feed) or the final BDAT chunk of each individual message informs
the receiving SMTP service to process the recipients and data of that particular message.
This processing is referred to as transport processing, because it delivers the message to the
local Exchange store or forwards it to the recipient's home server if the recipient's mailbox
does not reside on the local server. The SMTP service can also relay messages to external
recipients. For example, message relaying is performed when Exchange users who are
working with Internet clients send messages to external recipients.
After a message is received through SMTP, it is passed to the advanced queuing engine
(Phatq.dll). The thread that the SMTP service uses to pass the message to the advanced
queuing engine is then returned to ATQ. The advanced queuing engine uses its own thread
pool to process queued messages. This thread pool is separate from the thread pool used to
handle SMTP protocol operations. You can read more about the advanced queuing engine in
The Advanced Queuing Engine.
222
Events in the SMTP Transport Subsystem

When threads run the protocol code in Smtpsvc.dll or transport code in Phatq.dll, they trigger
events that cause code in other DLLs to run. This event architecture is based entirely on
COM. SMTP uses the Microsoft Server Extension Object COM Library (Seo.dll) to trigger
SMTP events and uses COM activation to instantiate the event sinks that are registered for
each particular event. SMTP events can indicate the transmission or arrival of an SMTP
protocol command or the submission of a message into the SMTP transport subsystem,
among other things. Event sinks, such as SMTP protocol extensions, categorizer, and routing
engine, register for specific events in the SMTP service.
The following types of events can occur in the SMTP transport subsystem of Exchange 2003:
• SMTP protocol events These events are specific to SMTP and allow event
sinks to modify the behavior of the SMTP protocol engine by modifying, disabling, or
adding inbound and outbound commands, as well as responses to those commands.
For example, the X-LSA Sink protocol event sink of Exchange Server 2003
implements an additional SMTP command, X-LINK2STATE, to transmit link state
information across routing groups, as explained in Message Routing Architecture.
Protocol event sinks can also be used to modify standard SMTP and ESMTP
commands, such as EHLO, to broaden the capabilities of the SMTP protocol.
Protocol event sinks are covered in SMTP Protocol Extensions.
• SMTP store events These events allow store event sinks (that is, store driver
implementations) to persist the content of messages in file system directories or in
the Exchange store. For example, in the transport subsystem of Exchange
Server 2003, store events are used to perform local delivery to Exchange recipients.
Store drivers are covered in SMTP Service Store Drivers.
• SMTP transport events These events occur when messages arrive at the
server, flow through the core transport subsystem, and are delivered to Exchange
recipients or relayed to other SMTP hosts. In Exchange Server 2003, transport
events are used to perform message categorization and message routing. The
routing engine is covered in Message Routing Architecture. The categorizer event
sinks are covered in SMTP Transport Components.
• SMTP system events These events translate into calls to a sink acting as a
system component. For example, the SMTP Eventlog sink is a system component
that registers for system events to write internal processing information into the
application event log.
223
Event sinks in the SMTP service
Note:
SMTP event sinks enable non-Microsoft vendors to implement custom extensions to
the SMTP transport subsystem, such as mail filters and anti-virus scanners. SMTP
event sinks do not support COM+ applications.
Event Dispatcher and Event Notifications

When an event occurs, a thread in the SMTP service, acting as the event dispatcher, checks
the event registrations (stored as event bindings in the IIS metabase) to determine if any
sinks are associated with the event. The event dispatcher determines all the event sinks that
are registered to run and when to run them. The order depends on the sink's priority, as
specified in the event binding information. Sinks are notified of an event in sequence. Sinks
with the lowest priority run first.
For each sink, the following process occurs:
1. The event dispatcher compares the sink's event registration with the event
conditions. If the conditions are met, the sink is executed.
Note:
Some SMTP events, such as store events, do not have event conditions.
2. If necessary, the event dispatcher creates an instance of the sink using the class
ID (CLSID) of the event sink COM class.
224
Note:
Sinks can be cached to avoid this step on subsequent events.
3. The event dispatcher calls the IUnknown::QueryInterface method of COM to get

the appropriate event notification interface of the event sink. Most sinks use the
Active Template Library (ATL) to implement the sink interface.
4. The event dispatcher runs the sink by calling the appropriate event method on
the sink interface. For transport events, the event dispatcher passes the message in
the form of a MailMsg object to the event sink. This object contains the whole
message, together with the transport envelope fields. The message and the envelope
fields can be modified by the sink.
5. When the sink finishes processing, it returns an event status flag to the event
dispatcher. The event dispatcher checks this flag to determine whether to notify
subsequent sinks. For example, an event sink might instruct the event dispatcher to
skip all remaining sinks to stop all further message processing.
Event sinks use the following return codes to indicate whether to notify subsequent sinks:
• S_OK Other sinks at the same or lower priority are called.
• S_FALSE Other sinks at the same or lower priority are not called.
Note:
SMTP protocol event sinks might also return the value
MAILTRANSPORT_S_PENDING to indicate that the processing will
complete asynchronously by calling the NotifyAsyncCompletion method. A
protocol event sink can call the NotifyAsyncCompletion method to notify the
inbound protocol event dispatcher that asynchronous processing is complete
and to pass the processing result.
6. For transport events, after each sink is notified, or after one sink indicates to skip
the remaining sinks, the status envelope field is examined for the message to
determine the next action. A message might be delivered to the appropriate location,
discarded, or placed in the SMTP virtual server's \Badmail folder on the file system.
Note:
In the SMTP service, the protocol engine and the advanced queuing engine assume
the roles of event dispatchers. The protocol engine dispatches protocol events. The
advanced queuing engine dispatches transport events. Both protocol engine and
advanced queuing engine also dispatch store and system events.
Administrative Interfaces
The primary tool for managing SMTP protocol settings and SMTP virtual servers on a server
running Exchange Server 2003 is Exchange System Manager, specifically the Exchange
225
SMTP snap-in (\Programme\Exchsrvr\bin\SMTPMgr.dll). You can find this snap-in in

Exchange System Manager, under each server object, under Protocols in the SMTP
container. You can control most of the SMTP settings that apply to inbound message transfer
and, to a lesser degree, outbound mail settings. Using Exchange System Manager, you can
also create additional SMTP virtual servers on your Exchange server. Each SMTP virtual
server represents an instance of the SMTP service and is defined by a unique combination of
an IP address and a TCP port number. Each SMTP virtual server triggers its own events and
manages its own set of event sinks. For more information about the configuration of virtual
SMTP servers, see the Exchange Server 2003 Transport and Routing Guide.
Note:
Creating multiple SMTP virtual servers on a server running Exchange Server 2003
does not increase system performance. Each SMTP virtual server is multithreaded
and can handle numerous connections concurrently. For example, the default
maximum number of concurrent outgoing connections per SMTP domain is 100, and
the total maximum number of concurrent outgoing connections is 1,000.
Configuration Settings and Event Bindings

The SMTP transport subsystem of Exchange Server 2003 relies on the following three
repositories for configuration information:
• Active Directory Exchange System Manager stores and retrieves configuration

information mainly from Active Directory. For example, recipient properties and
restrictions, as well as the routing topology of an Exchange organization, including all
routing groups and messaging connectors, are defined in Active Directory. The
components in the SMTP transport subsystem communicate with Active Directory to
obtain this information, as explained in Exchange Server 2003 and Active Directory.
• IIS metabase The core components of the SMTP service that ship with
Windows Server 2003 are not Active Directory-aware. For example, any settings that
you apply to an SMTP virtual server must be transferred from Active Directory to the
IIS metabase. This is the task of the metabase update service. The metabase update
service registers with the configuration domain controller that Exchange Server 2003
uses to receive notification of any changes to the Exchange configuration. This
notification occurs within 15 seconds of the change. As soon as the change is
replicated to the configuration domain controller, IIS metabase update service
replicates the change to the IIS metabase.
• Registry Most configuration settings that you can configure for the SMTP
transport subsystem are stored in Active Directory or IIS metabase. However, several
system parameters that affect the SMTP service, such as MaxPercentPoolThreads or
AdditionalPoolThreadsPerProc, are stored in the registry database under the
following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC.
226
Another important key is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo, which contains
configuration parameters for the Inetinfo process that hosts the SMTP service. Several
important registry parameters have been introduced earlier in this section.
Because all SMTP event sinks are COM components, they must be registered in the
registry under the HKEY_CLASSES_ROOT hive. You can use Regsvr32.exe to manually
register and unregister COM components.
Configuration Information in Active Directory

Exchange System Manager stores the configuration settings for SMTP virtual servers in the
configuration directory partition of Active Directory. Each virtual server is represented by a
separate configuration object. The location of this object matches the hierarchy of
configuration objects shown in Exchange System Manager, and the common name
corresponds to the numeral of the virtual server in the IIS metabase. For example, the default
SMTP virtual server is the first SMTP virtual server in IIS, and so the corresponding common
name (CN) of the default SMTP virtual server's configuration object in Active Directory is 1
(as in CN=1,CN=SMTP,CN=Protocols,CN=SERVER01,CN=Servers,CN=First administrative
Group,CN=Administrative Groups,CN=TailspinToys,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=TailspinToys,DC=com).
The following table lists important configuration information that Exchange Server 2003 stores
for SMTP virtual servers in Active Directory. To learn how to manage SMTP virtual server
settings in Active Directory programmatically, see Setting Message Restriction on an SMTP
Virtual Server Using ADSI.
Important Active Directory attributes for SMTP virtual servers
Active Directory Attribute Description
msExchServerBindings Specifies the Internet Protocol (IP) port

binding for Secure Sockets Layer (SSL)
connections.
msExchAuthenticationFlags Indicates which type of authentication this

SMTP virtual server accepts.
msExchMaxIncomingConnections Specifies the maximum number of inbound

connections allowed for this SMTP virtual
server.
msExchLogType Specifies the log formats that this SMTP

virtual server uses for protocol logging.
msExchAccessSSLFlags Identifies the type of encrypted channel that

this SMTP virtual server supports.
227
msExchServerAutoStart Specifies when to start the virtual server. If

true, starts the virtual server when the
operating system is booted.
msExchNTAuthenticationProviders Specifies a list of Security Support Provider

Interface (SSPI) packages that may be
used to authenticate to this SMTP virtual
server. Exchange Server 2003 supports
Kerberos authentication through Generic
Security Services Application Programming
Interface (GSSAPI), as well as the legacy
Microsoft Windows NT LAN Manager
Authentication Protocol (NTLM).
msExchIncomingConnectionTimeout Specifies the maximum time duration before

idle incoming connections are cancelled.
msExchSmtpMaxOutgoingConnections Specifies the maximum number of

outbound connections from this SMTP
virtual server.
msExchSmtpOutgoingConnectionTimeout Specifies the maximum time duration before

idle outbound connections are cancelled.
msExchSmtpMaxOutgoingConnectionsPer Specifies the maximum number of

Domain outbound connections from this SMTP
virtual server to a particular domain.
msExchSmtpOutgoingPort Specifies the outbound connection port

number that the SMTP virtual server uses
to contact a remote SMTP host.
msExchSmtpOutgoingSecurePort Specifies the outbound connection port

number that the SMTP virtual server uses
to contact a remote SMTP host, if Transport
Layer Security (TLS) is used to protect the
transmission channel.
msExchSmtpMaxHopCount Specifies the maximum number of hops that

the message transported by this SMTP
virtual server can take to reach the final
destination.
msExchSmtpMaxMessageSize Specifies the maximum size allowed for a

message delivered by this SMTP virtual
server.
228
msExchSmtpMaxSessionSize Specifies the maximum amount of data in

Kilobytes that can be transferred in one
SMTP session.
msExchSmtpMaxRecipients Specifies the maximum number of

recipients allowed on a message
transferred by this SMTP virtual server.
msExchSmtpLocalQueueExpirationTimeout Specifies the time at which this SMTP

virtual server must expire a local
undelivered message.
msExchSmtpLocalQueueDelayNotification Specifies the time at which this SMTP

virtual server must generate a delivery
status notification to inform the sender that
a local message did not reach its
destination.
msExchSmtpRemoteQueueExpirationTime Specifies the time at which this SMTP

out virtual server must expire an undelivered
outbound message.
msExchSmtpRemoteQueueDelayNotificatio Specifies the time at which this SMTP

n virtual server must generate a delivery
status notification to inform the sender that
an outbound message did not transfer.
msExchSmtpSmartHost Specifies a smart host route for outbound

messages from this SMTP virtual server.
msExchSmtpSmartHostType Specifies the smart host type.
msExchSmtpMaxOutboundMsgPerDomain Specifies the maximum number of

outbound messages that this SMTP virtual
server can transfer per domain in one
session.
msExchSmtpOutboundSecurityFlag Specifies the authentication that is used

when connecting outbound from this SMTP
virtual server.
msExchSmtpInboundCommandSupportOpt Controls which SMTP commands are

ions supported on inbound connections. By
changing this value, you can disable
features like 8BITMIME, BDAT,
CHUNKING, and PIPELINING.
229
msExchSmtpRelayForAuth Determines whether the message relaying

requires authentication.
msExchSmtpPerformReverseDnsLookup Specifies whether to perform reverse

Domain Name System (DNS) lookups for
delivery.
msExchSmtpDoMasquerade Specifies whether to use a masquerade

domain for Non-delivery reports (NDRs). If
set, use the masquerade domain. NDRs are
then returned to the alternate domain
specified, instead of to the domain from
which the e-mail messages originated.
msExchSmtpBadMailDirectory Specifies location where badmail (e-mail

messages contained in the BadMail folder)
is stored on the file system.
msExchSmtpSendBadmailTo Specifies an address to which to send

badmail.
msExchSmtpFullyQualifiedDomainName Specifies fully qualified domain name

(FQDN) for this SMTP virtual server.
msExchSmtpPickupDirectory Specifies the directory from which mail

messages are obtained.
msExchSmtpQueueDirectory Specifies the directory from which mail

messages are queued.
msExchSmtpRemoteQueueRetries Specifies the first, second, third, and

subsequent retries for remote mail delivery.
msExchSmtpRelayIpList Specifies a list of IP addresses for relay

restriction.
msExchBridgeheadedLocalConnectorsDN Specifies a list of connectors in the SMTP

BL virtual server's routing group for which this
SMTP virtual server is the local bridgehead.
msExchBridgeheadedRemoteConnectorsD Specifies a list of connectors in remote

NBL routing groups for which this SMTP virtual
server is a remote bridgehead.
230
Note:
The metabase update service replicates all these configuration settings into the IIS
metabase.
SMTP Configuration Settings in the Metabase

The IIS metabase is a hierarchical store of configuration and schema information, which is
used to configure IIS resources. The metabase configuration and schema for IIS 4.0 and
IIS 5.0 are stored in a binary file (MetaBase.bin), which is not easy to read or edit. You must
use the MetaEdit tool to view and edit the metabase of IIS 4.0 and IIS 5.0. MetaEdit 2.2 is
available for download at http://go.microsoft.com/fwlink/?LinkId=47942.
In IIS 6.0, Extensible Markup Language (XML)-formatted files, named MetaBase.xml and
MBSchema.xml, replace the earlier binary file. The IIS configuration information is stored in
the MetaBase.xml file, while the metabase schema is stored in the MBSchema.xml file. When
IIS is started, these files are read by the metabase storage layer and then written to the in-
memory metabase through Admin Base Objects (ABO), as shown in the following figure.
The metabase architecture of IIS 6.0
SMTP Configuration Keys

Members of the local Administrators group can view and modify the MetaBase.xml file, which
is a plain text file that is located in the \Windows\System32\Inetsrv folder. Metabase entries
that apply to the SMTP service and its SMTP virtual servers start with IIsSmtp.
The Location property in the configuration entries defines the hierarchy of the configuration
objects. For example, in Location ="/LM/SmtpSvc/1", LM means local machine, SmtpSvc
represents the SMTP service in general, and the numeral (1) represents the default SMTP
virtual server. The enumerator "1" corresponds to the CN attribute of the default SMTP virtual
server object in Active Directory.
231
The following figure illustrates the hierarchy of configuration entries for SMTP virtual servers,
according to the Location property of each IIsSmtp metabase entry.
Hierarchy of SMTP configuration entries in the IIS metabase
Parameters that apply to the SMTP service generally are registered in the metabase in the
SmtpSvc node. You can find this node when you search for the Location ="/LM/SmtpSvc".
The following section is a shortened listing of this key:
<IIsSmtpService Location ="/LM/SmtpSvc"
ConnectionTimeout="600"
DefaultDomain="server01.TailspinToys.com"
DomainRouting=""
EnableReverseDnsLookup="FALSE"
232
FullyQualifiedDomainName="server01.TailspinToys.com"
...
SmtpRemoteProgressiveRetry="15,30,60,240"
SmtpRemoteRetryThreshold="3"
>
<Custom
Name="AuthFlags"
ID="6000"
Value="AuthBasic | AuthAnonymous | AuthNTLM"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="INHERIT"
/>
...
<Custom
Name="UnknownName_61537"
ID="61537"
Value="0"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="NO_ATTRIBUTES"
/>
</IIsSmtpService>
Under the SmtpSvc node, you find the configuration settings for each SMTP virtual server
that you created on the server that is running Exchange Server 2003. SMTP virtual servers
inherit the general settings configured for the SMTP service and can overwrite these settings.
The following is a schematic listing of the configuration section for the default SMTP virtual
server. Note the Location information.
<IIsSmtpServer Location ="/LM/SmtpSvc/1"
... property definitions that apply only to the
particular virtual server ...
>
233
<Custom
... custom property defintion...
/>
</IIsSmtpServer>
Note:
When you compare the parameter names for SMTP virtual servers in the IIS
metabase with the attributes of SMTP virtual servers in Active Directory, you find
close matches. For example, the metabase parameter called PickupDirectory
corresponds to the Active Directory attribute called msExchSmtpPickupDirectory.
Direct Metabase Editing

Because MetaBase.xml is a text file, members of the Administrators group can edit the IIS 6.0
metabase directly using common text tools, such as Notepad. However, this file remains open
and locked when IIS is running. To support direct editing, you must enable the Enable Direct
Metabase Edit feature in IIS Manager. For detailed instructions about how to enable direct
editing of the IIS metabase, see How to Enable the Enable Direct Metabase Edit Feature in
IIS Manager.
Local Domain Registrations

Under each SMTP virtual server node in the metabase, you can find important child nodes,
such as Domain (Location ="/LM/SmtpSvc/1/Domain") and EventManager (Location
="/LM/SmtpSvc/1/EventManager") nodes. The domain node contains domain definitions that
determine the route actions that the SMTP virtual server should perform. For example, the
SMTP service must accept messages for all local SMTP domains, as defined in recipient
policies, but might be required to reject any attempts to relay messages to non-local domains.
The metabase update service replicates the domain information from recipient policies to the
IIS metabase for all SMTP virtual servers.
Note:
The domain definitions also contain entries that refer to Active Directory sites. An
example of such a domain name is 705260ab-46c4-454d-bfdd-
96b9c605364c._msdcs.fabrikam.com. The route action for these entries causes the
SMTP virtual server to place the messages in the \Drop directory from which Active
Directory can retrieve them. Do not change or remove these domain entries to avoid
directory replication issues. Active Directory uses the SMTP service to replicate
directory changes between sites.
234
Event Sink Registrations

The entries under the EventManager node are event registrations. For the SMTP service to
work with event sinks, event sinks must be registered in the IIS metabase, so that the SMTP
service can create and run these sinks when relevant events occur. IIsConfigObjects define
event bindings in the IIS metabase. For example:
<IIsConfigObject Location ="/LM/SmtpSvc/1/EventManager/
EventTypes/{283430C9-1850-11D2-9E03-00C04FA322BA}/
Bindings/{A928AD15-1610-11D2-9E02-00C04FA322BA}/
SinkClass"
>
<Custom
Name="MD_0"
ID="0"
Value="Exchange.Router"
Type="STRING"
UserType="UNKNOWN_UserType"
Attributes="NO_ATTRIBUTES"
/>
</IIsConfigObject>
This binding associates the GUID of a particular event, such as 283430C9-1850-11D2-9E03-

00C04FA322BA, with an event sink, such as the Exchange Router sink. The second GUID
entry in the binding information {A928AD15-1610-11D2-9E02-00C04FA322BA} is the
identifier (ID) of this particular event binding entry. Event binding IDs must be unique in the
metabase, but a particular event can have more than one event sink associated with it, as
indicated in Figure 6.4, earlier in this section.
Event binding parameters are defined under each event sink node in the metabase hierarchy.
The current listing defines a SinkClass value that creates an association between the SMTP
transport OnGetMessageRouter event and the Exchange.Router sink class. Additional
binding entries exist to define the display name for the event sink as Exchange Router, and to
define other parameters, such as the priority of the event sink. The following table lists the
parameters that can be specified for an event binding.
235
Event binding information
Property Description Property Description
ID A GUID that uniquely identifies the binding.

This information is required.
DisplayName An optional user-friendly name for the

binding.
SinkClass The programmatic identifier (ProgID) of the

event sink class.
Enabled A flag that indicates whether the binding is

currently enabled. If this flag is not
specified, the event sink is enabled. This
parameter is optional.
MaxFirings The number of event notifications the sink

can receive before the binding is disabled.
This parameter is optional.
EventBindingProperties A dictionary (or hash) of additional

properties that are defined for the entire
binding. This parameter is optional.
SinkProperties Sink properties are reserved for a particular

sink implementation. When the sink is
notified of an event, the event dispatcher
passes the collection of sink properties to
the event sink. For example, an event sink
that is used to add a disclaimer to a
message might receive the disclaimer text
through a sink property.
236
Property Description Property Description
SourceProperties Source properties are defined by a

particular event dispatcher implementation.
For example, the inbound and outbound
protocol event dispatcher uses a Rule and
Priority property to determine when a sink is
notified of an event. Most transport event
sinks do not use the Rule source properties,
except the OnTransportSubmission event.
All protocol and transport events support
use of the Priority source property.
The following source properties are used for
event bindings for protocol and transport
events:
• Rule A string identifying a

protocol filter for the sink binding.
The dispatcher uses the rule as a
condition or set of conditions that
determine whether the sink is
notified. The rules are SMTP
protocol command rules, such as
EHLO. Rules may include
conditions, such as
EHLO=*.contoso.com. Multiple
rules are separated by semi-colons.
• Priority The sink's notification

priority, compared to other sinks
registered to receive notifications of
the event. The range of values is 0
(highest) to 32767 (lowest). This
property is optional. The default
priority is 24575. Sinks with the
same priority run in an unspecified
order.
Server Extension Objects

GUIDs in event bindings guarantee a unique association between an event type and an event
sink, but these identifiers can be problematic because they are not logically apparent. For
example, if you want to know what event maps to the event sink in the listing in the preceding
237
table, you must search for the GUID 283430C9-1850-11D2-9E03-00C04FA322BA in the

registry under HKEY_CLASSES_ROOT\Component Categories. You can then find out that
this GUID identifies the SMTP Transport OnGetMessageRouter event type. The second
GUID in this example of a binding definition, A928AD15-1610-11D2-9E02-00C04FA322BA, is
the CLSID of the Exchange Router class, implemented in Reapi.dll. The registry key for this
COM component is HKEY_CLASSES_ROOT\CLSID\{A928AD15-1610-11d2-9E02-
00C04FA322BA}. However, this CLSID is only used to create a unique ID for the event
binding in the metabase. What matters is the SinkClass value that defines the association
between the event type and the event sink class.
Fortunately, you do not have to work with GUIDs to manage event sink bindings. You can use
server extension objects implemented in Seo.dll instead. Microsoft has developed a script
that demonstrates using server extension objects to manage event bindings for the SMTP
service. This script is called SMTPReg.vbs, and you can find it at smtpreg.vbs Event
Management Script. For example, you can use SMTPReg.vbs with the following command to
write all SMTP event bindings from the IIS metabase into a file called Event_Bindings.txt:
cscript smtpreg.vbs /enum > Event_Bindings.txt. The following listing shows the output
for the Exchange Router binding entry:
---------
| Binding |
---------
Event: SMTP Transport OnGetMessageRouter
ID: {A928AD15-1610-11D2-9E02-00C04FA322BA}
Name: Exchange Router
SinkClass: Exchange.Router
Enabled: True
SourceProperties: {
priority = 8192
How to Enable the Enable Direct Metabase

Edit Feature in IIS Manager
This procedure explains how to enable the Enable Direct Metabase Edit feature in IIS
Manager. You must perform this procedure in order to edit the MetaBase.xml file in the IIS 6.0
metabase directly when IIS is running; otherwise the file remains open and locked when IIS is
running.
238
Before You Begin

Because the Active Directory-to-IIS metabase update is a one-way replication, it is a good

idea to be careful when you modify settings in the IIS metabase directly. The metabase
update service might overwrite any changed values for the SMTP virtual server during the
next update cycle. It is recommended that you use Exchange System Manager to configure
the SMTP service on an Exchange 2003 server and modify only those parameters that are
not available in Exchange System Manager, such as the ConnectResponse setting.
Caution:
If you edit the metabase incorrectly, you could cause serious problems that could
require you to reinstall your Exchange server. Microsoft cannot guarantee that you
can solve problems that result from editing the IIS metabase incorrectly. You edit the
metabase at your own risk. Make sure you have a valid backup copy of the metabase
files before you apply any changes.
Procedure
To enable the Enable Direct Metabase Edit Feature in IIS Manager
1. In IIS Manager, right-click the server object, and then click Properties.
2. Select the Enable Direct Metabase Edit check box.
3. If you want to change parameters that are not available in Exchange System
Manager, you can edit the metabase settings directly. For example, you can change
the SMTP banner of your SMTP server by adding a value for the ConnectResponse
property to the default SMTP virtual server's configuration object
(<IIsSmtpServerLocation ="/LM/SmtpSvc/1">) to prevent disclosing Exchange-
specific version information in SMTP communications, as follows:
<IIsSmtpServer Location ="/LM/SmtpSvc/1"
AdminACL="4963... ... ...a472"
ClusterEnabled="FALSE"
ConnectionTimeout="600"
...
4. If you find Notepad inconvenient, you can use Active Directory Service Interfaces
(ADSI) instead to modify metabase settings. The following code block performs the
same change to the SMTP banner. The following figure illustrates the modified SMTP
banner.
239
' Get the configuration object for the default SMTP virtual server
' Configure the ConnectResponse setting
' Write the changed parameter into the metabase
5. For more information about how to access IIS metabase settings using ADSI, see
Using ADSI to Configure IIS in the Microsoft Platform SDK.
Note:
You must restart the IIS Admin service and all its dependent services, including
the SMTP service, to save the changes. The SMTP service is designed to obtain
changes to the system configuration automatically, without requiring a restart. But
some modifications, such as changing the SMTP banner, might require a restart.
Replacing Exchange version information in the SMTP banner

240
The Advanced Queuing Engine

The advanced queuing engine is a key component in Exchange 2003 message handling,
because all messages must pass through this engine, even when sender and recipient are
located on the same server running Exchange Server 2003. This enables Exchange
Server 2003 transport components to process every message. No e-mail message can
bypass the transport subsystem.
Note:
The base SMTP service of Windows Server 2003 uses an advanced queuing engine
implemented in Aqueue.dll to process received messages. The extended version of
the SMTP service does not use Aqueue.dll. Exchange Server 2003 replaces this
component with an Exchange advanced queuing engine, implemented in Phatq.dll.
To load Phatq.dll, Exchange Server 2003 modifies the SmtpAdvQueueDll property for
the SMTP service in the IIS metabase and points it to the Exchange advanced
queuing engine. Aqueue.dll and Phatq.dll perform similar functions, but Phatq.dll is
the only version that works with Exchange Server 2003.
Events Triggered by the Advanced Queuing

Engine
As the following figure illustrates, the advanced queuing engine acts as an information
controller or dispatcher of system, store, and transport events to process each message after
it reaches the SMTP transport subsystem.
241
The advanced queuing engine in the SMTP architecture
The advanced queuing engine dispatches the following events:
• SMTP Transport OnSubmission This event occurs when a message arrives at

the transport subsystem through \Pickup directory, SMTP connection, or Exchange
store driver. For categorization, routing, and delivery, the message must pass to the
advanced queuing engine. This action triggers an OnSubmission event, also named
OnTransportSubmission. The advanced queuing engine uses this event to invoke
event sinks, such as an anti-virus scanner, that check all incoming messages before
any other transport processing occurs. Accordingly, for example, the Exchange
Transport AntiVirus API event sink is registered for the OnSubmission event. Another
sink registered for this event is the Exchange Transport XEXCH50 Submission sink,
which prepares messages with XEXCH50 envelope data for further processing from
remote servers running Exchange Server 2003.
Note:
The OnSubmission event is the only event that offers a Collaboration Data
Objects (CDO) interface. Therefore, you can program event sinks using Microsoft
Visual Basic or Visual Basic Scripting Edition (VBScript). You must program all
other event sinks using C/C++ or Microsoft Visual C#.
CDO-based event sinks can register for the CDO_OnArrival event, which is a wrapper
around the OnSubmission event that provides a handle to the message in CDO message
format. The major benefit to using CDO_OnArrival is that the CDO message object
interface has many useful methods, such as the parsing of MIME and Request for
242
Comments (RFC) 822 headers. For details about extending the SMTP service through a
CDO sink, see Microsoft Knowledge Base article 837851, "How to configure an Internet
Information Services SMTP virtual server to archive or to remove messages in an
Exchange Server 2003 test environment."
The major drawback of CDO-based event sinks is that the CDO interface adds overhead.
VBScript-based event sinks do not perform as fast as sinks written in C, C++, or Visual
C#. It should also be noted that CDO-based event sinks operate synchronously, and
there is a time limit of 60 seconds to process the message. After 60 seconds, the
advanced queuing engine assumes that the script is not responding and stops the
processing. The 60 second limit is hard coded and cannot be changed. Moreover, the
CDO interface does not support changing the content of store-submitted messages. This
is a limitation that CDO_OnArrival event sinks share with all other event sinks. This
limitation exists because Exchange converts a store-submitted message to a temporary
SMTP version for the event sink to handle, and then discards the temporary version after
the sink finishes processing. For more information about this issue, see Microsoft
Knowledge Base article 273233, "PRB: CDOEX: Cannot Change MAPI Message
Contents in a CDO SMTP Event Sink."
Because Exchange discards the temporary copy of a store-submitted message, you

cannot use an event sink to add a disclaimer or other modifications to all outbound
messages, unless you force all messages to be received through SMTP. To do this, you
must install the event sink on a bridgehead server that is separate from the mailbox
servers in your organization. Servers running Exchange Server 2003 communicate with
each other through SMTP, so all messages transferred to the bridgehead arrive through
SMTP.
• SMTP Transport OnPreCategorize This event occurs immediately before a

message is sent to the categorizer. This event is similar to the OnSubmission event,
except that it offers no CDO version. By default, no sink is registered for this event.
• SMTP Transport OnCategorize This event occurs when a message must be

categorized. This is not a single event, but an event category. There are ten different
kinds of events that can be triggered for sinks that bind to this category. An event sink
that binds to this category is the categorizer sink that resolves sender and recipients,
and provides categorization information, such as the home server for each recipient,
to the advanced queueing engine. In Exchange Server 2003, two event sinks are
registered for the OnCategorize event: Exchange Categorizer and Outlook Mobile
Access Push Categorizer (registered in the IIS metabase as Mobile Categorizer).
Exchange Categorizer processes e-mail messages to resolve recipient information,
expand distribution lists, check per-recipient restrictions, and much more. Mobile
Categorizer implements up-to-date notifications for mobile devices.
• SMTP Transport OnPostCategorize This event occurs immediately after the

message is categorized. At this point, all distribution lists (that have the local server
243
as an expansion server) have been expanded, and the actual recipients are listed in
the message transfer envelope. By default, no sink is registered for this event.
Note:
It is possible for Exchange Categorizer to split a message into multiple, separate
copies, with different content or envelopes, during a process named bifurcation
(explained later in this section). After categorization, the SMTP Transport
OnPostCategorize event is triggered separately in an uncorrelated manner for
each copy of the message. The message recipients might be distributed across
several different message copies.
• SMTP Transport OnGetMessageRouter This event occurs when a message is

intended for remote recipients and must be routed. This is not a single event, but an
event category. There are multiple events that can be triggered for a sink that binds
to this category. For example, the sink that determines the message type ID and next
hop information in Exchange Server 2003 is named Exchange Router. The advanced
queuing engine also uses the Exchange Router sink to update link state information,
if the state of local messaging connectors changes, as explained in Message Routing
Architecture.
Note:
The base SMTP service of Windows Server 2003 does not implement a router
sink and sends messages point-to-point to the final recipient destination.
• SMTP Transport OnMsgTrackLog This event occurs when the advanced

queuing engine processes a message, so that a sink can persist tracking information
about the message in a log file. Exchange Server 2003 implements a MsgTrackLog
sink for this event to write status information about all messages that pass through
the advanced queuing engine to message tracking log files, stored in the \Program
Files\Exchsrvr\<servername>.log directory (for example, \Program
Files\Exchsrvr\Server01.log).
Note:
By default, message tracking is disabled.
• SMTP Transport OnDnsResolveRecord This event occurs when a domain

name must be resolved to an IP address. Exchange Server 2003 registers a sink
called Exchange LoadBalancer for this event, which is used to balance the load of
outbound message transfer for routing group connectors with multiple bridgehead
servers.
• SMTP Transport OnMaxMsgSize This event occurs when a submitted

message contains content that exceeds the currently configured maximum message
size. An event sink that handles this event can override the default blocking. By
default, no sink is registered for this event.
244
• SMTP StoreDriver This event occurs when a message must be saved to disk
or to the Exchange store. This is not a single event, but an event category. There are
multiple events that can be triggered for a sink that binds to this category. For
example, the advanced queuing engine triggers numerous StoreDriver events as a
message passes through the transport subsystem. You can read more about
StoreDriver event sinks later in this section.
Note:
SMTP StoreDriver events can be triggered by the advanced queuing engine or
the protocol engine.
Message Queues in the Advanced Queuing

Engine
The advanced queuing engine maintains a number of message queues in memory. A shared
pool of threads services these internal queues. You can view these queues in Exchange
System Manager. Specifically, the Exchange Queue Viewer snap-in, implemented in
Exadmin.dll, communicates with the advanced queuing engine through the queue admin
interface (PhatQAdm.dll) to list these queues and to perform queue management functions,
such as freezing or unfreezing messages in a message queue. The following figure illustrates
the most important message queues in the advanced queuing engine, as they relate to
transport events.
245
Message queues and transport events
The advanced queuing engine uses the following message queues:
• Messages Pending Submission This queue is also named the pre-submission

queue. This is the entry point into the advanced queuing engine. The OnSubmission
event is triggered for all messages in this queue. When this event succeeds,
messages are placed into the pre-categorization queue.
• Messages Awaiting Directory Lookup This queue is also named the pre-
categorization queue. It is a throttling queue for the categorizer. This queue contains
messages before they reach the categorizer. The categorizer resolves the sender
and recipient information against Active Directory, expands distribution lists, checks
restrictions, applies per-sender and per-recipient limits, and more. The categorizer is
discussed in more detail in the section, "Exchange Categorizer," in SMTP Transport
Components.
246
Messages are not in any queue during message categorization. A message that is being
categorized is actually in the categorizer and is not listed in any queue. Thus, Queue
Viewer might show an empty pre-categorization queue, while the Performance monitoring
tool might show a positive count for the performance counter called Categorizations in
progress. By default, the advanced queuing engine allows a maximum of 1,000 pending
categorizations before retaining messages in the pre-categorization queue. This
threshold can be changed using the following registry key.
Value MaxPendingCat
Type REG_DWORD
Value Data 0x3E8
Description This indicates the maximum number of

pending categorizations before the
advanced queuing engine starts retaining
messages in the pre-categorization queue.
The default is 1,000 connections.
• Messages Waiting To Be Routed This queue is also named the pre-routing

queue. It holds all messages queued for local and remote delivery after they are
categorized and post-categorization events are triggered. This is the point at which
the advanced queuing engine decides which messages must go to the local delivery
queue and which must be routed. For all messages to remote recipients, the
advanced queuing engine calls the routing engine in an OnGetMessageRouter event
to determine the next hop for each message in this queue and move the messages to
their respective link queues.
• Local Delivery After categorization, messages pass through the pre-routing

queue and enter the local delivery queue, if the recipient's mailbox resides on the
local server running Exchange Server 2003. The message categorizer marks the
recipient as local by setting a per-recipient property that indicates the destination
server, based on the recipient's homeMDB attribute, which points to the recipient's
mailbox store. For local recipients, the OnGetMessageRouter event is skipped and
the advanced queuing engine moves messages to the local delivery queue before
raising a StoreDriver event. The StoreDriver event informs the Exchange store driver
that messages must be transferred to the Microsoft Exchange Information Store
service.
• Dynamic Delivery These queues are domain queues with names that match
the remote domain or next hop address on the link. The queue name identifies the
destination.
247
A special case is message transfer through Exchange MTA, which is often referred to as
gateway delivery, because the MTA is also responsible for all MAPI-based connectors to
non-Exchange messaging systems, as explained in more detail in X.400 Transport
Architecture and Gateway Messaging Connectors Architecture. The SMTP transport
subsystem uses the Exchange store driver to move messages to and from the MTA
through the Exchange store. However, the advanced queuing engine does not know
whether a message must be transferred through SMTP or the MTA until the routing
engine returns this information. If the next hop of the recipient is over a non-SMTP
connector (Routing Group Connectors are considered SMTP connectors unless the
Routing Group Connector instance has an Exchange 5.5 bridgehead), the message is
sent to the Exchange MTA delivery queue and then to the local delivery queue. From
there the Exchange store driver sends it to the Exchange store. The recipient properties
that the categorizer sets in the message transfer envelope are used to distinguish which
recipients must be delivered to a local mailbox and which must be delivered to the
Exchange MTA.
• System These queues contain messages with specific parameters. The

following table lists the system queues that the advanced queuing engine maintains,
in addition to delivery queues.
System queues in the advanced queuing engine
Queue Description
Messages With an Unreachable This queue contains messages that cannot

Destination reach their final destination server. For
example, Exchange cannot determine a
route or a connector to the final destination,
or all available routes or connectors are
labeled as down.
248
Queue Description
Messages Queued for Deferred Delivery This queue contains messages that are
queued for later delivery. This queue might
contain messages that were sent by earlier
versions of Microsoft Outlook, such as
Microsoft Outlook 2000. Newer versions of
Outlook store these types of messages in
the Exchange store. Messages remain in
the Messages Queued for Deferred
Delivery queue until their scheduled
delivery time.
Note:
This queue might also contain
messages sent to a mailbox that
was recently moved to another
mailbox store or Exchange server,
while waiting for directory
replication to update the mailbox
location.
DSN Messages Pending Submission This queue contains delivery status

notifications that are waiting to be rendered
by Exchange. For example, if a message
remains in a message queue for an
extended period of time, the advanced
queuing engine generates a delivery status
notification to inform the sender that the
message was delivered. Non-delivery
reports (NDRs) are also delivery status
notifications. For more information about
delivery status notifications, see the
following Microsoft Knowledge Base
articles:
• 284204, "Delivery status

notifications in Exchange Server
and in Small Business Server"
• 256321, "Enhanced Status

Codes for Delivery - RFC 1893"
249
Queue Description
Failed Message Retry This queue contains messages that failed a

queue submission. Messages can fail a
queue submission for several reasons, and
the failure can occur before any other
processing is done. If messages are
corrupted or system resources are low,
messages appear in this queue.
Limiting the Number of Messages in Message

Queues
Each message in a message queue consumes at least four kilobytes (KB) of memory.
Therefore, you might encounter insufficient memory with a very large queue. To avoid this
situation, you can use the following registry parameter to limit the number of messages that
are stored in the queue at a given time.
Caution:
Using Registry Editor incorrectly can cause serious problems that may require you to
reinstall your operating system. Microsoft cannot guarantee that problems resulting
from the incorrect use of Registry Editor can be solved. Use Registry Editor at your
own risk.
Location HKEY_LOCAL_MACHINE\Software\Microsoft\Ex
change\Mailmsg
Value MaxMessageObjects
Type REG_DWORD
Value Data 0x000186a0

250
Description If a value is not specified, the default is

0x000186a0 (100,000) messages.
Specifying a lower value reduces the
maximum number of messages that can
reside in the advanced queuing engine,
thus decreasing the maximum memory
footprint for SMTP. After this limit is
reached, each SMTP connection made to
the server returns with an out-of-memory
error. For example, if this value is reduced
to 10,000 messages, SMTP refuses
inbound messages in excess of 10,000
messages.
SMTP Transport Components

In Exchange Server 2003, the advanced queuing engine uses the following six transport
event sinks to deliver messages to their destinations:
• Exchange Transport XEXCH50 Submission This event sink is implemented in

Peexch50.dll and enables the SMTP transport subsystem to receive messages from
remote Exchange servers through SMTP, using the XEXCH50 command. This event
is registered for the OnSubmission event.
• Exchange Transport AntiVirus API This event sink is implemented in

OnSubmit.dll and enables non-Microsoft vendors to implement virus scanners, which
check each message for malicious attachments and data structures before they
reach their destinations. This event is registered for the OnSubmission event.
By default, transport scanning is not enabled, as it causes messages to be scanned

twice, once at the SMTP layer and once in the Exchange store. However, if you are using
front-end servers to connect an Exchange organization to the Internet, you can enable
this feature on these servers by using the following registry key.
Location HKey_Local_Machine\Software\Microsoft\Ex
change\TransportAVAPI
Value Enabled
Type REG_DWORD
Value Data 0x1

251
Description A value of 0x1 enables transport scanning.

A value of 0x0 disables transport scanning.
If a value is not specified, the default is
0x0.
Note:
Transport-scanning functionality is available only with Exchange virus scanners
that are based on Virus Scanning Application Programming Interface
(VSAPI) 2.5.
• Exchange Categorizer This event sink is implemented in Phatcat.dll and

registered for the various events in the OnCategorize event category. The categorizer
is one of the most important components in the transport subsystem. It performs
address resolution, accomplishes message forwarding, sets per-domain outbound
and inbound Internet message format conversion flags, expands distribution groups,
and enforces global settings for blocking delivery status notifications. The categorizer
might also add alternate recipients to the message for journaling purposes, bifurcate
messages (if multiple copies of a message must be created), and more. The
categorizer is covered in more detail in the section, "Exchange Categorizer," later in
this topic.
• Mobile Categorizer This event sink, implemented in Miscat.dll, is also

registered for the various events in the OnCategorize event category. This event sink
supports up-to-date notifications for mobile devices, such as Microsoft Pocket PC,
which is a new feature in Exchange Server 2003. By default, up-to-date notifications
are installed with Exchange Server 2003. When an event is generated, for example,
when a user receives a message, a notification is sent to the user's Pocket PC. The
Pocket PC can then perform synchronization in the background, so that the most
current information is available when the user next checks the device.
Note:
Up-to-date notifications are available only on devices that run the Microsoft
Windows Mobile 2003 operating system.
• Exchange Router This event sink is implemented in Reapi.dll and registered

for the events in the OnGetMessageRouter event category. The Exchange Router
sink is the second most important component in the transport subsystem. The
advanced queuing engine uses this component to determine the next hop to the
message destination. For detailed information on the routing architecture of
Exchange Server 2003, see Message Routing Architecture.
• Exchange LoadBalancer This event sink is implemented in Reapi.dll and

registered for the OnDnsResolveRecord event. The advanced queuing engine uses
this sink to distribute outbound message transfer evenly across all bridgehead
252
servers specified for a routing group connector. For more information about load
balancing message transfer between routing groups, see Message Routing
Architecture.
Exchange Categorizer
The Exchange message categorization system is made up of two components, a base
categorizer and the Exchange categorizer. The base categorizer is made up of code originally
implemented in Aqueue.dll. Exchange Server 2003 replaces Aqueue.dll by registering a DLL
called Phatq.dll. Phatq.dll includes all the features available in Aqueue.dll, plus Exchange-
specific features. The Exchange categorizer is implemented in PhatCat.dll. PhatCat.dll is
registered for the events in the OnCategorize event category. The advanced queuing engine
triggers these events through the base categorizer. The base categorizer and Exchange
categorizer jointly process the message in ten categorizer events.
Note:
The base categorizer triggers the events that drive the message categorization
process.
The advanced queuing engine triggers the following ten categorizer events:
• Register The base categorizer and the Exchange categorizer use this event to
initialize their interfaces. For example, the Exchange categorizer initializes its
interfaces to Directory Service Access (DSAccess), routing engine, and store driver. If
any one of these interfaces fail, then the Exchange categorizer fails to initialize itself.
All categorizers require interfaces to these components for the following reasons:
a. Communication with DSAccess is required to determine if recipients are

in the DSAccess cache, in which case the required information can be
obtained directly from DSAccess without the overhead of performing
Active Directory lookups.
The Exchange categorizer also determines the list of global catalog servers that
DSAccess is using and provides this list to the base categorizer to use for its
Lightweight Directory Access Protocol (LDAP) lookups. By default, the base
categorizer uses the Active Directory domain topology to determine the global catalog
servers for LDAP lookups. However, on a server running Exchange Server 2003, the
categorizer should use the global catalog servers that DSAccess determined
dynamically, based on the Active Directory site topology, or statically, if you hard
coded global catalog servers in a DSAccess profile in the registry. For more
information about the DSAccess discovery process, see Exchange Server 2003 and
Active Directory.
b. Communication with the routing engine is necessary, for example, when

encapsulating a non-SMTP one-off address to an SMTP address. A one-off
253
address is an address that does not resolve against a recipient object in

Active Directory. The Exchange categorizer calls the routing engine to
determine if a route to the target exists. If a route does not exist, the
categorizer generates an NDR. If a route exists, the categorizer stamps the
one-off recipient with the encapsulated address on the MailMsg object. Later,
the advanced queuing engine passes the address information to the routing
engine, which then determines the next hop for the recipient.
Note:
The MailMsg object is an in-memory structure that contains a message
transfer envelope, plus a pointer to the actual message in either the NTFS
store or the Exchange store. The message transfer envelope has all
message header properties and recipient user information that the
categorizer needs to process the message.
c. Communication with the Exchange store driver is required in certain

situations during categorization. For example, the Exchange categorizer
might have to copy a message from the \Queue folder to enable the
Exchange store to process and convert RFC 822 content using the content
conversion logic that is implemented in the Internet mail (IMAIL) component
of the Exchange store.
• BeginMessageCategorization This event is called once for each MailMsg

object submitted to the base categorizer, which signals the beginning of a message
categorization process.
• EndMessageCategorization This event is called for each MailMsg object

submitted to the base categorizer. It signifies the end of message categorization.
• BuildQuery This event is called once for each recipient and the sender that
must be determined. However, query-based distribution group members are not
determined, because their attributes are already determined when processing the
query-based distribution group. For all recipients that must be determined, the
Exchange categorizer verifies whether the recipient resides in the DSAccess cache.
If this is true, the Exchange categorizer returns an ICategorizerItemAttributes object
to bypass the base categorizer directory service lookup code. Processing continues
with the ProcessItem event for this recipient. If the recipient is not in the DSAccess
cache, the LDAP-lookup code of the base categorizer creates an LDAP-compliant
search filter for the user, which is typically based on the proxyAddresses attribute and
the input address, for example:
(proxyAddresses=smtp:ted@fabrikam.com)
The input address can be an SMTP address, an X.400 address, or a non-Exchange

address, depending on the source and destination of the message.
254
Tip:
To illustrate how an LDAP filter, based on proxyAddresses, can be used to find a
particular recipient object in Active Directory, you can use the LDIFDE tool
(Ldifde.exe) included in Windows Server 2003. The LDIFDE command-line
parameter "r" allows you to specify an LDAP search filter. For example, you can
use the following command to find Ted in the global catalog on Server01 in a
domain called fabrikam.com: ldifde -f c:\Ted.ldf -s Server01 -t 3268 -d
"dc=fabrikam,dc=com" -p subtree -r
"(proxyAddresses=smtp:ted@fabrikam.com)". If Ted has an SMTP address of
Ted@fabrikam.com, LDIFDE finds the recipient object in Active Directory and
writes all of its attributes to a plain-text file called Ted.ldf. The Exchange
categorizer uses exactly the same principle to find recipient objects, retrieve
default SMTP, X.400, and legacyExchangeDN attributes from the recipient, and
set them as properties on the MailMsg object. Later, the Exchange categorizer
uses this information in message processing.
The Exchange categorizer uses the proxyAddresses attribute for almost all address types
(except legacy Exchange distinguished names and X.500 distinguished names, because
this address information is not stored in the proxyAddresses attribute). For example,
when an Outlook user sends a message to another user in the Exchange organization or
an external user that has a mail-enabled recipient object in Active Directory, the Outlook
client specifies the legacyExchangeDN address of the recipient in the outgoing message
for backward compatibility with Exchange Server 5.5. The Exchange categorizer then
uses the legacyExchangeDN attribute in the search filter to find the recipient object in
Active Directory.
The Exchange categorizer must handle X.500 distinguished names when resolving the
members of a distribution group, because the group members are listed with their
distinguished names in the member attribute. In this situation, the Exchange categorizer
parses the distinguished name to determine the relative distinguished name (RDN) of the
recipient, which is the recipient's common name (CN) in Active Directory. The Exchange
categorizer then uses the cn attribute in the search filter with the remainder of the
distinguished name (which points to the recipient object's parent container in
Active Directory) as the root of the LDAP search to find the recipient object. By default,
the cn attribute is indexed in Active Directory, which results in an efficient directory
lookup.
• BuildQueries This event is called once for each batched lookup. The base
categorizer uses this event to combine in a single query the individual searches for
up to 20 recipients. Then SendQuery can issue a single search that returns a batch
of recipients. It is usually more efficient to issue a single search for multiple recipients
than to issue multiple searches for multiple recipients. This is true even though extra
processing is required to handle a SortQueryResults event when performing
searches in batches and matching the returned results with the individual recipients
of the message. The matching required on results fewer than 20 is more efficient
255
than requiring multiple round trip LDAP queries to Active Directory. The following is
an example of an LDAP-compliant search filter that can be used to find multiple users
at once:
(|(proxyAddresses=smtp:Ted@fabrikam.com)
(proxyAddresses=smtp:Birgit@fabrikam.com))
Tip:
To illustrate how an LDAP filter for multiple users works, you can use the
following command to find Ted and Birgit in the global catalog on Server01 in a
domain called fabrikam.com: ldifde -f c:\TedandBirgit.ldf -s Server01 -t 3268 -d
"dc=fabrikam,dc=com" -p subtree -r "(|
(proxyAddresses=smtp:Ted@fabrikam.com)
(proxyAddresses=smtp:Birgit@fabrikam.com))". If Ted has an SMTP address
of Ted@fabrikam.com and Birgit has an SMTP address of Birgit@fabrikam.com,
LDIFDE finds both recipient objects in Active Directory and writes all of their
attributes in separate sections to a plain-text file called TedandBirgit.ldf. The
categorizer uses exactly the same principle to find multiple recipient objects.
• SendQuery The categorizer triggers this event once for each batched lookup
and then performs the directory search asynchronously.
• SortQueryResult The categorizer calls this event once for each batched lookup
and then determines which users belong to which directory object (the LDAP results
returned for the query). The proxyAddresses attribute is used for matching results
from lookups, based on an SMTP address, an X.400 address, or a non-Exchange
address. The legacyExchangeDN attribute is used to match legacyExchangeDN
lookups, and the distinguishedName attribute is used to match X.500 distinguished
name lookups. The address information must uniquely identify each recipient for this
to work. If values are not distinguishing, a 5.1.4 NDR results. The following table
provides the details for the 5.1.4 NDR.
Details of NDRs with code 5.1.4
Numerical code 5.1.4
Possible cause Two objects have the same (proxy)

address, and mail is sent to that address.
Troubleshooting Check the recipient address and resend the

message. This issue can also occur if the
recipient does not exist on the remote
server.
256
Comments For more information about NDR codes,

see Microsoft Knowledge Base article
284204, "Delivery status notifications in
Exchange Server and in Small Business
Server."
• ProcessItem The base categorizer triggers this event to add the default SMTP,
X.400, X.500, and legacyExchangeDN addresses for each recipient to the MailMsg
object. The addresses that the Exchange categorizer sets on the recipient are based
on the attributes returned for the recipient from Active Directory. The mail attribute
contains the SMTP address, the textEncodedORAddress attribute contains the X.400
address, the distinguishedName contains the X.500 address, and the
legacyExchangeDN attribute contains the legacy Exchange address.
Note:
The addresses used for the recipient after this point do not necessarily match the
address used to look up the recipient in Active Directory. For example, a non-
Exchange user might send a message to the secondary proxy address of an
Exchange user. During the ProcessItem event, the Exchange categorizer
replaces the secondary proxy address with the primary address of the Exchange
user.
The Exchange categorizer also has special code to handle contacts and one-off
addresses. Contacts are non-Exchange recipients, but they reside in Active Directory.
One-off addresses do not exist in Active Directory. The sender might have typed the
recipient address directly in the To line or might have specified a contact object from his
or her personal Contacts folder in Outlook. In either scenario, only the target address of
the recipient is known and added to the MailMsg object. If a contact address or a one-off
SMTP address matches an address space of the local Exchange organization, a conflict
occurs, because contacts and one-off addresses must refer to recipients outside of the
local Exchange organization.
The categorizer enforces its authority for addresses that match address spaces specified
in recipient policies when you select the This Exchange Organization is responsible
for all mail delivery to this address check box. If a user sends a message to an
address that is not in Active Directory but matches an address space in an authoritative
recipient policy, the Exchange categorizer sets an error status on the recipient that later
causes the advanced queuing engine to generate a 5.1.1 non-delivery report, which
signifies an unknown address. The Exchange categorizer also considers itself
authoritative for legacyExchangeDN and X.400 addresses that match the site address
space of the local administrative group.
257
Note:
If you have an alternate server configured on an SMTP virtual server (the
Forward all mail with unresolved recipients to host setting), the categorizer
reroutes messages to non-existent addresses in its authoritative address spaces
to the alternate server, instead of generating a 5.1.1 non-delivery report for the
recipients. This action is taken during the CompleteItem event.
The following table provides the details for the 5.1.1 non-delivery report.
Details of non-delivery reports with code 5.1.1
Possible cause The e-mail account does not exist at the

organization to which this message was
sent. For example, if an Internet user sends
a message to
user_does_not_exist@fabrikam.com, where
your server is authoritative for fabrikam.com
and no one in Active Directory has that
address, a 5.1.1 NDR is generated.
A 5.1.1 NDR is an "authoritative not found"

NDR. It applies to SMTP addresses
according to recipient policies, to
legacyExchangeDN recipients according to
the legacyExchangeDN attribute of the local
administrative group, and to X.400
addresses according to the administrative
group's X.400 site address. Otherwise, a
5.1.2 NDR is generated any time you have
a non-SMTP address that is not routable
and does not match a recipient object in
Active Directory.
Troubleshooting Either the recipient address is incorrectly

formatted or the categorizer cannot properly
resolve the recipient. You must check the
recipient address and resend the message
to resolve this error.
For more information about NDR codes,

Server."
258
For addresses that are not in Active Directory and do not match an authoritative recipient
policy or local site address space, the categorizer does not register an error. Instead, it
registers a relay to a remote destination.
• ExpandItem The categorizer triggers this event to handle the following tasks:
• Distribution list expansion If the local server is an expansion server for

the distribution groups in the message, the distribution groups can be
expanded locally. The msExchExpansionServerName attribute lists the
server running Exchange Server 2003 that is responsible for distribution list
expansion. If this attribute is not set, any server running Exchange can
expand that distribution group. If a server is specified and it is not the local
server, the categorizer must forward the message to that server, because the
mail-enabled group must be expanded on that specific server. When a
distribution group is expanded, the categorizer resolves each individual
recipient.
• Restriction checking The categorizer checks for any per-sender and

per-recipient restrictions, limits, and message format settings and marks
each recipient appropriately. For example, if the sender has a recipient limit
and a message exceeds this limit, the categorizer requests the advanced
queuing engine to generate a 5.5.3 NDR to ensure that no message has
more than the allowed number of recipients.
Details of NDRs with code 5.5.3
Possible cause Too many recipients on the sent message.
Troubleshooting The recipient limit is a configurable limit on

the receiving server. To resolve this issue,
either increase the recipient limit, or divide
the message into multiple messages to fit
the server limit.

Server."
• Alternate recipients Using Active Directory Users and Computers, you

can specify alternate recipients for Exchange users on the Exchange -
General tab under Delivery Options. The Exchange categorizer adds this
recipient information to the MailMsg object and forwards the message. When
259
transferring the message across an Exchange organization, a flag is passed

in the message transfer envelope through XEXCH50 with the original
recipient. This prevents multiple copies of a message from being forwarded
to an alternate recipient. When the Exchange categorizer discovers this flag
for an original recipient, it skips the code to add the alternate recipient.
The Exchange categorizer also checks for loop conditions (for example, Ted forwards
to Birgit and then Birgit forwards to Ted). If a loop is detected, the categorizer informs
the advanced queuing engine to generate a 5.4.6 NDR for the first user in the loop.
Details of non-delivery reports with code 5.4.6
Possible cause A categorizer forward loop is detected. A

targetAddress attribute is set on a mailbox-
enabled user that contains an address that
is in an authoritative SMTP domain. The
targetAddress attribute must point to a
remote domain.
A 5.4.6 NDR is also generated when you

have a forwarding loop in Active Directory.
For example, this NDR is generated if a
chain of Exchange users has alternate
recipients that point to each other circularly.
Troubleshooting Check the contact's alternate recipient.
Check and remove the targetAddress

attribute from mailbox-enabled users.

Server."
• Message bifurcation If recipients require different message formats, the

Exchange categorizer bifurcates the message to create multiple message
copies. Message bifurcation is explained in more detail later in this section.
• CompleteItem The base categorizer calls this event to perform final processing
when the work of all other categorizer event sinks is complete. Final processing
includes the following tasks:
• Journaling Journaling is the process of copying messages sent or

received by users on an Exchange server to a message archive. If the
260
current server is the first server to handle a sender or recipient for which
journaling must occur (for example, because message journaling is enabled
for the sender's or a recipient's local mailbox store), the Exchange
categorizer adds the mailbox store's journaling address to the message
transport envelope and transfers the message.
The journaling configuration is stored in Active Directory and is available to all

Exchange servers in the organization. For example, an Exchange user (whose home
mailbox store has journaling enabled) might use an Internet client to send messages
through SMTP to a bridgehead server that is part of the Exchange organization. The
bridgehead server then adds the journaling address to the message transfer
envelope and forwards a copy of the message to the archive mailbox for that sender.
Servers running Exchange Server 2003 communicate message transfer envelope
information, including the list of journal addresses for sender and recipients, using the
XEXCH50 command. If multiple Exchange servers are involved in message transfer
and a server finds a journaling address in the message transfer envelope, it does not
add the journaling address again, thus preventing duplicate messages in the
message archive.
Note:
Message journaling might not reliably account for blind carbon-copy
recipients, recipients from transport forwarding rules, or recipients from
distribution group expansions. If you must record the message transport
envelope data, in addition to the message data, you must enable Envelope
Journaling. This is accomplished using the E-Mail Journaling Advanced
Configuration tool, available for download at the Exchange Server Email
Journaling Advanced Configuration Web site.
• Forwarding unresolved recipients If you configured the SMTP virtual

server to forward all messages with unresolved recipients to an alternate
host, the Exchange categorizer sets the destination server for all unresolved
recipients to the fully qualified domain name (FQDN) of the alternate server.
• Recipient marking The Exchange categorizer marks each recipient by

setting a per-recipient property on the message. This property indicates the
destination server for each recipient. The typical format of this property is the
FQDN of the recipient's home server. Based on the FQDN that the
categorizer sets on each recipient, the advanced queuing engine decides
whether to deliver the message locally or call the routing engine. All
messages matching the local server's FQDN go straight from the pre-routing
queue to the local delivery queue, without performing message routing. For
recipients that are not local, the advanced queuing engine must call the
routing engine later to determine the next hop for message transfer.
261
Note:
The Exchange categorizer determines the FQDN of each recipient's home
server through a component called MDAccess. MDAccess uses the
configuration information in Active Directory to determine the network
address of the server hosting a recipient's mailbox store. The Exchange
categorizer sets the recipient's homeMDB attribute as a property on the
recipient in the message transfer envelope, if the recipient's mailbox resides
on the local Exchange server. With this information the Exchange store driver
later determines the mailbox store to which it delivers the recipient's
message.
• Redirecting delivery status notifications When a user sends a message

on behalf of a distribution group (that is, the user specifies the group in
From) and requests delivery or read receipts, the delivery status notifications
are generated and sent to the distribution group, rather than to the sender
only. To address this issue, the categorizer directs status notifications to the
actual sender by changing the sender address in the message transfer
envelope of the message to the address of the actual sender.
Users rarely send messages on behalf of a distribution group. A more common

situation occurs when a user receives multiple out-of-office notifications, auto replies,
and delivery status notifications, such as non-delivery reports, after sending a
message to a large distribution group. To mitigate this issue, the Exchange
categorizer suppresses out-of-office notifications and auto replies by default when
sending messages to a distribution group. To accomplish this, the Exchange
categorizer adds a property to the recipients in the message envelope. The
Exchange store uses this property as a parameter during local delivery operation to
suppress rules which would otherwise generate out-of-office notifications and auto
replies. This extended property of the message envelope is transmitted between
servers running Exchange Server 2003 using XEXCH50, if the individual distribution
group members reside on different mailbox servers.
The Exchange categorizer redirects or deletes out-of-office notifications, auto replies,

and delivery status notifications according to the criteria listed in the following table.
262
Delivery status notification redirection and deletion criteria
Criteria Action
Distribution group has an owner, and Redirect non-delivery reports to notify the
delivery reports are configured to be sent to configured owner of the group when an
this owner error occurs during the delivery of a
message to the group or to one of its
members. The categorizer redirects any
non-delivery reports for group members that
would usually return to the message
sender.
By default, only NDRs are redirected to the

group owner. In cases in which a sender
requests explicit status notifications (such
as a delivery receipt notification), SMTP
protocol delivery status notification
extensions are used to generate the
reports. If a sender requests a delivery
status notification in a message to a group
with report redirection enabled, the sender
receives the delivery status notification
when the group is either expanded
successfully or redirected to its expansion
server (if the local server is not an
expansion server for the group).
Delivery reports are configured to be sent Send delivery status notification to the
to message originator sender of the message. The categorizer
suppresses out-of-office notifications and
auto replies if the Send out-of-office
messages to originator check box, on the
Exchange-Advanced tab, is not selected
for the group. By default, this check box is
not selected.
263
Criteria Action
Distribution group is configured to suppress Suppress all out-of-office notifications, auto

delivery reports for group members to avoid replies, and all types of delivery status
disclosing membership information notifications (such as delivery notifications
and read receipts). This is similar to
redirecting NDRs, except that the
categorizer suppresses all types of delivery
notifications, including non-delivery reports
for individual group members. To block all
delivery reports, the categorizer changes
the sender address in the message transfer
envelope of the message to "<>".
If a sender requests a delivery status

notification (such as a delivery receipt
notification) in a message to the group,
SMTP protocol delivery status notification
extensions generate the delivery status
notification when the group is either
expanded successfully or redirected to its
expansion server (if the local server is not
an expansion server for the group).
Note:
By default, the categorizer suppresses out-of-office notifications, auto replies,
and delivery status notifications when a user sends a message to a
distribution list. You can configure this by selecting the Send out-of-office
messages to originator check box, on the Exchange-Advanced tab, in the
distribution group properties. For more information, see Microsoft Knowledge
Base article 325469, "Automatic replies from distribution group do not work in
Exchange Server 2003 or Exchange 2000 Server."
• Status code mapping The Exchange categorizer also maps the status
codes that previous categorizer sinks have returned to the recipients in the e-
mail message. Error codes then cause the advanced queuing engine to
generate NDRs for affected recipients.
Message Bifurcation
As mentioned previously, the categorizer might create multiple copies of a message during
the categorization process. This process is called bifurcation and is performed any time
264
different recipients must receive different copies of the same message. Bifurcation is
performed for the following reasons:
• Content conversion Content conversion must occur whenever an Exchange

user sends a message in MAPI format to a non-MAPI user. For example, an Outlook
user might send a message to a recipient on the Internet, in which case the
categorizer must perform content conversion from MAPI to an Internet message
format. Content conversion must also occur when a MAPI message must be
transferred over an SMTP-based routing group connector in a mixed-mode Exchange
organization. Bifurcation is required for content conversion because the categorizer
cannot change the content of existing messages. You can read more about content
conversion later in this section.
• Removing delivery and read receipt requests on a per-recipient basis This
is necessary when a message with a read receipt request is sent to a distribution
group with hidden membership information and an additional individual recipient in
the To line. Because the membership of the group must remain confidential, read
receipts must not be generated when the distribution group members receive the
message. Otherwise, the sender would be able to identify the group members based
on the read receipts received. To avoid this, two copies of the message are created,
one for the distribution group with hidden membership and the other for the individual
recipient. The read receipt request will be removed from the message to the
distribution group.
• Delivery status notifications with multiple recipients When the Exchange

categorizer detects delivery status notifications with multiple recipients, the Exchange
categorizer bifurcates the message for each recipient, because the Exchange MTA
(to comply with the X.400 standard) does not support more than one recipient per
notification. Because the categorizer cannot determine if the MTA is involved in
message transfer (only the routing engine can determine this), the categorizer must
create a separate delivery status notification for each individual recipient.
Bifurcation occurs on the server running Exchange Server when the message is submitted by
the client. You can check the number of new messages created by the categorizer using the
Performance tool. The following figure illustrates the relevant performance counter.
265
The Cat: Messages bifurcated performance counter
Content Conversion
Users of MAPI clients, such as Outlook, can specify on a per-message or per-recipient basis
whether to send the message in rich-text, HTML, or plain text format. The categorizer must
convert the message accordingly. Administrators can also specify preferred formats in the
properties of mail-enabled recipient objects in Active Directory or define Internet mail formats
on an address space basis (for example, per Internet domain, in Exchange System Manager,
under Global Settings). Thus, messages sent to users in an Internet domain can be
formatted in rich-text, Multipurpose Internet Mail Extensions (MIME), or Unix-to-Unix encoded
(UUEncoded). The categorizer uses specific logic to coalesce these various format settings
for each recipient. When the categorizer resolves the message recipients, it might discover
that different message formats are required for subsets of recipients or individual recipients.
The categorizer must then bifurcate the message to have the correct message format, such
as rich-text, HTML, or plain text, for each recipient.
Content conversion is also required for MAPI messages to Exchange recipients inside the
local Exchange organization, if the messages are transferred over SMTP. Servers running
Exchange Server 2003 in the local routing group always communicate with each other over
SMTP. Servers running Exchange Server 2003 in different routing groups communicate over
SMTP when the Routing Group connector or SMTP connectors are deployed. To support
SMTP, the MAPI format must be converted to RFC 822 format so that the message can be
transferred.
266
Note:
Content conversion is done on the server where the user submits the message. This
allows the message to move from server to server by means of SMTP, without further
conversion. Content conversion is performed for MAPI messages only.
IMAIL
The message conversion process in Exchange Server 2003 is called IMAIL. IMAIL is an
internal component of the Exchange store. The Exchange categorizer does not perform the
actual message conversion. The Exchange categorizer creates copies of the message using
the Exchange store driver only and sets some properties in the message transfer envelope of
each copy. The store driver then uses these property settings as parameters to specify which
format to request when requesting the RFC 822 content from the Exchange store. The
Exchange store uses IMAIL to convert the MAPI message to RFC 822 format, using the
requested formatting parameters. When producing the RFC 822 content of a message, IMAIL
produces a rendering of the MAPI message only. The actual message in the Exchange store
is not changed. Changes to the rendered RFC 822 content are not dynamically correlated
back to the MAPI message that was used to produce the RFC 822 content.
TNEF
Exchange Server 2003 uses transport neutral encapsulation format (TNEF) to convert MAPI
messages to RFC 822 format. TNEF appears on a message as a MIME attachment of type
application/ms-tnef. The attachment is called Winmail.dat. It contains the full message
content and any attached files. Only MAPI clients, such as Outlook, are able to decode the
Winmail.dat attachment. Non-MAPI clients are unable to decode TNEF and might show
Winmail.dat as a typical, but useless file.
Note:
Recipients with mailboxes on an Exchange server, who use Internet clients to access
their messages, are not considered non-MAPI recipients. This is because the
Exchange store that hosts the mailboxes can produce the necessary RFC 822
content in non-MAPI format when users download MAPI messages from their
Inboxes using a POP3 or an IMAP4 client.
There are several possible Exchange-to-Exchange transfer scenarios that require MAPI to
RFC 822 conversion:
• Recipient is on an Exchange server in the same routing group Exchange

Server 2003 renders MAPI messages into Summary-TNEF (S/TNEF) format, a
special kind of transport-neutral encapsulation format (TNEF), which has no plain text
part and is rendered in eight-bit binary format. S/TNEF messages consist only of
Winmail.dat.
267
Note:
Within a routing group, Exchange Server 2003 always uses S/TNEF, because in
all remote delivery cases, the message is guaranteed to take either an SMTP
hop directly to a server running Exchange 2000 Server or Exchange Server 2003
or go to the Exchange MTA. Exchange 2000 Server and Exchange Server 2003
support binary MIME. On the other hand, if the message is passed to the
Exchange MTA for delivery to a server running Exchange Server 5.5 through
RPCs, message conversion is not required, because the RFC 822 format is not
used.
• Recipient is on an Exchange server in another routing group and the

Exchange organization is operating in native mode Exchange Server 2003
renders MAPI messages into Summary-TNEF (S/TNEF) format, because in native
mode an Exchange organization can include only servers running Exchange 2000
Server and Exchange Server 2003 that support binary MIME.
• Recipient is on an Exchange server in another routing group and the

Exchange organization is operating in mixed mode In mixed mode, it is possible
to use the Internet Mail Service of Exchange Server 5.5 as an SMTP connector, but
Internet Mail Service does not support binary MIME. Because the RFC 822
representation of S/TNEF that IMAIL generates is binary MIME, Internet Mail Service
is unable to transfer S/TNEF messages. Because the Exchange categorizer cannot
detect beforehand what route a message will take, the categorizer does not convert
the message to S/TNEF for a recipient that is on a server outside the local routing
group in mixed mode. To accommodate a potential Internet Mail Service instance in
the transfer path, the Exchange categorizer converts the message to a plain text part
and an attachment in legacy TNEF, which is seven-bit MIME that Internet Mail
Service can transfer.
• Recipient is a MAPI recipient outside the local Exchange

organization Users and administrators can enable the transfer of TNEF across the
boundaries of the local Exchange organization for recipients in external messaging
environments who use Outlook. Because the recipient is not in the local Exchange
organization, the Exchange categorizer cannot determine if all SMTP hosts involved
in the message transfer support binary MIME. Correspondingly, the Exchange
categorizer converts the message to a plain text part and an attachment in legacy
TNEF.
Note:
Non-MAPI recipients typically prefer to receive a message in plain text or HTML
without TNEF, because their clients cannot decode the Winmail.dat file that
includes the message and all attachments. TNEF encapsulation prevents non-
MAPI clients from accessing attachments. Non-Microsoft tools, such as EPOC
WMDecode for Windows, might be able to extract attachments from Winmail.dat
files.
268
• MAPI messages sent to public folders Messages sent to public folders are
always relayed in legacy TNEF format. You can read more about public folder
message handling later in this section.
• MAPI messages sent to an expansion server over SMTP If a message

contains a distribution list with an explicit expansion server that is not the local server,
the message is forwarded to the expansion server in legacy TNEF format (if SMTP is
used for message transfer). In this case, a property is transmitted in the message
transfer envelope through XEXCH50 that notifies the expansion server of the time the
message was originally received through the Exchange store driver. After the
categorizer on the expansion server expands the distribution list, it must apply the
effective RFC 822 message formats to the individual recipients. The categorizer uses
the Exchange store driver to copy the message to the Exchange store, where IMAIL
reads the TNEF data to construct a MAPI message with the submit time of the
original message. The SMTP transport subsystem can then read the MAPI message
from the store in an RFC 822 format consistent with the recipients' formatting
requirements.
You can control the TNEF format behavior for sending messages by adding the following
registry key. The number nn represents the virtual server instance for this machine.
Location HKey_Local_Machine\Software\Microsoft\Ex
change\StoreDriver\Exchange\nn\EnableTne
f
Value Disabled
Type REG_DWORD
Value Data 0x0
Description A value of 0x0 disables TNEF, and

messages are generated without using
TNEF. A value of 0x1 will generate a
message using legacy TNEF when S/TNEF
would ordinarily be generated. A value
of 0x2 has no effect, as that is the
default behavior.
Public Folder Message Handling

Public folders can be mail-enabled so that users can send messages to them. However,
unlike mailbox-enabled user accounts, which can have their mailboxes only on one
designated Exchange server in an organization, public folders can be replicated between
multiple servers and can be missing from other servers that have a public folder store
269
associated with the public folder's top-level hierarchy. Therefore, it is difficult to determine the
delivery location for messages sent to the public folder.
To perform message delivery, the Exchange categorizer must deliver the message to a public
folder store that knows where the replicas of the public folder reside. This information is
contained in the Exchange store in the PTagReplicaList attribute. Only the Exchange store
with a public folder store that is associated with the public folder's top-level hierarchy has this
PTagReplicaList information.
To find a public folder store that is associated with the public folder's top-level hierarchy, the
Exchange categorizer reads the public folder's homeMDB attribute. The homeMDB attribute
contains the distinguished name (DN) of the top-level hierarchy object in Active Directory.
This object, in turn, has an msExchOwningPFTreeBL attribute that lists the public folder
stores associated with the top-level hierarchy. The Exchange categorizer then chooses a
public folder store from that list and directs the message to that public folder store. The public
folder store determines the PTagReplicaList entry for that folder, readdresses the message to
a public folder store that holds a replica of the public folder, and resubmits the message. The
message again goes through the advanced queuing engine, including categorization. When
the Exchange categorizer locates the updated folder location in the public folder store, it sets
the updated folder location as the destination of the message and re-routes the message.
The Exchange categorizer uses the following prioritization, from top to bottom, to select the
public folder store for the message:
1. Public folder stores on the local server running Exchange Server have the
highest priority
2. Public folder stores in the local routing group
3. Public folder stores in the local administrative group
4. Public folder stores in the local Exchange organization
5. Public folder stores on servers running Exchange Server 5.5
Note:
If multiple public folder stores exist in the local routing group, the Exchange
categorizer chooses the first from the list.
Categorizer Performance Tuning

As mentioned in the section "Exchange Categorizer" earlier in this topic, the Exchange
categorizer determines the list of global catalog servers to use for LDAP lookups from
DSAccess. DSAccess determines this list dynamically, based on the Active Directory site
topology or statically, if you hard coded global catalog servers in a DSAccess profile in the
registry, as explained in Exchange Server 2003 and Active Directory.
270
By default, DSAccess determines the list of global catalog servers dynamically, which
enables global catalog servers to be excluded from the list, if they become unavailable for
any reason. The connection retry period for an unavailable global catalog server is five
minutes. By default, DSAccess recalculates its list at least every 15 minutes. The Exchange
categorizer calls DSAccess once every hour to update the list of global catalog servers.
The Exchange categorizer also updates the list of global catalog servers if there are more
than 100 connection failures per global catalog server. A global catalog server might be down
for maintenance or other reasons, or there might be a network communication problem
causing an LDAP connection to fail. You can use the following registry parameters to specify
the timeout values that the categorizer uses to classify LDAP connections as not operational.
Caution:
own risk.
Set\Services\SMTPSVC\Parameters
Value LdapResultTimeout
Type REG_DWORD
Value Data 0x79
Description This is the maximum time in seconds that

the Exchange categorizer waits for new
results from the global catalog server for
pending searches. If the timeout expires
and the Exchange categorizer did not
receive any new results, the searches
pending on the LDAP connection fail with
the status code LDAP_SERVER_DOWN. The
Exchange categorizer can then reissue
these searches on new LDAP connections.
The default timeout period is two minutes
and one second (121 seconds).
Value LdapRequestTimeLimit
271
Type REG_DWORD
Value Data 0x258
Description This is the maximum time in seconds that

the categorizer allows a single LDAP
request to be pending. Searches that take
longer than the specified time limit fail with
the status code LDAP_TIMELIMIT_EXCEEDED,
even if the global catalog server responds
with results for that search. The default is
ten minutes (600 seconds).
Value MaxConnectionRetries
Type REG_DWORD
Value Data 0x14
Description This is the maximum number of times a

single categorization can have its LDAP
connection fail and can reissue its searches
on a new connection until that
categorization fails and is placed in a retry
queue. The default is 20 failures.
If a categorization fails because MaxConnectionRetries is exceeded, the categorizer places

the affected message back in the pre-categorization queue and informs the advanced
queuing engine that the categorization might be successful in a later attempt. By default, the
advanced queuing engine then retries the categorization after one hour. You can adjust this
time period using the following registry parameter.
Value CatRetryMinutes
Type REG_DWORD
Value Data 0x3C

272
Description This is the number of minutes that the

categorizer waits before retrying a
categorization for a message that failed with
an error that might be resolved through a
retry, such as an LDAP connection error.
The default is one hour (60 minutes).
Global Catalog Load Balancing

If multiple global catalog servers are available to a server running Exchange Server 2003, the
Exchange categorizer can load balance LDAP searches between all of these global catalogs.
By default, the Exchange categorizer starts load balancing LDAP searches when more than
16 LDAP searches are pending on one global catalog server. The Exchange categorizer
chooses global catalog servers based on cost values. The cost values are determined by the
following characteristics:
• Number of existing LDAP connections The Exchange categorizer prefers

existing LDAP connections over new connections, because it is more efficient to use
a connection that is already established than to establish a new connection to a
global catalog server. Establishing connections imposes processing overhead.
By default, the base categorizer can open up to eight (depending on the workload)
concurrent LDAP connections per global catalog server to perform directory lookups. You
can adjust the number of connections using the following registry key.
Value MaxLdapConnections
Type REG_DWORD
Value Data 0x8

273
Description This is the maximum number of LDAP

connections that the components in the
SMTP service can open to a global catalog
server. The default is eight connections.
Note:
This value applies individually to
each process in the categorizer that
performs LDAP lookups: one
resolves recipients on submitted
messages during categorization
and one checks message
restrictions per recipient. Each of
these processes can have eight
connections, thus the maximum
total is 16 connections to global
catalog servers.
• State of existing LDAP connections The Exchange categorizer prefers

available LDAP connections that have no pending searches.
• Locality to the Exchange server The Exchange categorizer prefers global

catalog servers in the local Active Directory site over global catalog servers in remote
sites. It is assumed that TCP/IP connections in the local site are fast and reliable.
• Number of LDAP pending queries The categorizer prefers idle connections

over connections with pending queries. If all connections have pending queries, the
Exchange categorizer chooses the connection with the least number of pending
queries.
The Exchange categorizer selects the global catalog server with the lowest cost. If multiple
global catalog servers have the same cost value, the categorizer performs load balancing
across all available LDAP connections in a round robin fashion. The Exchange categorizer
selects a connection as follows:
1. The Exchange categorizer iterates through the list of existing LDAP connections
and automatically selects the first connection that has no pending searches.
2. If no LDAP connection exists or is available, the Exchange categorizer

establishes a new connection to the global catalog server.
LDAP Search Batches

The Exchange categorizer can perform lookups asynchronously and in batches of up to 20
recipients. Performing a single Active Directory lookup for multiple recipient objects using an
274
LDAP OR filter can result in a performance gain, even though some extra processing is
required to match the results to the recipients in the message. Batched LDAP searches work
well for individual recipient objects that can be grouped together into a single query to a
global catalog. Most Exchange categorizer operations are in this category, but there are
exceptions.
The categorizer uses non-batched queries in the following situations:
• The categorizer must expand a dynamic distribution group.
• The categorizer must request paged attributes. For example, this is the case for
distribution groups with more than 1,000 members.
Note:
The Exchange categorizer checks with DSAccess to determine if a recipient object is
in the DSAccess cache. For cached objects, directory lookups are not performed.
You can manage the performance of the Exchange categorizer using the following registry
keys. For example, you can increase the maximum number of recipients in a batched search.
However, dramatically increasing this number might actually have a negative impact on
performance, because the overhead for matching results to recipients also increases. In
general, the default values are sufficient for most situations. Therefore, it is not a good idea to
change these values without the assistance of a Microsoft Product Support specialist.
Value MaxSearchBlockSize
Type REG_DWORD
Value Data 0x14
Description This is the "batch limit" or the maximum

number of categorizer searches that can be
submitted together as a single LDAP
search. The default is hexadecimal 0x14 or
decimal 20 categorizer searches.
Value MaxPendingSearches
Type REG_DWORD
Value Data 0x3C

275
Description This is the maximum number of pre-

batched, pending searches per LDAP
connection. The default is hexadecimal
0x3C or decimal 60 pending searches.
Message Re-Categorization
Messages are categorized only once. For messages in the \Queue folder on the file system,
the categorizer uses alternate data streams, a little known NTFS feature, to persist the
MailMsg property stream, which includes message envelope and categorization information.
Alternate data streams enable data storage in hidden files, which are linked to a visible file on
an NTFS partition. When the SMTP service cannot transfer a message immediately and must
retry at a later time, the message is saved and closed. Part of that operation involves saving
the existing MailMsg property stream, so that it can be reloaded and used when the message
transfer is retried. However, if you must categorize a message again (for example, if it is
queued for a destination server that no longer exists) you will notice that categorization is not
performed a second time.
The advanced queuing engine stores messages either as .eml files in the SMTP virtual
server's \Queue directory or as Exchange installable file system (ExIFS) files in the Exchange
store. For .eml files, the categorizer uses two NTFS alternate data streams, named
PROPERTIES and PROPERTIES-LIVE, during the categorization process to persist the
properties of the MailMsg object and categorization information. The PROPERTIES data
stream provides a copy of the original message. The PROPERTIES-LIVE data stream
provides a copy of the current message. The alternate data streams are removed when the
SMTP service moves a message to the \Badmail folder. In this situation, the message is
saved with a .bad file name extension, and the property stream is saved in a separate file
with a matching file name, but with a .bdp file name extension.
Note:
The way that the property stream is saved depends on the store driver that is used.
The NTFS store driver saves property streams using alternate data streams. The
Exchange store driver saves property streams by copying the data to a special binary
MAPI property of the message (if the property stream is small) or to a separate ExIFS
file (if the property stream is large), in which case a link to the ExIFS file is saved in
the binary MAPI property.
Alternate Data Streams in the \Queue Directory

You can use Notepad to view the alternate data streams for an .eml file in the SMTP virtual
server's \Queue directory. For example, the following command shows the categorization
information for a test message with the file name NTFS_0ec25fe701c4120a00000001.EML:
276
notepad C:\NTFS_0ec25fe701c4120a00000001.EML:PROPERTIES-LIVE. Note that the

period at the end belongs to the command. If you omit it, Notepad will append a .txt filename
extension to PROPERTIES-LIVE, but PROPERTIES-LIVE.txt is not the name of the alternate
data stream. The first part of the file name points to the parent file of the stream. The second
part is the actual stream name.
The following figure shows sample content from the parent file (on the left), together with
MailMsg property information in the alternate data stream (on the right). Note that the
PROPERTIES-LIVE stream in the top window contains detailed recipient information
obtained for sender and recipient from Active Directory.
A message file with an alternate data stream for categorization information
Note:
If you move an NTFS file with an alternate data stream to a File Allocation Table
(FAT) partition, the alternate data stream is lost, because FAT does not support this
feature. This loss includes categorization information and message transfer
envelope. Later, if you move this file to the pickup directory, the P2 (RFC 822)
recipient list is used to deliver the message, unless x-sender and x-receiver headers
are specified. This list might differ from the P1 (RFC 821) recipient list that was used
277
to send the message originally, so some recipients might receive the message twice,
Bcc'ed recipients might not receive the message at all, or unintended recipients might
receive a copy of the message. These outcomes occur because the original P1
recipient list was lost with the MailMsg property stream, leaving the SMTP service
with no information other than the P2 recipient list. The P2 recipient list, however, is
not designed to maintain a list of recipients for the purpose of transport and delivery.
Forcing Re-Categorization
The previous discussion demonstrates that it is not a good idea to move files to a FAT
partition to drop the MailMsg property stream, thus forcing the transport subsystem to re-
categorize a message.
You might have to force re-categorization of a message in the following situations:
• Metabase corruption If the Internet Information Services (IIS) metabase is

corrupt or replaced with a non-Exchange version, messages might be categorized by
the wrong categorizer version. To categorize the messages using the Exchange
categorizer (perhaps after reinstalling Exchange Server 2003), you must re-
categorize the messages.
• Incorrect expansion server If you change the expansion server for a

distribution list, the wrong distribution list expansion server might be stamped on the
message object until the distribution list changes are replicated across
Active Directory. If this occurs, the message is sent to the incorrect expansion server.
For example, if the expansion server is removed from the network and messages are
already categorized on the local server, you must re-categorize the messages to
send them to the correct expansion server.
• Incorrect back-end server A categorization issue might also be caused if you

restore mailboxes on an Exchange server other than the original server in the
organization. For example, you might decide to restore mailboxes on a different
server if the hardware of a mailbox server fails. Any existing messages in queues on
other servers running Exchange Server (such as front-end servers) might not be
delivered, because the advanced queuing engine attempts delivery to the non-
existing server. Unless you re-categorize the messages, the previous server's FQDN
is contained in the message transfer envelope.
In these situations, you must re-categorize the messages. However, server restarts do not
affect alternate data streams. For this reason, restating the server running Exchange Server
does not result in the re-categorization of messages. To trigger a re-categorization without
moving files to a FAT partition, you must reset the message status using the following registry
key:
278
Caution:
own risk.
Set\Services\SMTPSVC\Queuing\
Value ResetMessageStatus
Type REG_DWORD
Value Data 0x1
Description This parameter forces re-categorization of

all messages on enumeration. If this
parameter does not exist, the default is no
re-categorization (0x0).
For changes to take effect, you must stop

and restart the SMTP service. After the
SMTP service is restarted, the categorizer
enumerates and reprocesses all previously
queued messages. When the messages
leave the \Queue folder, delete the
ResetMessageStatus key again. You can
then restart the SMTP service to resume
normal operation.
SMTP Service Store Drivers

The advanced queuing engine passes a MailMsg object (an in-memory message object that
allows for fast processing) from sink to sink. The MailMsg object is made up of a message
transfer envelope and a pointer to the actual physical message, if the message resides in the
\Queue directory on NTFS. If the message resides in the Exchange store, the pointer refers
to the RFC 822 content of the message, which is in a temporary file in the streaming
database. Note that event sinks do not work with MAPI messages directly, and any changes
to a MAPI message during message processing in the transport subsystem are not persisted.
Components, such as the categorizer, use the message pointer primarily to read data from
the message content. The advanced queuing engine also uses the message pointer to
manage the deletion of messages when requested.
279
Note:
The MailMsg property stream is the primary mechanism that transport components
use to make permanent changes to a message. The MailMsg property stream is
persisted across service restarts.
To create the MailMsg object in memory for a received message and to work with the actual
message, the advanced queuing engine uses the following store drivers:
• NTFS Store Driver This store driver is implemented in NTFSDrv.dll, which

resides in the \Windows\System32\Inetsrv folder. This is the base store driver that
comes with Windows Server 2003. It provides persistent storage for a MailMsg
object's content and message transfer envelope properties on the file system.
• Exchange Store Driver This store driver is implemented in Drviis.dll, which
resides in the \Program Files\Exchsrvr\bin folder. Exchange Server 2003 implements
this driver to provide persistent storage for a MailMsg object's content and transfer
envelope properties in the Exchange store. The store driver also handles local
message delivery.
Note:
Changes written to the content of the message are not always permanent. In the
case of messages backed up by the Exchange store driver, changes are lost
because the Exchange store works only with a temporary message copy.
NTFS Store Driver

The SMTP service stores inbound messages on a hard disk drive before it acknowledges the
transfer and disconnects the SMTP connection to the remote host. When messages arrive
through the SMTP protocol engine, the data is written to a \Queue folder on the file system in
the form of an NTFS file (an .eml file). This folder resides in the \Mailroot directory of the
SMTP virtual server. The path to the \Mailroot directory of the default SMTP virtual server is:
\Program Files\Exchsrvr\Mailroot\Vsi 1. When you create additional SMTP virtual servers in
Exchange System Manager, additional \Vsi x folder structures are created in the \Mailroot
directory, according to the numeral of the SMTP virtual server. All \Vsi x directories are
located under \Program Files\Exchsrvr\Mailroot and are named sequentially (that is, \Vsi 1,
\Vsi 2, and so forth).
Note:
The Exchange Server 2003 Setup program moves the \Mailroot directory of the
SMTP service from \Inetpub\Mailroot to \Program Files\Exchsrvr\Mailroot. The
previous folder structure is not deleted. However, any messages in the former
\Pickup and \Queue folders are not delivered. To send these messages, you must
manually move them to the current \Pickup folder of the SMTP virtual server.
Each \Vsx folder has three or four subfolders for the following purposes:
280
• \Badmail This folder is used to save undeliverable messages. An undeliverable

message prompts the advanced queuing engine to return the message to the sender
together with an NDR. If the NDR cannot be delivered, the message is saved in three
separate files in the \Badmail folder.
• \Pickup This folder provides an alternative method to send e-mail messages.

You can place messages in the form of text files, formatted according to RFC 822, in
this folder for delivery. The Inetinfo process uses a thread from ATQ to monitor the
\Pickup directory of each SMTP virtual server. This thread obtains any messages
from the \Pickup folder immediately, creates a new file in the \Queue directory, and
then parses the content from the file in the \Pickup directory and writes the data to
the file in the \Queue directory. Note that the content might be modified during this
process. For example, "x-sender" and "x-receiver" headers are not copied to the
content written to the file in the \Queue directory.
The following is an example of an Internet text message with extended header

information for recipients and sender. The "x-receiver" header identifies a single recipient.
If you want to include multiple recipients, add an "x-receiver" header for each recipient.
The header must appear first in the text file, with the "x-sender" header listed first.
According to RFC 822, there must be an empty line between the header information and
the body of the message.
The file name of the message item is not important. The SMTP service uses its own logic
to name the message file in the \Queue directory and append an .eml file name
extension, for example NTFS_7224ae2001c4125c0000001b.eml.
x-sender: Ted@contoso.com
x-receiver: Birgit@fabrikam.com
From: Ted@contoso.com
To: Birgit@fabrikam.com
Subject: RFC 822 Pickup Message
This message is passed to the SMTP service through the \Pickup directory.
Note:
You should create the text messages in another folder on the file system and
then move the messages to the \Pickup folder. To avoid conflicts with the
monitoring SMTP service, do not create the files directly in the \Pickup folder.
• \Queue This folder holds all messages received through SMTP that are
currently waiting for transfer to a remote destination through SMTP. However,
messages received through the Exchange store are not in this directory during
processing in the SMTP transport subsystem. Messages might accumulate in this
folder if a connection is busy or currently unavailable.
281
Note:
The advanced queuing engine attempts to resend messages in the \Queue folder
at designated intervals. You can configure these intervals in Exchange System
Manager, in the SMTP virtual server properties, on the Deliver tab. However, the
content of the \Queue folder is not scanned at intervals. The content of the
\Queue folder is scanned only when you start a service or when you restart an
SMTP virtual server.
• \Filter By default, this folder is not present. It is created automatically when the
first message is filtered, after you enable message filtering for a particular virtual
server. To enable message filtering, from Exchange System Manager, select the
SMTP virtual server properties, select the General tab, and then click Advanced.
Note:
In addition, there is a \Windows\NTDS\Drop folder that the SMTP service uses on
domain controllers to deliver inter-site directory replication messages to Active
Directory. The \Drop folder is not used to deliver Exchange messages.
Relocating the \Mailroot Directory

In Exchange Server 2003, Exchange System Manager enables you to move the \Badmail and
the \Queue folders to another location in the file system (in the properties of the SMTP virtual
server, from the Messages tab). The \Badmail and the \Queue folders are the most important
folders for Exchange message handling, because they are the main folders that the SMTP
service uses. You can also move the \Pickup folder by setting the
msExchSmtpPickupDirectory for the SMTP virtual server object in Active Directory using
ADSI Edit (AdsiEdit.msc). The metabase update service transfers the configuration settings
to the IIS metabase, as explained earlier in this section.
Do not place the \Mailroot directory on a FAT partition, because FAT partitions do not support
alternate data streams to a file object, and they have other restrictions. For example, FAT16
partitions support a maximum of 65,535 files. This can be a problem on a busy bridgehead
server. If a queue begins to fill, it is possible to deplete entries to create new files. However,
this process is complicated by the fact that each message requires three files. Because
alternate data streams are unavailable on a FAT partition, the NTFS store driver must create
three different files for each message, instead of one file with two alternate data streams. FAT
does not perform well on large volumes, because it provides minimal fault tolerance and no
recoverability after an unexpected system halt. A positive performance impact may occur if
you place the \Mailroot directory on a high-performance disk subsystem, such as a redundant
array of independent disks (RAID). A RAID 0+1 with eight to ten disks is a good start for high-
volume message delivery. A RAID controller with a cache larger than 64 megabytes (MB) also
helps performance.
282
Note:
Every message that is processed by the SMTP protocol engine is committed to disk
and then read to a MailMsg object.
Exchange Store Driver

The Exchange store driver solves an interesting problem in the Exchange Server 2003
transport architecture. The threads of the advanced queuing engine run in the Inetinfo
process, but not all messages are received through the SMTP protocol engine. As illustrated
in the following figure and discussed in Message Routing Architecture, messages from MAPI
clients, such as Outlook, and from the Exchange MTA, are passed to the SMTP transport
subsystem through the Microsoft Exchange Information Store service. Because they are not
received through the SMTP protocol engine, these messages must be passed to the
advanced queuing engine in a different way. The Exchange store driver provides this
alternative mechanism.
In addition, messages might not leave a server running Exchange Server 2003 through the
SMTP protocol engine. A message might be addressed to a recipient with a mailbox in the
local Exchange store, in which case the message is delivered through the Exchange store
driver. Messages for remote recipients that are reached through the Exchange MTA must also
be transferred to the Exchange store, because the Exchange MTA has its outbound message
queue in the Exchange store. The Exchange MTA controls message transfer to servers
running Exchange 5.5 in the local routing group, to remote Exchange MTAs and non-
Exchange X.400 MTAs using an X.400 connector, or to a non-Exchange messaging system
using a MAPI-based messaging connector. For more information about the Exchange MTA,
see X.400 Transport Architecture.
283
Non-SMTP message transfer through the advanced queuing engine
Exchange Store Driver Architecture

It is important to understand that the Exchange store (Store.exe) and IIS Inetinfo process
(Inetinfo.exe) are separate processes in the operating system, as indicated in the following
figure. Separate processes do not share their virtual address spaces directly with each other,
thus data in the virtual address space of Store.exe is not accessible by Inetinfo.exe and vice
versa. To place a MAPI message in the pre-submission queue of the advanced queuing
284
engine, the Exchange store driver must pass a function call from the virtual address space of
Store.exe to the virtual address space of the Inetinfo process. The Exchange store driver
must also pass a function call in the other direction, from the IIS Inetinfo process to the
Exchange store, for local delivery to a recipient mailbox or to the Exchange MTA message
queue.
Architecture of the Exchange store driver
The Exchange Store Driver event sink uses the following three key components to enable
inter-process communication between the Exchange store and Inetinfo. Together these
components form the Exchange store driver.
• Drviis.dll This DLL runs in the Inetinfo process and communicates with the
advanced queuing engine through SMTP StoreDriver COM events.
• Epoxy.dll This DLL implements the Exchange inter-process communications

layer (ExIPC) between IIS and the Exchange store. IIS and the Exchange store use
this communication layer to rapidly exchange data directly across process
boundaries. This is accomplished through shared memory that is loaded by means of
this DLL to the virtual address space of both processes.
The shared-memory model of Epoxy.dll is based on the Shared Memory Circular Queue
(SMQ) model. This means that within the Epoxy.dll layer, individual circular queues of a
fixed size are used for data transfer in either direction. The Epoxy.dll layer includes a
binding facility that enables the store driver to create and connect an arbitrary number of
circular queues between IIS and the Exchange store. This binding facility includes a
central queue manager that monitors the queues that communicate through this process.
This binding facility is also used for queue unbinding and cleanup.
285
Note:
Epoxy.dll uses local remote procedure calls (LRPCs) and a shared-memory heap
to pass data between IIS and the Exchange store. Shared memory works only for
processes running on the same computer. Communication between remote
processes, as in a full remote procedure call (RPC) scenario, is not possible
using Epoxy.dll.
• ExSMTP.dll This DLL runs in the Exchange store process and implements the
protocol stub to communicate with the Exchange store through EPOXY and the
Inetinfo interface of Dviis.dll.
Exchange Installable File System

To minimize the differences between the Exchange store driver and the NTFS store driver
that ships with Windows Server 2003, Exchange Server 2003 implements a Microsoft Win32
file system over the streaming databases (.stm) in the Exchange store. The .stm file of an
Exchange store holds Internet messages in their native format (plain text, MIME, or
UUEncode), while the corresponding .edb file stores messages in MAPI format. A streaming
database has no directory structure in the .stm file. The structures of the Exchange store are
maintained in message tables in the .edb file. You can read more about the architecture and
design of the messaging databases in Exchange Information Store Service Architecture.
The Exchange installable file system is made up of the following main components (shown in
the following figure):
• Exifs.sys This is a kernel-mode driver that the Exchange store driver can use
to read and write items from and to messaging databases. This driver provides the
Win32 file API for the Exchange store.
• Exwin32.dll This is an Exchange store extension that runs in the Store.exe

process and handles requests for file-level operations (such as create, open, rename,
commit, delete, and more) from Exifs.sys. Note that this is a user-mode component
used for Win32 file system operations. The SMTP transport subsystem does not use
the Win32 files.
• Ifsproxy.dll This is a user-mode wrapper around Exwin32.dll to provide a

straightforward interface for Win32 file system calls. Ifsproxy.dll also plays a crucial
role in free-space allocation in the .stm file. ExIFS requests space from ESE when
allocating free space in a database. For example, if the Exchange store driver
creates a new item in the Exchange store to deliver a message locally, ExIFS
requests space from ESE.
ExIFS supports access to files in two different modes.
• Win32 This mode is based on file names and is used to make the Exchange
store visible through the file system similar to a disk drive. The operating system
maps the file namespace \\.\backofficestorage to the Exchange installable file
286
system. This namespace provides access to all private and public databases. The
format is file://./backofficestorage/DomainName, such as
file://./backofficestorage/fabrikam.com.
Note:
Win32 files are used primarily by the HTTP-DAV protocol and EXOLEDB and
CDOEX APIs.
• EA EA is the acronym for extended attributes, which are stored in a special

property of each message. ExIFS copies the extended attributes to an in-memory
structure called the scatter list (SLIST). The scatter list is basically a binary large
object (BLOB) that can be used to open a message item. EA files are for internal use
by the Exchange transport subsystem and are not visible to users through any one of
the documented APIs or protocols. An EA path might look like this:
\;E:\Ted\$705260a-46c4-454d-b0dd-96b9c605364\369b6c05-0256-46c7-fad3-
54ffa867d089-0000001e.
Note:
The components in the SMTP transport subsystem exclusively use extended
attributes to open files in ExIFS.
Integration of IIS and the Exchange store

287
Outbound Message Transfer

The Exchange store driver performs the following steps for an outbound message to pass it
to the pre-submission queue of the advanced queuing engine.
1. When an Outlook user sends a message, the message is placed in the Outbox of
the user's mailbox and marked for delivery.
2. The Exchange store places the message to its internal SendQ folder and calls
the Exchange store driver to transfer the message to IIS.
3. ExSMTP.dll determines the folder identifier (FID) and message identifier (MID) of
the message and reads transport-relevant message properties (such as sender and
recipient addresses, and whether delivery reports are requested). ExSMTP.dll
reformats these properties into a property stream for MailMsg object. ExSMTP.dll
includes the FID and MID of the message, so that Drviis.dll can later fetch the
message content on the side of Inetinfo if necessary. The FID uniquely identifies the
message folder in the Exchange store that contains the message. The MID uniquely
identifies the message.
Note:
The message envelope does not contain the message content. Epoxy.dll is used
to pass message envelope information to Inetinfo. ExIFS.sys is used to marshal
the message content, if necessary. It might never be necessary to access the
content of a message if it is a "local to local" or "local to Exchange MTA" delivery.
The RFC 822 content only needs to be produced for delivery to recipients in
other mailbox stores, for outbound SMTP delivery, or for sinks that request the
content during a transport event.
4. ExSMTP.dll passes a pointer to the shared memory section through a circular

shared-memory queue to Drviis.dll. As indicated in the following figure, the pointer
refers that portion of allocated shared memory that contains the envelope property
stream, folder ID, and message ID.
Inter-process communication using EPOXY

288
Note:
A heap is used for allocating and freeing memory dynamically in addition to what
the operating system allocates for the code and stack during run time.
5. Drviis.dll de-queues the pointer on the Inetinfo side (that is, removes the pointer
from the circular memory queue). The pointer references the shared memory that
holds the envelope property stream, folder ID, and message ID.
6. Drviis.dll uses the memory pointer to read the property stream from shared
memory to a MailMsg object. As mentioned earlier in this section, the MailMsg object
is made up of a message transfer envelope that provides the information required to
route the message to the next hop, plus a pointer to the actual physical message. At
this point, the MailMsg object has the message transfer envelope information
because the properties for the MailMsg object are all in the shared memory block that
was prepared by ExSMTP.dll.
7. Drviis.dll places the MailMsg object in the pre-submission queue. The transport
subsystem can now process the message.
8. The advanced queuing engine triggers its transport and system events to invoke
the base and Exchange categorizers and the routing engine, and other registered
event sinks to process the message. Most transport processing is performed using
the message transfer envelope. The message content is not opened until it is
explicitly required. For example, the Exchange categorizer might have to perform a
content conversion. If the message must be transferred to the next hop over SMTP,
the SMTP protocol engine must access the message content in RFC 822 format.
Note:
For local delivery of MAPI messages (sent and received on the same server
without content conversion), the content is never opened by the SMTP transport
components (if you have not installed any custom event sinks that attempt to
read the RFC 822 message content, such as an archive sink).
9. When the message content is opened by a component in the transport

subsystem by calling the ReadContent or WriteContent method of the MailMsg
object, the message content is accessed as a file similar to a message item in the
\Queue folder on the file system (for example, messages that must be sent over
SMTP). When messages are submitted through the Exchange store, ExIFS files are
used instead of NTFS files.
10. For messages in the Exchange store, MailMsg call Drviis.dll to open an ordinary
file handle. The message content is requested in RFC 822 format. For messages that
are categorized, the property stream might also contain some additional outbound
conversion values that can be used to request a specific format when retrieving the
content.
289
11. As mentioned earlier in this section, Drviis.dll saves a pointer to the physical
message in the MailMsg object. This pointer is made up of the folder ID and message
ID for the message. Drviis.dll uses this pointer and any additional content formatting
parameters to pass a message request packet through Epoxy.dll to Exsmtp.dll inside
the Store.exe process.
12. Exsmtp.dll calls an internal Exchange store method named EcGetMime with the
folder ID and message ID to request the content of the message in RFC 822 format,
specifying any additional parameters that Drviis.dll might have passed.
Note:
You might notice the EcGetMime call in application event log entries with an
event source of MSExchangeTransport and an event category of Exchange Store
Driver. For an example, see Microsoft Knowledge Base article 319682, "XGEN:
The Exchange 2000 Information Store Reports an Event ID327 Warning
Message and Virtual Memory May Be Fragmented."
13. Because the message was submitted through Outlook, the message is not in
RFC 822 format. The message is in MAPI format, stored in the .edb file. Therefore,
the content that Exsmtp.dll is requesting does not exist in the streaming database
(that ExIFS is using) when the message is opened by a transport component or
Internet client.
Note:
Exchange Server 2003 stores messages received from MAPI clients, X.400
connectors, or Exchange Development Kit (EDK)-based connectors in MAPI
format in the .edb database.
14. If the message does not exist in the streaming database, it must be created using
the various properties and tables in the .edb database that describe the message.
Accordingly, the Exchange store uses IMAIL to create a temporary ExIFS file and to
render the message from the database to that file in RFC 822 format, according to
the requested formatting parameters that are passed.
Note:
The Exchange categorizer uses the IMAIL mechanism to apply message formats
to the content, as defined for Internet domains in Exchange System Manager or
as specified by the user per recipient in Outlook. If no formatting parameters are
passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF)
format.
15. In Exchange Server 2003, ExIFS.sys creates a temporary ExIFS file so that a
malfunctioning event sink that attempts to modify the RFC 822 content cannot corrupt
the committed pages in the streaming database. Instead of writing to actual content
pages, the event sink is writing to a copy only.
290
16. Once the temporary ExIFS file is generated, the file handle is passed back to
Exsmtp.dll. Exsmtp.dll calls to ExIFS to retrieve a pointer to the pages that the file
occupies in the streaming database (that is, to the extended attributes which ExIFS
copies to an in-memory structure called a scatter list).
17. Exsmtp.dll copies the scatter list to shared memory and passes the list back to
Drviis.dll through Epoxy.dll.
18. Drviis.dll uses this scatter list to open the ExIFS file in the form of an extended
attributes (EA) file. Now that Drviis.dll has the open ExIFS file handle, it returns the
file handle to MailMsg, which can then process ReadContent or WriteContent
requests to the RFC 822 message content.
19. The SMTP protocol engine can now read the message content and transfer the
data to a remote host or Exchange server through SMTP.
20. After successful message transfer, the advanced queuing engine deletes the
MailMsg object, because it is no longer needed. Accordingly, the advanced queuing
engine calls to the Exchange store driver (drviis.dll) to delete the message. Drviis.dll
creates a request to delete the message in shared memory and transfers the request
through EPOXY to Exsmtp.dll. Then Exsmtp.dll either moves the message from the
sender's Outbox to the Sent Items folder or deletes the message.
Note:
The content is re-rendered every time it is requested. Each time the content is
requested, it is returned in a temporary ExIFS file. As long as that file remains open, it
can be used. After the file is closed, it is automatically discarded, because it is only a
temporary copy of the message. To minimize the number of rendering cycles, the
advanced queuing engine keeps the content file open until the message is
transferred or delivered. The content file is closed only when messages are ready to
be deleted or are scheduled to be retried at a later time. A message might be retried
at a later time either because the remote server is unavailable, or because more than
10,000 content files are open and actively processed in the queue. If more than
10,000 content files are open and actively processed, some files must be closed to
make room for other messages. When a message is opened again at a later time (for
example, because message transfer is retried), the content must be re-rendered. It is
important to understand that IMAIL renders a new temporary ExIFS file when the file
is opened. Any changes to this ExIFS file are lost when the file is closed.
Inbound Message Transfer

The Exchange store driver performs the following steps for inbound messages that must be
delivered to a local recipient or the Exchange MTA.
291
1. A message is placed in the pre-submission queue, either through the SMTP

protocol engine or Exchange store driver, and then categorized and marked for local
delivery.
2. The advanced queuing engine triggers an SMTP StoreDriver event to signal to

the Exchange Store Driver sink that a message must be transferred to the Exchange
store.
3. If the message is received through an SMTP connection or \Pickup folder, the

message still resides in the \Queue folder. Accordingly, Drviis.dll calls CreateFile() to
create a new file in ExIFS and copies the message item to the new file in the
Exchange store.
Note:
If messages are sent from and received in the same mailbox store, the content is
not copied to the store. If messages are sent from and received in different
mailbox stores on the same server, the message is copied using RFC 822
S/TNEF as the intermediate format. No content marshaling from the Exchange
store to the Inetinfo process occurs. The processing is done in the Exchange
store. IMAIL renders the content in S/TNEF format to an ExIFS file at the request
of Exsmtp.dll. The Exchange store uses this ExIFS file to construct a new
message for delivery to the mailbox store that contains the recipient's mailbox.
4. In the SMTP/Pickup case, ExIFS returns the scatter list that indicates the location
of the new item's data in the streaming database.
5. Drviis.dll allocates memory from the shared-memory heap and places the scatter
list into the allocated memory block. A pointer to that portion of allocated shared
memory is then placed in the queue in the direction of the Store.exe process.
6. ExSMTP.dll obtains the pointer from the queue on the Exchange store side. The
pointer references the shared memory that holds the scatter list for the inbound
message.
7. ExSMTP.dll calls into Ifsproxy.dll with the scatter list to receive a file handle back
from ExIFS. To commit the item to the database, a message must be created, so
ExSMTP.dll calls to the Exchange store kernel (Store.exe) through the messaging
database external interface (MDBEIF) to create a message object. ExSMTP.dll then
explicitly passes the file handle of the content to the Exchange store kernel and the
Exchange store kernel passes the file handle to ESE to commit the data when
ExSMTP.dll commits the message object.
Note:
Page checksums are stored in the MAPI-based database file (.edb). The
streaming database file (.stm) does not contain page checksums.
292
8. The Exchange store informs Outlook when a new message arrives and Outlook
lists the message in the Inbox folder.
9. ExSMTP.dll notifies Drviis.dll through EPOXY that delivery is complete, and then
Drviis.dll returns a positive result to the advanced queuing engine. The advanced
queuing engine can then delete the message, as follows:
• Message was received through SMTP or the \Pickup directory There is

an .eml file in the \Queue directory for the message. The advanced queuing
engine calls back to MailMsg to delete the message. Because the MailMsg
object is bound to the NTFS store driver, the call is passed to NTFSDrv.dll,
which deletes the message from the \Queue directory on the file system.
• Message was submitted through the Exchange store driver The

advanced queuing engine calls back to MailMsg to delete the message.
Because the MailMsg object is bound to the Exchange store driver, the call is
passed to Drviis.dll, which queues an EPOXY request to ExSMTP.dll.
ExSMTP.dll then either moves the message from the sender's Outbox to the
Sent Items folder or deletes the message.
Note:
Messages for remote recipients that arrive through \Pickup directory or SMTP
protocol engine do not reach the Exchange store. They remain in the \Queue folder
on the file system until they are successfully transferred to the next hop on route to
their destination. However, the categorizer might use the Exchange store for
messages that are not delivered through the Exchange store driver. The categorizer
might need to generate delivery status notifications, which are created in the
Exchange store.
Transfer Retries
Note that messages that enter the advanced queuing engine through the Exchange store
driver remain in the Exchange store during the categorization and routing process, as well as
during the actual transfer process. The message is not copied to the SMTP virtual server's
\Queue folder. These types of messages also remain in the Exchange store if a connection
failed and must be retried. If a message cannot be transferred immediately, it is moved to a
temporary table. Therefore, the message disappears from the sender's Outbox folder and is
copied to the Sent Items folder (if Outlook is configured to keep a copy of all messages in the
Sent Items folder). The message remains in the temporary table until it is transferred
successfully or expires. You can view these messages in the Failed Message Retry queue
using the Queue Viewer snap-in in Exchange System Manager.
293
SMTP Protocol Extensions

The advanced queuing engine is not the only dispatcher of COM events in the SMTP service.
The SMTP protocol engine is also a main dispatcher of COM events, specifically SMTP
protocol events. The core SMTP protocol engine is responsible for all standard SMTP
communication and handles most of the standard SMTP service extensions (that is, the
Extended Simple Mail Transfer Protocol (ESMTP) standard, as defined in RFC 821 and
RFC 1869). Protocol events can be used to modify the SMTP protocol to add new ESMTP
commands, or even to change the action of existing commands. Exchange Server 2003 uses
these protocol events to implement Exchange-specific extended SMTP commands to
communicate with other Exchange servers in the organization more efficiently than over
standard SMTP.
You can verify that the extended SMTP commands for Exchange Server 2003 are loaded
when you connect to the TCP port of your SMTP virtual server using telnet. As shown in the
following figure, the server response indicates the features that the SMTP virtual server
supports when you submit the EHLO command to initiate an ESMTP connection. The
standard commands are listed when you submit a HELP command.
Standard and extended SMTP commands of Exchange Server 2003
The following table explains the SMTP features that the Exchange-extended SMTP service
supports.
294
SMTP features supported in Exchange Server 2003
SMTP Server Response Comments
8BITMIME Indicates that the local SMTP virtual server

supports eight-bit Multipurpose Internet Mail
Extensions (MIME) messages.
AUTH, AUTH GSSAPI NTLM LOGIN, and Signals that the local SMTP virtual server
AUTH=LOGIN supports the SMTP authentication service
extension. The additional information after
the AUTH key word identifies the supported
authentication mechanisms.
BDAT, CHUNKING An alternative to the DATA command, which

takes two arguments. When an SMTP
virtual server responds to the EHLO
keyword with CHUNKING, the SMTP server
is indicating that it supports the BDAT
command and will accept messages in
chunks.
The first argument indicates the length of

the binary data packet, so that the SMTP
host does not have to continuously scan for
the end of the data. The receiving server
counts the bytes in the message and, when
the message size equals the value sent by
the BDAT command, the server assumes it
received all the message data. The second
argument indicates whether the data packet
is the last packet in the current
transmission. The second argument is
optional.
295
BINARYMIME Indicates that the SMTP virtual server

accepts messages that contains binary
material without transport encoding by
using a BODY parameter with a value of
"BINARYMIME" with the MAIL command.
When the SMTP server accepts a MAIL
command with a BODY parameter of
BINARYMIME, the server agrees to
preserve all bits in each octet passed using
the BDAT command. The BINARYMIME
SMTP extension can only be used with
CHUNKING.
DATA Sent by a remote host to initiate the transfer

of message content.
DSN An ESMTP command that enables delivery

status notifications as defined in Request
for Comments (RFC) 1891.
EHLO Sent by a client to signal the start of an

ESMTP session. The server can identify its
support for ESMTP commands in its
response to EHLO (Figure 6.14).
ENHANCEDSTATUSCODES Indicates that the SMTP server provides

enhanced error status codes. Text part of all
SMTP status responses, other than the
initial greeting and any response to HELO
or EHLO, are prefaced with a status code
as defined in RFC 1893.
ETRN Sent by an SMTP server to request that the

local virtual server send any e-mail
messages that it has in the queue for the
domains indicated in the ETRN command.
HELO Sent by a client to identify itself, usually with

a domain name, and to signal the start of a
standard SMTP session.
HELP Returns a list of SMTP commands that are

supported by the SMTP virtual server in
standard SMTP sessions (as opposed to
ESMTP sessions).
296
MAIL Identifies the start of a message transfer by

identifying the sender of the message; used
in the form MAIL FROM.
PIPELINING Provides the ability to send a stream of

commands without having to wait for a
response after each command.
QUIT Signals the end of a standard or extended

SMTP session.
RCPT Identifies the message recipients; used in

the form RCPT TO.
RSET Nullifies the entire message transaction and

resets the buffer.
SIZE Provides a mechanism by which the SMTP

virtual server can indicate the maximum
supported message size. Compliant servers
must provide size extensions to indicate the
maximum message size that can be
accepted. Remote hosts should not send
messages that are larger than the size
indicated by the server.
STARTTLS Indicates that the SMTP server supports

secure SMTP over Transport Layer Security
(TLS). The SMTP service extension for
secure SMTP over TLS is defined in
RFC 2487.
TURN Allows a remote host and the local host to

switch roles and send mail in the reverse
direction, without establishing a new
connection.
297
VRFY Verifies that a mailbox is available for

message delivery. For example, VRFY TED
verifies that a mailbox for Ted resides on
the local server. By default, this command is
available in Exchange 2003, but does not
verify users. The server will inform the
remote host that, although the user cannot
be verified, messages will be accepted. The
server response has the following format:
252 2.1.5 Cannot VRFY user, but will take
message for <Ted@TailspinToys.com>
XEXCH50 Provides the ability to send extended

message transport envelope properties in
Message Database Encoding Format
(MDBEF) format during an Exchange
Server 2003 server-to-server
communication.
X-EXPS GSSAPI NTLM LOGIN, X- X-EXPS is a command that is proprietary to

EXPS=LOGIN Exchange. It is similar to AUTH, because it
indicates the methods that can be used by
servers running Exchange Server 2003 and
Exchange 2000 Server to authenticate, as
follows:
• GSSAPI A method that stands

for Generic Security Services
Application Programming Interface
and enables authentication through
Kerberos.
• NTLM A method that stands

for Windows NT and LAN Manager
and enables authentication using
the Windows NT
Challenge/Response protocol.
• LOGIN A method that stands

for AUTH LOGIN, a clear text
authentication method using a
base-64-encoded user name and
password.
298
X-LINK2STATE Adds support for link state propagation to

the SMTP service. For details about the link
state algorithm used to propagate link state
information within and between routing
groups, see Message Routing Architecture.
Note:
All Exchange-specific SMTP commands start with "X-" (without the quotation marks).
If these commands are not listed in the EHLO response of your SMTP virtual server,
then the server is running the Windows Server 2003 base version of the SMTP
service. In this case, you must reinstall Exchange Server 2003 and any Service
Packs.
Protocol Event Categories

The SMTP protocol engine triggers protocol events to control the host-to-host
communication. There are three main types of events that can occur in such a
communication over SMTP:
• The SMTP service receives an SMTP command These events occur when a
remote SMTP host or client connects to the local SMTP service and establishes a
session by sending the HELO or EHLO command. Events in this category are SMTP
Protocol OnInboundCommand events on incoming connections.
• The SMTP service receives an SMTP response These events occur when the
local SMTP service receives responses from a remote SMTP host or client to
outbound SMTP commands. Events in this category are SMTP protocol
OnServerResponse events on outbound connections.
• The SMTP service sends an SMTP command These events occur when the
local SMTP service connects to a remote SMTP host and establishes a session to
transfer messages. Events in this category are SMTP protocol OnSessionBegin,
OnMessageStart, OnPerRecipient, OnBeforeData, and OnSessionEnd events on
outbound connections.
The following table summarizes the purpose of each SMTP protocol event.
299
Protocol events in the SMTP service
Event Comments
OnInboundCommand Occurs when an SMTP command is

received by the SMTP protocol service,
which gives an event sink an opportunity to
respond.
OnServerResponse Occurs when the SMTP service receives an

SMTP response to a previously sent SMTP
command.
OnSessionBegin Occurs before the EHLO command is

transmitted.
OnMessageStart Occurs before the MAIL FROM command is

transmitted.
OnPerRecipient Occurs before the RCPT TO command is

transmitted.
OnBeforeData Occurs before the DATA protocol command

is transmitted.
OnSessionEnd Occurs before the QUIT command is

transmitted.
Exchange-Specific SMTP Protocol Extensions

The Exchange Server 2003 Setup program registers Exchange-specific SMTP protocol
extensions for the following SMTP protocol features:
• XEXCH50 This feature is implemented using nine event sinks to support a full
communication between two servers running Exchange Server. The following table
maps the protocol events to their XEXCH50 event sinks. All XEXCH50 sinks are
implemented in peexch50.dll, which resides in the \Program Files\Exchsrvr\bin
directory.
300
Protocol extensions for the XEXCH50 command
Event sink Protocol event Comments
Exchange SMTP Protocol OnBeforeData Notifies the XEXCH50 sink

XEXCH50 Before Data Sink that the DATA protocol
command is about to be
transmitted. The XEXCH50
sink now has the opportunity
to request the SMTP service
to send an XEXCH50
command instead to start an
XEXCH50 communication.
Exchange SMTP Protocol OnInboundCommand Notifies the XEXCH50 sink

XEXCH50 Inbound EHLO that an EHLO command
Sink was received.
Exchange SMTP Protocol OnInboundCommand Implements the XEXCH50

XEXCH50 Inbound command to start an
XEXCH50 Sink XEXCH50 conversation.
Exchange SMTP Protocol OnInboundCommand Implements the MAIL

XEXCH50 Inbound MAIL command in an XEXCH50
Sink conversation.
Exchange SMTP Protocol OnInboundCommand Enables the local SMTP

XEXCH50 Inbound RCPT virtual server to receive
Sink recipient information in an
incoming XEXCH50
communication.
Exchange SMTP Protocol OnPerRecipient Enables the local SMTP

XEXCH50 Per Recipient virtual server to send
Event Sink recipient information in an
outgoing XEXCH50
communication.
301
Exchange SMTP Protocol OnServerResponse Enables the local SMTP

XEXCH50 Ehlo Response virtual server to receive a
Sink response after an EHLO
command is sent to the
remote host. The response
from the remote host might
indicate support for
XEXCH50 communications.
Exchange includes
XEXCH50 in the list of
supported commands that
are returned to the
connecting host
(Figure 6.14).

XEXCH50 Response Sink virtual server to receive a
response to a previously
issued outbound XEXCH50
command. For example, if
the local SMTP service
issued an XEXCH50
command without prior
authentication, the remote
server responds with: 504
Need to authenticate first.
302

XEXCH50 RCPT Response virtual server to receive
Sink status information from the
remote Exchange server for
each recipient indicated with
an outbound RCPT
command. A recipient
address might be incorrectly
formatted or the server
might be unable to relay. If
the recipient information is
correct, the remote SMTP
virtual server reflects the
address back to the local
SMTP service with status
information, such as: 250
2.1.5
administrator@tailspintoys.c
om.
• X-LINK2STATE This feature is implemented using five event sinks. However,

one event sink is used for two separate events, as indicated in the following table. All
X-LINK2STATE event sinks are implemented in Xlsasink.dll in the \Program
Files\Exchsrvr\bin directory.
Protocol extensions for the X-LINK2STATE command
EHLO Inbound Command OnInboundCommand Notifies the X-LINK2STATE

Handler Sink for XLSA event sinks that an incoming
EHLO command was
received.
X-LSA Inbound Command OnInboundCommand Notifies the X-LINK2STATE

Handler Sink event sinks that an incoming
X-LINK2STATE command
was received.
303
X-LSA Sink OnMessageStart, Signals the start (MAIL

OnSessionEnd command) and end (QUIT
command) of an outbound
X-LINK2STATE
communication. Because
the remote SMTP virtual
server is the ultimate
recipient of the Orginfo
packet being transmitted,
there is no need to specify
recipients in an outbound
RCPT command. This event
sink transmits the link state
information.
X-LSA Response Handler OnServerResponse Responds to an incoming X-

Sink LINK2STATE command with
information about how to
transmit the link state
information. An example of a
response is: 200 LAST
CHUNK={00000029} MULTI
(5) ({00000010}
DONE_RESPONSE), which
indicates the last chunk of
data sent by this SMTP
virtual server.
EHLO Response Handler OnServerResponse Responds to an incoming

Sink for X-LSA EHLO command by listing
the X-LINK2STATE
command in the server
response.
• X-EXPS These features are implemented using five event sinks, as listed in the
following table. All protocol security extensions are implemented in Exps.dll in the
\Program Files\Exchsrvr\bin directory.
304
X-EXPS protocol security extensions
Exchange SMTP Protocol OnInboundCommand Signals the end of data

Security EXPS-EOD Sink transfer ( _EOD).
Exchange SMTP Protocol OnInboundCommand Signals an incoming AUTH

Security EXPS-Aux Sink command.
Exchange SMTP Protocol OnInboundCommand, Signals an incoming EHLO

Security EHLO Sink OnServerResponse command and responds to
EHLO by listing the X-EXPS
command in the server
response.
Exchange SMTP Protocol OnInboundCommand, Indicates the start of data

Security Mail Sink OnServerResponse, transfer. This event sink is
OnMessageStart implemented for all relevant
MAIL command scenarios.
This event sink processes
events that signal an
incoming MAIL command,
respond to an incoming
MAIL command, and can
issue an outbound MAIL
command.
Exchange SMTP Protocol OnInboundCommand, Indicates the start of an X-

Security EXPS Sink OnServerResponse, EXPS session. This event
OnSessionStart sink is implemented for all
relevant X-EXPS command
scenarios. This event sink
processes events that signal
an incoming X-EXPS
command, respond to an
incoming X-EXPS
command, and can issue an
outbound X-EXPS
command.
• SPAM Control This feature is implemented using three event sinks that process
sender and recipient information on incoming SMTP connections, as listed in the
following table. The spam control event sinks are implemented in Turflist.dll in the
\Program Files\Exchsrvr\bin directory.
305
Spam control SMTP extensions
RCPT Inbound Command OnInboundCommand Signals an inbound RCPT

Handler Sink command with a recipient
address that should be
checked.
MAIL Inbound Command OnInboundCommand Signals an inbound MAIL

Handler Sink for TURF command with a sender
address that should be
checked.
EOD Inbound Command OnInboundCommand Signals an inbound _EOD

Handler Sink command.
For More Information

For complete information about SMTP, see SMTP Server.
Protocol Logging, Event Logging, and

Message Tracking
The SMTP transport subsystem of Exchange Server 2003 implements the following event
sinks to keep a history of all activities in the SMTP service:
• Exchange SMTP Protocol Logging Sink This event sink is implemented in

Protolog.dll and registered for the protocol OnServerResponse and
OnInboundCommand events to keep track of all inbound SMTP commnads and
server responses. The protocol logging sink is called for the following SMTP
commands: RCPT, QUIT, EHLO, X-EXPS, STARTTLS, TLS, X-LINK2STATE, HELO,
XEXCH50, MAIL, RCPT, QUIT, EHLO, X-EXPS, STARTTLS, TLS, X-LINK2STATE,
HELO, XEXCH50, MAIL.
• SMTP Eventlog Sink This event sink is implemented in Tranmsg.dll and

registered for StoreDriver and OnEventLog system events.
• MsgTrackLog Sink This event sink is implemented in Msgtrack.dll and

registered for the OnMsgTrackLog system event.
306
Protocol Logging
When you keep a history of all SMTP protocol activities, you can prove whether a particular
message left your server, verify whether the SMTP virtual server is performing its work as
expected or is experiencing communication problems, and identify attacks from the Internet.
The following protocol logging can be configured for an SMTP virtual server in Exchange
System Manager, on the General tab, in the virtual server's properties:
• No Logging The event sink does not track SMTP protocol activities.
• Microsoft IIS Log File Format The event sink keeps track of SMTP protocol
activities in a comma-separated plain-text file. This format includes the remote host's
IP address, the host name if specified, the date and time of the request, the status
code, the number of bytes received, the elapsed time of the request, the number of
bytes sent, and the action taken. The items are separated by commas and the list
cannot be customized. You can configure the path to the log files in Exchange
System Manager. The default path to the log file directory is
Windows\System32\LogFiles.
Note:
For most detailed logging in text files, select Microsoft IIS Log File Format.
• NCSA Common Log File Format The event sink keeps track of SMTP protocol
activities in a comma-separated plain-text file. This is a fixed, non-customizable
ASCII format that includes basic information, such as the remote host name, user
name, date, time, command type, status code, and the number of bytes received.
The items are separated by spaces.
• ODBC Logging The event sink keeps track of SMTP protocol activities in an
open database connectivity (ODBC)-compliant database, such as Microsoft Access
or Microsoft SQL Server. For troubleshooting purposes, you might find it sufficient to
log protocol activities in an ASCII text file instead of an ODBC-compliant database.
Note:
IIS includes an SQL template file, which can be run in an SQL database to create
a table that accepts log entries from IIS.
• W3C Extended Log File Format The event sink keeps track of SMTP protocol
activities in a customizable plain-text file. When you choose this format, you can
exclude all those fields from the log file that do not have meaningful information for
SMTP protocol activities, such as user name in anonymous SMTP communications.
This can help to limit log size by omitting unwanted fields. Fields are separated by
spaces.
307
Event Logging
Exchange Server 2003 uses the SMTP Eventlog Sink to record events for internal SMTP
service components in the application event log. An event in this sense is any significant
occurrence in the system that might require administrator attention. Event logs can help you
identify and diagnose the source of current system problems, or help you predict potential
issues. By default, only minimum information is written to the event log. However, you can
increase the amount of information using the diagnostics logging settings available in
Note:
To reduce the amount of information written to the application event log during typical
operation, Exchange Server 2003 might only log a single event hourly for events that
occur multiple times per hour.
For detailed instructions about how to enable diagnostic logging, see How to Enable
Diagnostics Logging for the SMTP Service in Exchange System Manager.
Field Engineering Logging

Logging levels control the amount of data logged in Application Log. The more events logged,
the more transport-related events you can view in the application event log, and the better
your chance of determining the cause of the message flow issue. To acquire the most
detailed information about the SMTP service, you can set the diagnostics logging level for the
internal SMTP service components to Field Engineering to enable the logging of trace level
events. Field Engineering is not exposed in Exchange System Manager and can only be set
using Registry Editor.
For detailed instructions about how to set the diagnostics logging level for
MSExchangeTransport categories to Field Engineering, see How to Set the Diagnostics
Logging Level for MSExchangeTransport Categories to Field Engineering.
For more information about Field Engineering logging, see Microsoft Knowledge Base article
262308, "XCON: How to Generate Application Log Events for Non-Delivery Report Failures."
Message Tracking
Message tracking is a feature that you can use to track messages across an Exchange
organization. You can track all types of messages, including system messages and regular e-
mail messages that are going to or coming from a non-Exchange messaging system. An
example of system messages are public folder replication messages that the Exchange
stores on multiple servers exchange with each other to keep public folder instances on
separate servers synchronized. You can use Message Tracking Center to locate messages
308
that failed to arrive in your users' mailboxes, such as messages that are stuck in a
connector's message queue.
By default, message tracking is not enabled. You must enable this feature on each server for
which you want to track messages. When enabled, Exchange Server 2003 uses
MsgTrackLog Sink in the SMTP service to add tracking information about messages routed
through the server to the message tracking logs. To enable message tracking for multiple
servers, you can use a server policy.
For detailed instructions about how to enable message tracking, see How to Enable Message
Tracking in Exchange System Manager. You can also configure how Exchange Server 2003
maintains message tracking log files. For example, you can prevent the removal of log files or
modify the length of time the log files are kept. The default period that tracking logs are kept
is seven days. For more information about how to use message tracking, see Microsoft
Knowledge Base article 262162, "XADM: Using the Message Tracking Center to Track a
Message."
Note:
Message tracking logs can grow quickly on bridgehead servers that process many
inbound and outbound messages. Make sure that you have adequate disk space for
tracking log files.
How to Enable Diagnostics Logging for the

SMTP Service in Exchange System
Manager
This procedure explains how to enable diagnostics logging for the SMTP service in Exchange
System manager. You would execute this procedure if you wanted to increase the amount of
information being written to the system event log.
Before You Begin

Setting the diagnostics logging level to Maximum can cause many events to be written to the
application event log. As a best practice, set the size of the application and system event log
to 30 MB, and enable the option to overwrite events as needed. Remember to reapply the
default setting of None after you solve the problem.
309
Procedure
Enable diagnostics logging for the SMTP service in Exchange System Manager
1. Display the properties of the Exchange Server object that hosts the SMTP
virtual servers.
2. Select the Diagnostics Logging tab.
3. Under Services, select MSExchangeTransport.
4. Under Categories, select all the categories that the SMTP service provides,
including Routing Engine/Service, Categorizer, Queuing Engine, Exchange
Store Driver, NTFS Store Driver, SMTP Protocol, and Connection Manager.
5. Under Logging Level, select the appropriate logging level. In a

troubleshooting situation, it is appropriate to increase the level of event logging
for the MSExchangeTransport services to Maximum to obtain the most detailed
information.
How to Set the Diagnostics Logging Level

for MSExchangeTransport Categories to
Field Engineering
This procedure explains how to set the diagnostics logging level for MSExchangeTransport
categories to Field Engineering. You would execute this procedure to enable the logging of
trace level events in your SMTP service, to help determine the cause of a message flow
issue.
Before You Begin

• Field Engineering degrades server performance. It should only to be used under

the guidance of Microsoft Product Support Services when troubleshooting complex
transport issues.
• This topic contains information about editing the registry.
Caution:
310
any valuable data.
Procedure
Set the diagnostics logging level for MSExchangeTransport categories to Field
Engineering
1. Start Registry Editor, and open the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Diag
nostics.
2. Double-click the entries for the individual MSExchangeTransport categories,

one after another, and set the value to 0x7. For example, double-click the 2
Categorizer entry in the right pane, and then change the value to 0x7.
3. Restart the SMTP service. Services typically do not have to be restarted in

order for the change to take effect. However, when you edit the registry manually,
you might have to perform this step.

For more information about Field Engineering logging, see Microsoft Knowledge Base article
262308, "XCON: How to Generate Application Log Events for Non-Delivery Report Failures."
How to Enable Message Tracking in

This topic describes how to enable message tracking in Exchange System Manager. You
would use this feature to track all types of messages, including system messages and regular
e-mail messages that are going to or coming from a non-Exchange messaging system,
across your Exchange organization. You can use Message Tracking Center to locate
messages that failed to arrive in your users' mailboxes, such as messages that are stuck in a
connector's message queue.
Before You Begin

311
By default, message tracking is not enabled. You must enable this feature on each server for
which you want to track messages. To enable message tracking for multiple servers, you can
use a server policy.
Note:
Message tracking logs can grow quickly on bridgehead servers that process many
inbound and outbound messages. Make sure that you have adequate disk space for
tracking log files.
Procedure
Enable message tracking
1. Start Exchange System Manager and display the properties of the server on
which you want to enable message tracking.
2. On the General tab, select the Enable message tracking check box.
3. To track the subject line for each message, in addition to envelope

information, such as To, From, and Date Sent, select the Enable subject
logging and display check box.
Reference
For more information about how to use message tracking, see Microsoft Knowledge Base
article 262162, "XADM: Using the Message Tracking Center to Track a Message."
X.400 Transport Architecture

Microsoft Exchange Server 2003 uses Simple Mail Transfer Protocol (SMTP) for native
message transfer. However, the core components of Exchange Server 2003 include a
message transfer agent (MTA) that is also compliant with the X.400 recommendations of the
1988 conformance year. Therefore, you can use X.400 connectors to build the messaging
backbone of your Exchange organization or to connect to an external X.400 messaging
system. By choosing to use X.400 connectors, rather than SMTP connectors, you add an
extra layer of security. This occurs because the X.400 standard requires MTAs to authenticate
themselves before the MTAs can transmit messages. Note, however, that X.400 MTAs and
X.400 connectors are more difficult to maintain than SMTP connectors. For example, X.400
e-mail addresses are not user-friendly because of their numerous attributes. X.400 is a
complex standard that defines the architecture of a message handling system (MHS), based
on the following recommendations: X.200, X.217, X.218, X.227, X.228, X.402, X.411, X.413,
X.419, X.420, X.435, X.680, X.690, X.880, X.881, and X.882.
312
The X.400 standard was originally developed in the 1980s by telecom companies, under the
umbrella of Consultative Committee for International Telephone and Telegraph (CCITT),
which later became the Telecommunications Standardization Sector of the International
Telecommunication Union (ITU-T). ITU-T publishes updated X.400 recommendations every
four years. Each update introduces new features but remains compatible with previous
versions. The first official X.400 recommendation was published in 1984 and is referred to as
the Red Book because of the color of its cover. The 1984 X.400 recommendation had several
weaknesses in the area of message handling. The 1988 X.400 recommendation introduces
additional X.400 message bodyparts and envelope properties. Object identifiers describe
message attachments precisely, so that attachment names and other object properties are
preserved. The 1988 X.400 standard is referred to as the Blue Book.
Note:
The ITU-T uses the letters from the English alphabet to categorize their standards:
The "X" in X.400 indicates that the standard is for data networks and open system
communications. For details about "X" standards, see the ITU-T Web site
(http://www.itu.int/).
• Exchange MTA in the Exchange Server 2003 architecture This section

explains how Exchange MTA integrates with other Exchange Server 2003
components and provides a general overview of message transfer through X.400 or
MAPI-based gateway connectors.
• X.400 connectors and transport stacks X.400 message transfer is governed

by protocols that determine how MTAs communicate with each other. X.400
connectors and transport stacks define these communication parameters for
Exchange MTA. A clear understanding of these protocols and parameters is helpful
when configuring connectors and transport stacks. You must understand X.400
communication prerequisites to troubleshoot X.400 connectivity problems.
• Connecting routing groups using X.400 connectors When Exchange MTAs

communicate with each other through X.400 connectors, they do not necessarily
conform to all aspects of X.400. Specifically, Exchange MTAs support message
formats that are not defined in X.400. They exchange link state information so that all
servers running Exchange Server 2003 in an organization can perform dynamic
message routing, as explained in Message Routing Architecture.
• Exchange MTA in a mixed-mode organizationIf you are running a mixed-mode

organization, you must understand the various tasks that the Exchange MTA must
perform to support seamless integration of Exchange Server 2003 with Exchange
Server 5.5.
This section assumes that you are familiar with the design of message routing topologies and
the configuration of X.400 connectors. For more information on X.400 connector
configuration, see the Exchange Server 2003 Administration Guide.
313
Exchange MTA in Exchange Server 2003

Architecture
The Exchange MTA is a core component of Exchange Server 2003 and is responsible for all
non-SMTP message transfer. This includes message transfer to external X.400 messaging
systems and Exchange servers connected through X.400 connectors. Message transfer to
non-Exchange messaging systems, such as Lotus Notes and Domino or Microsoft Exchange
Connector for Novell GroupWise, is controlled by the Exchange MTA through MAPI-based
connectors, such as Microsoft Exchange Connector for Lotus Notes or Microsoft Exchange
Connector for Novell GroupWise. Exchange MTA is also responsible for remote procedure
call (RPC)-based communication with Exchange Server 5.5. It is best to implement Exchange
MTA on all servers running Exchange Server 2003.
Exchange MTA Communication Partners

The Exchange MTA is implemented in a Microsoft Windows service named Microsoft
Exchange MTA Stacks. When you display the properties of the Microsoft Exchange MTA
Stacks service in the Services tool and click the Dependencies tab, you find that the
Microsoft Exchange MTA Stacks service depends on System Attendant. System Attendant
hosts the Directory Service Access (DSAccess) component that the MTA uses to obtain
recipient and configuration information from Active Directory. However, System Attendant is
not the only dependency, as illustrated in the following figure.
314
MTA communication partners
The Exchange MTA communicates with the following components:
• Active Directory Communication with Active Directory is required because the

MTA configuration object and X.400 connector objects reside in the configuration
directory partition of Active Directory. The Exchange MTA cannot start if
Active Directory is inaccessible.
• Registry database Not all MTA configuration settings are maintained in

Active Directory. Important settings for the Microsoft Exchange MTA Stacks service
are also stored in the server's registry in the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMT
A. This section explains numerous settings that you can find under the Parameters
key. By configuring registry parameters manually using Registry Editor, you can fine-
tune the MTA performance.
Caution:
Using Registry Editor incorrectly can cause serious problems that may require
you to reinstall your operating system. Microsoft cannot guarantee that problems
resulting from the incorrect use of Registry Editor can be solved. Use Registry
Editor at your own risk.
315
• SMTP service In Exchange Server 2003, the Exchange MTA does not perform
message routing. Message routing is the task of the routing engine, which is part of
the SMTP service. The Exchange MTA communicates with the routing engine
through Mtaroute.dll to make its routing decisions.
Note that the communication with the SMTP service is bi-directional. The MTA
communicates with the SMTP service for message routing purposes. The SMTP service
initiates communication when the routing topology changes, to inform the MTA that all
messages must be rerouted. For more information about the interaction between the MTA
and the SMTP service, see Connecting Routing Groups Using X.400 Connectors.
• Exchange store As illustrated in the following figure, the SMTP service passes
outbound messages to the Exchange MTA through the MTA's message queue in the
Exchange store. The Exchange MTA also passes inbound messages to the SMTP
service through the Exchange store. Communication with the Exchange store is
required if messages must be transferred over MAPI-based messaging connectors
for which the Exchange MTA is responsible. MAPI-based messaging connectors,
similar to the SMTP service, maintain message queues in the Exchange store, as
explained in Gateway Messaging Connectors Architecture.
MTA communication through the Exchange store

316
To communicate with the Exchange store, the MTA uses an internal API named XAPI,
which is a wrapper around MAPI. To start the Microsoft Exchange MTA Stacks service
successfully, the Exchange store must have at least one mailbox store to host the
message queues. You can read more about outbound and inbound message handling
later in this section.
Note:
If your bridgehead server running Exchange Server 2003 hosts many X.400
connectors or connects to non-Exchange messaging systems, such as Lotus
Notes and Novell GroupWise, you should consider placing the transaction logs
and database files of the Exchange store on separate disks, even if the
Exchange store does not contain user mailboxes. By spreading the database
files across multiple physical drives, you can improve system performance.
• File system The Exchange MTA uses two important directories on the file
system. These directories are named the MTA database directory and the MTA run
directory. The database directory contains queue files and messages during transfer
in the form of .dat files. This collection of .dat files is named the MTA database. The
run directory contains template files (named run files). Run files determine how the
MTA formats data using Abstract Syntax Notation One (ASN.1). By default, both the
database directory and run directory point to the same physical directory on the file
system. As indicated in Figure 7.2, this is the \Program Files\Exchsrvr\Mtadata
directory. It is best to split the database and the run directory, as explained later in
this section.
Note:
The run directory does not contain the actual executable file (Emsmta.exe) and
dynamic link libraries (DLLs) of the Microsoft Exchange MTA Stacks service.
Emsmta.exe and DLLs, such as Mtaroute.dll, are stored in the \Program
Files\Exchsrvr\bin directory.
• Remote X.400 MTA The Exchange MTA communicates with remote X.400
MTAs through X.400 connectors. An X.400 connector is a configuration object in
Active Directory that describes the communication parameters and message formats
that the Exchange MTA must use for message transfer. A remote X.400 MTA can be
a non-Exchange MTA or an Exchange MTA connected through an X.400 connector.
For more information about X.400 communication, see MTA Transport Stacks and
X.400 Connectors.
• Exchange 5.5 servers in the same routing group X.400 connector objects
are not required for the Exchange MTA to communicate with servers running
Exchange Server 5.5 in the local routing group. These types of MTAs are also named
LAN-MTAs to emphasize the fact that an explicit X.400 connector is not involved in
their communication. LAN-MTAs use RPCs to communicate with each other. For
317
more information about communication between Exchange Server 2003 and

Exchange 5.5, see Exchange MTA in a Mixed-Mode Organization.
Exchange MTA Configuration Settings in

Active Directory
The Exchange MTA obtains its configuration settings from the local registry and from an MTA
object in Active Directory. The MTA directory object is located under each Exchange server
object in the configuration directory partition. For example, the following is the distinguished
name of an MTA object on a server called SERVER01 in the tailspintoys.com domain:
CN=Microsoft MTA,CN=SERVER01,CN=Servers,CN=First Administrative
Group,CN=Administrative Groups,CN=Tailspin Toys,CN=Microsoft.
The location of the MTA configuration object is slightly different in Exchange System
Manager. You can find the MTA configuration object in the Protocols container under the
server object, as shown in the following figure. The object is named X.400, although you are
actually configuring the MTA and not just X.400 settings. You can use the X.400 configuration
object to define the name of the MTA and its local password. You can also specify the MTA
database directory in which the message queues reside. On the Messaging Defaults tab,
you can configure general communication parameters, such as retry values, which the MTA
uses for communication with LAN-MTAs. You can override these settings when you configure
X.400 connectors.
318
The MTA configuration object in Exchange System Manager
MTA configuration objects are instances of the MTA object class. For example, you can use
this information in a Lightweight Directory Access Protocol (LDAP) filter to export all settings
from all MTAs in an Exchange organization to a text file. The following LDAP Data
Interchange Format Directory Exchange (LDFIDE) command demonstrates how to perform
this step: ldifde -f c:\AllMTAs.ldf -s localhost -d "CN=First Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r
"(objectClass=mTA)". You must have read permissions on all administrative groups in the
organization.
The following table lists the important attributes of the MTA directory object and their
purposes.
319
Important attributes of the MTA directory object
Directory Attribute Purpose
objectClass Identifies the directory object as an MTA

object.
cn Contains the common name (cn) of the

MTA.
transRetryMins Defines the period of time between transfer

retries in minutes. The default is five
minutes.
transTimeoutMins Defines the timeout period for message

transfer in minutes. The default is 20
minutes.
mTALocalDesig Specifies the X.400 name of the local MTA.

This name, of up to 32 characters, is used
to identify the local Exchange MTA to
remote MTAs and LAN-MTAs.
delivContLength Defines the maximum deliverable message

size, in kilobytes (KB), that can be sent over
the MTA.
diagnosticRegKey Specifies the location of the diagnostic

registry key. If this key does not exist, the
MTA uses the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\Curren
tControlSet\Services\MSExchangeMTA\Dia
gnostics.
expandDLsLocally Corresponds to the setting Expand remote

distribution lists locally, in the MTA
properties. If expandDLsLocally is True, and
a user sends a message to a remote
distribution list, the MTA expands the
distribution list locally. The Exchange MTA
then determines the best route for the
message, based on the location of
recipients in the list. This method
guarantees the most efficient message
handling. However, processing large
distribution lists can affect server
performance.
320
msExchHomeRoutingGroupDNBL A back link to the routing group of which this

MTA is a member.
associationLifetime Specifies the amount of time in seconds

that the system keeps an association open
to a remote X.400 MTA after a message is
sent. The default is 300 seconds.
numOfOpenRetries Specifies the maximum number of times

that the Exchange MTA tries to open a
connection before it sends a non-delivery
report (NDR). The default is 144 times.
numOfTransferRetries Specifies the maximum number of times

that the Exchange MTA tries to transfer a
message across an open connection. The
default is two times.
openRetryInterval Specifies the number of seconds that the

system waits after an error before
attempting to reopen a connection. The
default is 600 seconds.
rTSCheckpointSize Specifies the amount of data in KB that is

transferred before a checkpoint is inserted.
If an error occurs and the message must be
resent, the process restarts from the most
recent checkpoint. A value of zero indicates
that no checkpoints are inserted.
rTSRecoveryTimeout Specifies the amount of time after a broken

connection that the MTA waits for
reconnection before deleting the information
(with its checkpoints) and restarting the
transfer from the beginning.
rTSWindowSize Specifies the number of checkpoints that

can go unacknowledged before data
transfer is suspended. The window size has
no meaning if the checkpoint size is zero.
sessionDisconnectTimer Specifies the amount of time in seconds

that the Exchange MTA waits before ending
a connection after all associations over this
connection are ended.
321
tempAssocThreshold Specifies the maximum number of queued

messages that the system can send to a
remote system. When this is exceeded, the
MTA opens another association.
transferRetryInterval Specifies the number of seconds that the

system waits after a message transfer fails
before re-sending a message across an
open connection. The default is 120
seconds.
transferTimeoutNonUrgent Specifies the amount of time in seconds per

kilobyte that the system waits before
sending an a non-delivery report (NDR) for
a non-urgent message.
transferTimeoutNormal Specifies the amount of time in seconds per

sending a non-delivery report (NDR) for a
normal message.
transferTimeoutUrgent Specifies the amount of time in seconds per

sending a non-delivery report (NDR) for an
urgent message.
msExchMTADatabasePath Indicates the path to the MTA database

directory.
msExchResponsibleMTAServerBL Contains the distinguished name of the

server hosting the MTA.
322
msExchEncryptedPassword Specifies the MTA password that remote

MTAs must use when connecting to this
MTA. The password can be up to 64
characters long and is stored in
Active Directory in encrypted form.
Note:
The MTA password is stored in
encrypted form in Active Directory,
but this does not mean that MTA
names and passwords are secure.
X.400 MTAs exchange their names
and passwords in clear text when
establishing connections.
Internal Exchange MTA Architecture

The internal architecture of the Exchange MTA is based on thread pools, message queues,
and database queues. Threads perform the actual processing within the Exchange MTA
process (Emsmta.exe). Message queues, indicated by arrows in the following figure, handle
interactions and notifications between threads. Database queues contain messages waiting
for processing by one of the thread pools. For example, the work queue, shown in the
following figure, is a database queue that holds messages until the MTA has transferred them
successfully or until they expire and are returned to the sender with a non-delivery report
(NDR). Running multiple threads allows the Exchange MTA to perform multiple tasks
concurrently. This figure shows the internal architecture of the Exchange MTA.
323
Internal Exchange MTA architecture
The internal Exchange MTA architecture is based on the following elements:
• XFER IN and XFER OUT threads These threads handle the actual message
transfer in and out of the MTA process. This communication takes place through the
following mechanisms:
• X.400 Communication with a remote X.400 MTA or an Exchange server

in a remote routing group using an X.400 connector.
• RPCs Communication with a LAN-MTA (that is, a server running

Exchange Server 5.5 in the local routing group).
• XAPI Communication with the Exchange store using MAPI.
You can control the number of transfer threads using the following registry parameter.
Set\Services\
MSExchangeMTA\Parameters
Value Transfer threads
Type REG_DWORD
Value Data 0x1

324
Description Determines the number of MTA transfer

threads. This value is multiplied by two for
the two subtypes of transfer threads (XFER
IN and XFER OUT).
The default value is 0x1. The recommended

value is 0x3, if this MTA communicates with
multiple remote MTAs, either within a
routing group or between routing groups.
• Work Queue The Exchange MTA writes all messages to .dat files in the MTA
database directory on the file system. It then creates a pointer for each .dat file in the
work queue. The work queue maintains a reference to each message for which the
MTA is responsible. The MTA database and .dat files are discussed later in this
section.
• Dispatcher The dispatcher is at the core of the MTA process and is responsible
for message routing and results processing. The dispatcher uses router, fan-out, and
result threads for message processing. The dispatcher performs the following key
tasks:
• Message routing, fan-out, and transfer The dispatcher uses a routing

thread to communicate with the routing engine and determine the next hop
for message transfer. If a message is addressed to recipients in different
destinations that are reached through separate connections (such as two
X.400 connectors installed on the same server), the dispatcher uses a fan-
out thread. The fan-out thread creates multiple message copies and places
them in the appropriate link queues. The dispatcher then triggers XFER OUT
threads to process the fan-out message copies.
Note:
The process of creating multiple message copies in the MTA is named fan-
out. This is in contrast to bifurcation, which refers to the process of creating
multiple message copies in the categorizer of the SMTP transport
subsystem. The categorizer is covered in detail in SMTP Transport
Architecture.
• Results processing The dispatcher also performs reporting based on

the results of routing, fan-out, and transfer actions. For example, if a
message is successfully transferred over an X.400 connector, the dispatcher
updates the responsibility flags for the message recipients in the work queue
to indicate transfer success.
Each message in the work queue has a bitmap that is made up of one bit per
recipient. Initially, the MTA sets the bits for all recipients to indicate that the message
325
is not transferred. Once a fan-out copy of a message is successfully transferred, by

an XFER-OUT thread, the dispatcher clears the bits corresponding to the recipients
on that fan-out copy. The MTA removes the message from the work queue when the
message successfully transfers to recipients, or when the message expires. At this
point, the MTA generates an NDR for each recipient that did not receive the
message.
You can control the number of dispatcher threads using the following registry parameter.
Set\Services\
Value Dispatcher threads
Type REG_DWORD
Value Data 0x1
Description Determines the number of MTA dispatcher

threads, which are responsible for message
processing. This value is multiplied by three
for the three subtypes of dispatcher threads
(that is, router, fan-out, and result threads).

value is 0x3 if this MTA communicates with
more than five LAN-MTAs.
• Submit and deliver threads These thread pools are a legacy from Exchange
Server 5.5. They are not used in Exchange 2000 Server and Exchange Server 2003
under typical circumstances, because in Exchange 2000 Server and Exchange
Server 2003, there is no direct submit or delivery. All messages must pass through
the SMTP service. The SMTP service delivers messages to local recipients through
the Exchange store driver, as explained in SMTP Transport Architecture.
The Exchange MTA treats the SMTP service similar to a MAPI-based connector with
message queues in the Exchange store. XAPI gateways handle the message transfer in
and out of the message queues in the Exchange store. XAPI gateways are threads in the
Exchange store that interface with the XFER IN and XFER OUT MTA threads.
The Exchange MTA uses the following threads for inter-process communication and to
perform system functions, such as updating configuration information when changes occur.
• OSI stack The Exchange MTA uses a number of thread pools to handle
communication tasks between the various layers of the Open Systems
Interconnection (OSI) stack. These thread pools include reliable transfer service
326
(RTS) threads, kernel threads, RPC threads, transport threads, and TCP/IP or X.25
threads. For more information about the purpose of these threads, see MTA
Transport Stacks and X.400 Connectors.
• Timers The Exchange MTA runs timer threads in various situations; for
example, to wait after a message transfer fails before re-sending a message across
an open connection.
• Directory polling The Exchange MTA uses a separate thread to poll

Active Directory every ten minutes for configuration changes.
• Threads not owned by the MTA The routing engine and the DSAccess module
own threads that run in the MTA process, to inform the Exchange MTA when changes
occur. For example, the routing engine calls the RoutingReset () function of the MTA
if the routing topology changes to trigger message rerouting for all queued
messages. DSAccess communicates with the Exchange MTA to provide cached
directory information.
Exchange MTA Database

The Exchange MTA maintains all messages that it transfers in the MTA database. The MTA
database is a flat-file database that is made up of .dat files, as illustrated in the following
figure. There are separate .dat files for database queues and the actual messages. Note that
database queues contain references or pointers to the actual messages, but database
queues do not contain the messages themselves. The MTA stores each message in a
separate message .dat file in the MTA database directory. In an active database, there is a
DBREFS file that contains reference counts for objects, which provide tertiary backup
information. DBREFS is rebuilt when the MTA is restarted or the MTA check tool is run.
It is difficult to distinguish between the various .dat file types in an active MTA database. The
Exchange 2000 Server Resource Kit (available at bookstores) includes a tool named
MTAView. You can use MTAView to view the contents of the MTA's queues and the headers
of the messages in these queues. The following figure illustrates the MTAView tool with an
active MTA database open. The foreground window shows the .dat files in the MTA message
queue directory.
327
Message queues and .dat files of the Exchange MTA
The MTA .dat files are divided into two categories:
• Core .dat files The core .dat files act as the reference rows and columns of the
MTA database. There are 38 core .dat files in the message queue directory
(\Program Files\Exchsrvr\Mtadata), and all are required for the Exchange MTA to run.
Most core .dat files ship with Exchange Server 2003. You can find these files on the
product CD in the \Setup\i386\Exchange\Bootenv directory. The Exchange
Server 2003 Setup program copies these files to the \Program
Files\Exchsrvr\Mtadata directory during installation. The core .dat files that ship with
Exchange Server 2003 are numbered DB000001.dat through DB000026.dat (in hex
numbers).
328
The Exchange MTA dynamically creates additional .dat files for important database
queues. For example, the MTA rebuilds the MTA work queue each time the MTA is
restarted. During this rebuild, no messages are delivered, because the MTA must first
account for all .dat files. When all files are accounted for, message transfer begins.
The most important core .dat files on an active MTA database are:
• DB000001.dat This is the most important database queue, named the

master queue. The master queue contains a list of queue object IDs and
references to other work queues, which each have their own individual .dat
files.
• DB000020.dat This is the XAPI work queue that maintains references to

messages bound for the SMTP service or MAPI-based gateway connectors,
such as Connector for Lotus Notes and Connector for Novell GroupWise,
which have their own message queues in the Exchange store.
• DB000025.dat This is the out of office information queue that contains

objects for out of office notifications.
• DB000026.dat This is the reference data queue. For redundancy, .dat

files are referred more than once in the queue .dat files.
• DB000027.dat This is the MTA work queue that contains a list of

messages waiting for transfer.
• Message and placeholder .dat files The remaining .dat files in the database
directory are message and placeholder files. The MTA creates a message .dat file for
each message it must transfer. Because the number portion of the file name is
assigned at random (DB######.dat), duplicate file names are possible. To avoid
overwriting an existing file, the Exchange MTA creates a placeholder .dat file together
with each message .dat file. The placeholder .dat file is one byte in size and is used if
a message .dat file cannot be created because of a duplicate file name. The figure
above illustrates a message .dat file of two megabytes (DB00002D.dat) and a
placeholder .dat file of zero kilobytes (DB00002E.dat). The MTA creates two .dat files
for each message.
After a message is transferred, the Exchange MTA erases the data from the .dat files and
resets the files to one byte (instead of deleting the .dat files). The Exchange MTA can
then reuse the .dat files for future messages. This mechanism enhances the performance
of the MTA, because creating and deleting files is time consuming. The number of .dat
files that you find in the message queue directory reflects the maximum number of
messages in the queue at any one time. On a busy bridgehead server running Exchange
Server 2003, you might find hundreds of .dat files in the MTA database directory.
329
Relocating the MTA Database Directory

Exchange System Manager enables you to move the MTA database directory to another
location in the file system (in the server's Protocols container, right-click the X.400
configuration object, click Properties, and then on the General tab, under Message queue
directory, click Modify). When you modify the location of the queue directory in Exchange
System Manager, you move the database files to the new location, and you change the
msExchMTADatabasePath attribute of the MTA directory object to point to the new location.
However, the msExchMTADatabasePath attribute is for informational purposes only. More
important is the following registry key, which Exchange System Manager also updates.
Set\Services\
Value MTA database path
Type REG_SZ
Value Data C:\Program Files\Exchsrvr\Mtadata
Description Points to the location of the database files

(queue files and message files) for the
Exchange MTA. If the path is not valid or
points to an empty directory, the MTA
cannot start.
You should not place the MTA database directory on a file allocation table (FAT) partition.
FAT16 partitions support a maximum of 65,535 files. This size limitation can be an issue on a
busy bridgehead server. When a queue starts to fill, available entries with which to create
new files can become depleted in only a single day. This problem is compounded because
each message requires two .dat files. Moreover, FAT does not perform well on large volumes,
provides only minimal fault tolerance, and has no recoverability after an unexpected system
halt.
On a busy X.400 bridgehead server running Exchange Server 2003, you can optimize
performance by placing the MTA database directory on a high-performance disk subsystem,
such as a redundant array of independent disks (RAID). A RAID 0+1 with eight to ten disks is
a good starting point for high-volume message transfer. A RAID controller with a cache larger
than 64 megabytes (MB) also helps performance.
Note:
Under the MTA database path registry key, you can find a registry key called MTA
Run Directory. This registry key points to the directory where the run files for the
330
Exchange MTA are located. It is best to place the database and run directory on
different disks.
Secured and Unsecured Message Copies

Messages in the MTA work queue are named secured messages, because they are always
saved in .dat files. These .dat files persist even if an unexpected termination of the Exchange
MTA process occurs. The dispatcher uses secured messages in the work queue as source
files and creates unsecured message copies. The dispatcher then attaches the appropriate
link queues for the connectors or next hop links to transfer the messages. If a message is
intended for multiple destinations, which are reached over separate connections, the
dispatcher creates a fan-out copy for each connection. Each fan-out copy references the
secured message in the MTA work queue. The MTA removes secured and unsecured
message copies from the queues when the message is transferred successfully.
Messages on link queues are represented as reference pointers to message objects and not
as the objects themselves. Secured messages are available in .dat files, but this is not
necessarily true for unsecured copies. Unsecured copies are kept in memory primarily to
increase MTA performance. The dispatcher saves unsecured copies in .dat files only if there
is not enough cache space available to hold the objects in memory. The cache is a fixed pool
of 4k buffers and per-object structures, based on thread pool sizes. You can adjust the
number of data buffers per object in memory using the following registry parameter.
Set\Services\
Value DB data buffers per object
Type REG_DWORD
Value Data 0x3

331
Description Determines the number of database server

buffers that are configured for each
database object. More buffers require more
memory but make it less likely for a
database object to be rolled out to disk
because of a lack of buffer space.

multiple MTAs, either within a routing group
or between routing groups. Additionally, you
should tune this setting if a MAPI-based
connector is installed on this server.
MTA Database in a Server Cluster

It is not possible to partition the MTA database and .dat files so that multiple MTA instances
can use the MTA database concurrently. This is a requirement, for example, if you want to run
MTA on multiple cluster nodes in a server cluster, based on the Microsoft Windows
Server 2003 Clustering service. Because only one MTA can own the MTA database, the
Exchange MTA can run only on the first initialized node in the cluster. Upon failover, the
cluster service stops the MTA on the failed node and starts it on another node, which then
recovers from the same .dat files and re-establishes connections.
Corrupted Messages in Gateway Queues

Exchange Server 2003 transfers messages, destined for MAPI-based connectors, to the MTA
through the Exchange store. Messages travel back from the MTA, through the Exchange
store, to the connector mailbox. By default, there are only two threads (one for incoming
transfers and one for outgoing transfers) communicating with the MTA. This means that a
corrupt message, at the top of a gateway link queue in the MTA, can block all message flow
to or from the Exchange store. To unblock the message queue, you can use the Queue
Viewer snap-in in Exchange System Manager to delete critical messages.
Note:
You should not delete .dat files directly from the MTA database directory, because
accidentally deleting a core .dat file can corrupt the entire database.
You can also increase the number of gateway in-and-out threads in the Exchange store
process for each mailbox store by using the following registry parameters. If the Exchange
store communicates with the Exchange MTA using multiple threads, a corrupt message might
block one thread, but another thread might still be able to process further messages. If all
332
gateways are blocked by multiple corrupted messages, this might indicate a serious problem
(for example, a hard disk controller malfunction).
Set\Services
\MSExchangeIS\<server_name>\Private-
<database_guid>
Value Gateway In Threads Gateway Out Threads
Type REG_DWORD
Value Data 0x1
Description The default value for both of these

parameters is 0x1. The recommended
setting is 0x3 if this MTA communicates with
multiple LAN-MTAs or is responsible for
MAPI-based messaging connectors.
You must add these parameters to all keys

for mailbox stores in the registry. Each
gateway-in and gateway-out thread
consumes about one MB of virtual memory.
This could be an issue on servers with
many private databases. For example, if
you have ten private databases, and you
increase these parameters from 0x1 to 0x3
(a total increase of four threads), you create
4 x 10 = 40 threads, which together
consume 40 MB of virtual memory.
Fixing MTA Database Corruption

If deleting a corrupted message from a message queue does not fix all problems relating to
MTA queues, use the MTA Check tool (Mtacheck.exe) to analyze and correct problems in the
MTA database. Run MTA Check if you suspect corruption in the MTA database or see errors
written to the Event Log. The MTA Check tool must be used directly on the server, you must
stop the Microsoft Exchange MTA Stacks service. The MTA Check tool checks the pointers in
the database queues and ensures that the .dat files indicated in the queue files exist. The tool
removes corrupt messages (that is, messages with inconsistent pointers). Corrupt messages
are moved to the \Program Files\Exchsrvr\Mtadata\Mtacheck.out directory. You can use
command-line parameters to delete public folder replication messages and other system
messages, but you must use them with care. For further information, see the MTA Check tool
333
documentation. The MTA Check tool and its documentation are available from the Downloads
for Exchange Server 2003 Web site.
Wiping the MTA Database

On a busy bridgehead server with multiple X.400 or MAPI-based connectors, the MTA
database directory can fill with more than 10,000 .dat files. This issue is compounded if there
are transfer problems due to corrupt messages or network problems. The relevant physical
limit to the number of .dat files that can be written to disk is the amount of available disk
space. The Microsoft Exchange MTA Stacks service shuts down when the available disk
space drops below ten on the hard drive where the MTA database is located.
To restart the Microsoft Exchange MTA Stacks service, you must make sure that more than
ten megabytes of disk space are available. This might require that you temporarily move all of
the .dat files out of the MTA database directory to another drive or a network share. The
process of moving files to create an empty database directory is known as an MTA wipe. An
MTA wipe is helpful when troubleshooting MTA database problems, such as numerous
corrupted messages stuck in database queues.
For detailed instructions about how to wipe the MTA Metabase, see How to Wipe the MTA
Database.
Caution:
If you need to wipe an MTA database, you should contact Microsoft Product Support
Services for assistance to ensure that the steps are performed correctly. If you apply
the steps incorrectly, you might loose e-mail messages that are currently present in
the MTA message queues.
Replaying DAT Files

To deliver messages that were in the MTA database at the time of a MTA database wipe, you
must replay the .dat files. There are three different ways in which you can replay DAT files.
• You can perform a complete replay The easiest way to replay the .dat files is
to replay them all at one time on the server where they originally resided. To do this,
the MTA on the Exchange server of origin should have nothing in its queues. If there
are messages in the MTA queues, the MTA should be allowed to finish sending the
messages until all of the queues are empty.
• You can perform a remote replay The .dat files do not have to be replayed on
the Exchange server where they originally resided. If, for example, the original
Exchange server is a busy bridgehead server that continuously transfers large
quantities of e-mail messages and does not reach an empty MTA work queue, you
can choose to replay the messages on another server running Exchange Server.
334
• You can perform an incremental replay An incremental replay is performed

by dividing the .dat files into several smaller groups, which are replayed one at a
time. This approach is more complicated than a complete or remote replay, but can
be helpful when dealing with a very large number of .dat files. An incremental replay
might also be a good idea when important messages must be delivered, but a corrupt
message somewhere in a message queue is causing the MTA to stop unexpectedly.
You can perform an incremental replay on the original Exchange server or on another
Exchange server in the organization.
For detailed instructions about how to perform each of these procedures, see How to Replay
DAT Files After an MTA Database Wipe.
Examining Exchange MTA Processing

The primary tools used to monitor the MTA are System Monitor (in the Performance Monitor
tool) and Event Viewer. You can use System Monitor to monitor the behavior of messaging
connectors in real time. You can determine the number of messages waiting in inbound and
outbound message queues. You can determine the total number of messages that have been
transferred by a connector since the MTA was started. It is a good idea to check message
queues using System Monitor, because numerous messages queuing up in a messaging
connector might indicate a performance bottleneck or a malfunctioning connector component.
The Event Viewer tool can help you identify and diagnose the source of system problems or
help you predict potential issues. The Exchange MTA writes critical events in the Application
Event Log. An event is an occurrence of activity in the Exchange MTA that might require
administrator attention.
Checking the Exchange MTA Using System

Monitor
Performance monitoring involves looking at discrete components of a system. In Windows, an
object represents an individual process, a section of shared memory, or a physical device. An
object can have several performance counters associated with it. For example, the
MSExchangeMTA object has many performance counters, including a counter named Work
Queue Length that indicates the number of messages in the MTA work queue.
To add performance counters to System Monitor, start the Performance monitor tool and then,
in the toolbar, click Add, indicated by a plus sign (+). You can then select the
MSExchangeMTA object from the Performance object drop-down list in the Add Counters
dialog box. According to your selection, appropriate performance counters are listed in the
Select counters list.
The following table lists the performance counters available for the MSExchangeMTA
performance object.
335
MSExchangeMTA performance counters
Performance counter Description
Adjacent MTA Associations The number of open associations that this

MTA has to other MTAs.
Messages/Sec The rate at which messages are processed.
Message Bytes/Sec The rate at which message bytes are

processed.
Free Elements The number of free buffer elements in the

MTA pool.
Free Headers The number of free buffer headers in the

MTA pool.
Admin Connections The number of Microsoft Exchange

Administrator programs connected to the
MTA.
Threads In Use The number of threads in use by the MTA.

This number can be used to determine
whether additional processors might be
beneficial.
Work Queue Length The number of outstanding messages in the

Work Queue. This indicates the number of
messages not yet processed to completion
by the MTA.
XAPI Gateways The number of XAPI gateways connected

to the MTA using the XAPI interface. A
single gateway can have multiple XAPI
gateway sessions.
XAPI Clients The number of XAPI clients connected to

the MTA using the XAPI interface. A single
client can have multiple XAPI client
sessions.
Disk file deletes The number of disk file delete operations

per second.
Disk file syncs The number of disk file sync operations per
second.
Disk file opens The number of disk file open operations per
second.
336
Disk file reads The number of disk file read operations per
second.
Disk file writes The number of disk file write operations per
second.
ExDS Read Calls/sec The rate of read calls to the Directory

service.
XAPI Receive Bytes/sec The rate at which bytes are received over a
XAPI connection.
XAPI Transmit Bytes/sec The rate at which bytes are transmitted over
a XAPI connection.
Admin Interface Receive Bytes/sec The rate at which bytes are received over
an admin connection.
Admin Interface Transmit Bytes/sec The rate at which bytes are transmitted over
an admin connection.
LAN Transmit Bytes/sec The rate at which bytes are transmitted over
a LAN to MTAs.
LAN Receive Bytes/sec The rate at which bytes are received over a
LAN from MTAs.
RAS Receive Bytes/sec The rate at which bytes are received over a
RAS connection. RAS-based X.400
connectors are not available in Exchange
Server 2003.
RAS Transmit Bytes/sec The rate at which bytes are transmitted over
a RAS connection. RAS-based X.400
Server 2003.
TCP/IP Receive Bytes/sec The rate at which bytes are received over a
TCP/IP connection.
TCP/IP Transmit Bytes/sec The rate at which bytes are transmitted over
a TCP/IP connection.
TP4 Receive Bytes/sec The rate at which bytes are received over a
TP4 connection. TP4-based X.400
Server 2003.
337
TP4 Transmit Bytes/sec The rate at which bytes are transmitted over
a TP4 connection. TP4-based X.400
Server 2003.
X.25 Receive Bytes/sec The rate at which bytes are received over
an X.25 connection.
X.25 Transmit Bytes/sec The rate at which bytes are transmitted over
an X.25 connection.
The Exchange MTA also provides a performance object for each connection established by
the MTA. In the Add Counters dialog box, select the MSExchangeMTA Connections object
from the Performance object drop-down list. You can then find the individual connection
instances under Select instances from list. Each MSExchangeMTA Connections instance
describes a single connection, but you can also choose to monitor all instances together.
Performance counters for individual connections established by the MTA
The following table lists the performance counters that are available for MSExchangeMTA
Connections performance objects.
338
MSExchangeMTA connections performance counters
Associations The number of associations between the

MTA and the connected MTA. MTAs can
open multiple associations, if additional
transfer throughput is necessary.
Receive Bytes/sec The rate at which bytes are received from

the connected entity.
Send Bytes/sec The rate at which bytes are sent to the

connected entity.
Receive Messages/sec The rate at which messages are received

from the connected entity.
Send Messages/sec The rate at which messages are sent to the

connected entity.
Note:
When sending many messages to the Exchange MTA, the Send Messages/sec value
displayed in MSExchangeMTA Connections - SMTP Server <GUID> goes up and
down while messages flow. However, MSExchangeMTA - Work Queue Length is
always at zero. When sending messages from Exchange to a remote MTA, using an
X.400 Connector, both MS Exchange MTA - Work Queue Length and MS Exchange
MTA Connections - X.400 Connector show activity. This is a result of the different
mechanism that is used by the MTA for inbound and outbound XAPI message
handling. For inbound messages to the SMTP mailbox (an XAPI gateway), the MTA
immediately transfers the messages to the XAPI work queue (DB000020.dat). This is
not the MTA work queue (DB000028.dat). However, for X.400 MTAs or LAN-MTAs,
the MTA places the message in the MTA work queue and does not complete the
transfer until the remote MTA confirms that the message is received. In this way,
System Monitor can be used to determine details of the internal MTA processing.
Exchange MTA Event Logging

Troubleshooting MTA issues should include an inspection of the Application Event Log. The
Exchange MTA tracks critical events automatically, but you can also set diagnostics logging
levels by category for the MTA, to increase the amount of information that the Exchange MTA
writes in the event log. In Exchange System Manager, display the properties of the server
object of interest and then click the Diagnostics Logging tab. Under Services, select
MSExchangeMTA, and then select Categories to list the categories for the MTA. Each MTA
category has a diagnostics logging level. When the MTA generates an event with a
339
significance number less than or equal to the logging level, the event is recorded in the Event
Log. If the significance number of the event is greater than the logging level, it is not logged.
The following table lists the Exchange MTA categories that can be enabled for diagnostics
logging.
During normal operation, all categories of the Exchange MTA should have a logging level of
None. At this level, only error events and critical messages are written to the event log. When
increasing the logging level, select only those categories relevant to the issue. Setting logging
levels too high, for too many categories, can quickly fill the event log with irrelevant
information. Do not forget to reset the logging level on all categories to None when you are
done examining the MTA.
Tip:
It is also possible to filter events according to event sources and categories. In Event
Viewer, select the Application log, click View, and then click Filter. Under Event
source, select MSExchangeMTA. To display all events of the Exchange MTA in
Event Viewer, ensure that Category is set to All. Event logs can be viewed locally or
remotely, and they can be saved to *.EVT files.
Diagnostics logging categories for the Exchange MTA
Category Description
X.400 Service Reports events related to X.400 protocol

handling, such as delivery of messages to a
remote MTA.
Resource Reports events related to the use of MTA

resources.
Security Reports events related to MTA security and

security violations.
Interface Reports events related to communication

between the MTA and the Exchange store
and communication between MTAs using
RPCs.
Field Engineering Reports events related to debugging MTA

operation. These events reveal details
about internal processing in the Exchange
MTA and are useful to a Microsoft Product
Support Services support specialist.
340
MTA Administration Reports events related to message queues.

Uses the Queue Viewer snap-in, in
Exchange System Manager, to work with
MTA queues to generate these events.
Configuration Reports events related to problems with

MTA configuration settings. Corrupt run files
in the \Mtadata directory or invalid registry
parameters can cause these events.
Directory Access Reports events related to Active Directory

communication.
Operating System Reports events related to operating system

services that the MTA uses to create and
manage files and threads.
Internal Processing Reports events related to the internal

processing in the Exchange MTA, which
can be useful to a Microsoft Product
Support Services support specialist.
341
Interoperability This category does not cause the MTA to

write information to the Application Event
Log. Instead, it tracks the binary content of
protocol messages. Use this category in
conjunction with the Interface category to
log messages sent over internal interfaces
to AP*.log files in the \Program
Files\Exchsrvr\Mtadata directory. For
example, you can use AP*.log files to create
MTA stack traces and XAPI traces.
Interoperability logs can be instrumental in
tracking down configuration problems on
MTAs.
Increasing diagnostic logging levels to

Medium or higher for both the
Interoperability and Interface categories
generates AP*.log files. The current log is
always named Ap0.log. Prior logs are
named AP#.log, with the # increasing with
the age of the log. When a log reaches five
megabytes, it is renamed and a new
AP*.log is created.
Note:
AP*.log files can grow very quickly
and have a performance impact on
the Exchange MTA.
342
APDU (Application Protocol Data Unit) This category does not cause the MTA to
write information to the Application Event
Log. Instead, it tracks the message
envelope content (the P1) for messages the
MTA sends and receives, as well as the
fully-encoded application protocol data units
(APDUs) that are transmitted between the
MTAs.
Use this category in conjunction with the

X.400 Service category to log information to
BF*.log files in the \Program
Files\Exchsrvr\Mtadata directory. BF*.log
files are useful when diagnosing
interoperability or conformance problems,
for example, when messages from remote
MTAs are bad or formatted incorrectly. An
ASN.1 Parser tool, such as the Aspirin tool
(included in Exchange 2000 Server
Resource Kit, available in bookstores), can
be used to decode the data in a Bf*.log.
Increasing diagnostic logging levels to

Medium or higher for both the APDU and
X.400 Service categories generates BF*.log
files. The current log is always named
Bf0.log. Prior logs are named BF#.log, with
the # increasing with the age of the log.
When a log reaches 5 megabytes in size, it
is renamed and a new BF*.log is created.
Note:
BF*.log files can grow very quickly
and have a performance impact on
the Exchange MTA.
Text Event Logging

To log all MTA event information to EV*.log files in the \Exchsrvr\Mtadata directory, set the
following registry parameter. The EV*.log files are a non-localized text copy of the same
MSExchangeMTA events that are logged to the Application Event Log. The categories and
343
levels of events written to the log files are controlled, as described in Table 7.4. EV*.log files
are easier to read, search, and copy when troubleshooting MTA issues than the
corresponding Application Event Log.
Location HKEY_LOCAL_MACHINE\CurrentControlSet\Ser
vices\MSExchangeMTA\Parameters
Value TextEventLogging
Type REG_DWORD
Value Data 0x1
Description Setting this value to 0x1 enables text

logging to the EV*.log files.
For more information about the various logs that the Exchange MTA can create, see Microsoft
Knowledge Base article 153188, "XCON: Description of MTA Diagnostics Logging Options."
Trace Level Logging

The higher the diagnostics logging level, the more MTA-related events you find in the
application event log. This additional information improves your ability to determine the cause
of a message flow issue. To obtain the most detailed information about the Exchange MTA,
set the diagnostics logging level for the MTA categories to trace level. Trace level logging is
not exposed in Exchange System Manager and can only be set using Registry Editor.
Note:
Trace level logging degrades server performance measurably. Use trace level logging
under the guidance of Microsoft Product Support Services when troubleshooting
complex Exchange MTA issues.
Caution:
own risk.
To set the diagnostics logging level for MSExchangeMTA categories to trace level, use the
following steps:
1. Start Registry Editor and open the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Diagnostics
344
2. Double-click each entry for the individual MSExchangeMTA categories and set
the values to 0x7. For example, double-click the 1 X.400 Service entry in the right
pane, and then change the value to 0x7.
3. Restart the Microsoft Exchange MTA Stacks service. Services typically do not
have to be restarted in order for the change to take effect. However, when editing the
registry manually, you might have to perform this step.
MTA Check Logging

One underused troubleshooting tool is a current, verbose Mtacheck.log file. This log file
shows the results of running Mtacheck.exe. You can run the MTA Check tool manually, but it
also runs automatically when the Microsoft Exchange MTA Stacks service determines that the
MTA was previously shut down incorrectly. If the MTA Check tool is run automatically, events
are logged to the application event log and an Mtacheck.log file is generated in the \Program
Files\Exchsrvr\Mtadata\Mtacheck.out directory. You can use the Mtacheck.log file to perform
the following tasks:
• Obtain a quick list of all the secured queues and their associated object IDs.
• Quickly identify which queue a message object resides in at MTA startup.
• Associate data and reference objects with each other that are in the work queue
at startup.
For more information about the Mtacheck.log file, see Microsoft Knowledge Base article
163323, "XCON: Mtacheck.log."
Object IDs and Message IDs

For every object that the Exchange MTA processes, there is an associated eight-digit object
ID. The first two digits of the object ID identify the object class. The last six digits of the ID
correspond to a DB<6digit>.dat file, if the object is written to disk. MTA object classes range
in hex from 01 to 0E. The two most important classes are 01 (queues) and 06 (messages).
For example, the following event refers to a message object with an ID of 0600002D.
Event ID: 272
Source: MSExchangeMTA
Type: Information
Category: X.400 Service
received from entity /DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT

EXCHANGE/CN=FIRST ORGANIZATION/CN=CONNECTIONS/CN=SMTP (SERVER01-{43D5C017-4A4B-4AFD-
85AF-06EAB90057AA}). The entity is a XAPI-Gateway , object is a Normal priority
Message, the MTS identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4,
345
and content length is 1719. The number of objects sent so far = 1. External trace
information (first 100 bytes) =
3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D
3034303530333136303234315A8201008302060000000000. (10)
Note:
Not all objects that the MTA handles are written to disk. Unsecured objects might
exist only in memory.
Each message also has an associated ID. This is referred to as either the message ID or
Message Transfer Service (MTS) identifier. Unlike object IDs, which are used only by the
local Exchange MTA, the message ID is part of the message itself and can be tracked across
MTAs.
A typical message ID generated by an Exchange MTA has the following format:
C=<country>;A= ;P=<organization>;L=<server>-<date><greenich mean time>-<message
number>. An example is in boldface in event 272, as just shown. There are several variations
of the L= value, depending on the message source. Message IDs from outside Exchange
might differ, but their purpose is the same. MTS identifiers help to associate message copies
with a particular message source. For example, if one message is sent to a distribution group
with hundreds of recipients, each generated fan-out copy of the message has the same
message ID, even after the messages leave the MTA.
How to Wipe the MTA Database

This procedure explains how to wipe the MTA database — specifically, how to move files to
create an empty database directory.
Before You Begin

If you need to wipe an MTA database, you should contact Microsoft Product Support Services
for assistance to ensure that the steps are performed correctly. If you apply the steps
incorrectly, you may lose e-mail messages that are present in the MTA message queues.
Procedure
Wipe the MTA database
1. Use the Services tool (Administrative Tools program group in the Start menu)
to ensure that the Microsoft Exchange MTA Stacks service is stopped.
346
2. Copy the entire contents of the MTA database directory (by default, this is the
\Program Files\Exchsrvr\Mtadata directory) to a different location. This is
preferable to moving only the .dat files, because Microsoft Product Support
Services might require the entire contents of the Mtadata directory to determine
what caused the problem.
Note:
Do not delete the original .dat files until the messages have been recovered.
3. Verify that the copy process completes successfully, and then delete the .dat
files from the MTA database directory.
4. Copy all files found in the \Setup\i386\Exchange\Bootenv directory on the

Exchange Server 2003 product CD to the active MTA database directory. The
Microsoft Exchange MTA Stacks service cannot start without the core .dat files.
5. Remove the read-only file attribute from the copied files. There should be no
read-only files in the MTA database directory.
6. Restart the Microsoft Exchange MTA Stacks service. If the MTA had
problems from corrupted messages in the .dat files, the MTA can now resume
operation and message transfer.

After you have performed an MTA database wipe, the messages in the .dat files that you
moved out of the MTA database directory will need to be replayed before they can be
delivered. For detailed instructions about how to replay DAT files after you have wiped the
MTA database, see How to Replay DAT Files After an MTA Database Wipe.
How to Replay DAT Files After an MTA

Database Wipe
After you have performed an MTA database wipe, the messages in the .dat files that you
moved out of the MTA database directory cannot be delivered until they are replayed. This
topic provides links to the following three procedures for replaying .dat files after an MTA
database wipe:
• A complete replay (in which the .dat files are replayed all at once, and on the
Exchange server where they originally resided).
• A remote replay (in which the .dat files are replayed on an Exchange server other
than the one on they originally resided)
347
• An incremental replay (in which the .dat files are divided into several smaller
groups, which are replayed one at a time).
Before You Begin

Before you perform the procedures in this topic, it is important to consider the differences
among the three methods. For an overview of all three methods, see the section "Replaying
DAT Files" in Exchange MTA in Exchange Server 2003 Architecture.
Procedure
To replay .DAT files after an MTA database wipe
• Select from the three following methods:
• How to Replay DAT Files After an MTA Database Wipe via a

Complete Replay
• How to Replay DAT Files After an MTA Database Wipe via a Remote
Replay
• How to Replay DAT Files After an MTA Database Wipe via an

Incremental Replay
Reference
For general information about wiping the MTA database and replaying DAT files, see the
sections "Wiping the MTA Database" and "Replaying DAT Files" in Exchange MTA in
Exchange Server 2003 Architecture.

Database Wipe via a Complete Replay
This procedure describes how to replay the .dat files following an MTA database wipe via a
complete replay — specifically, how to replay the messages all at one time on the server
where they originally resided. Generally, this is the easiest way to replay the .dat files.
Before You Begin

348
When you prepare to perform the replay, be sure that the MTA on the Exchange server of
origin has nothing in its queues. If there are no messages currently residing in the MTA
queues, the MTA can be stopped. The current .dat files can be safely moved and eventually
deleted, because there are no messages pending delivery. If there are messages in the MTA
queues, the MTA should be allowed to finish sending the messages until all of the queues are
empty. After all queues are empty, the MTA must be stopped immediately. After the MTA is
stopped, move the current .dat files to a different location. Do not leave any earlier .dat files in
the MTA database directory. Copy the .dat files that must be replayed to the MTA database
directory.
Procedure
To perform a complete replay of .dat files after an MTA database wipe
1. Verify that all the MTA queues on the server running Exchange Server are empty.
If the queues are not empty, allow the MTA to finish delivering any messages that are
in the queues.
Note:
You can use the Performance Monitor tool (Perfmon.msc) to verify that no
messages are in the MTA queues. For example, to check the work queue, select
the MSExchangeMTA performance object, and then select the Work Queue
Length performance counter, as illustrated in the following figure.
Checking the number of messages in the MTA work queue

349
2. When the MTA work queue is empty, stop the Microsoft Exchange MTA Stacks
service.
3. Copy the entire contents of the MTA database directory to a different location.
These files are eventually discarded, if the MTA queues were at zero prior to stopping
the MTA.
4. Delete the .dat files from the MTA database directory.
5. Copy the .dat files from the directory that contains the original set of .dat files that
you want to replay in the MTA database directory.
6. Restart the Microsoft Exchange MTA Stacks service.
7. Monitor the MTA queues and event logs to make sure that all messages are
delivered successfully and that the MTA continues to function typically.

• For information about how to replay .dat files after an MTA database wipe via a
remote replay, see How to Replay DAT Files After an MTA Database Wipe via a
Remote Replay.
350
• For information about how to replay .dat files after an MTA database wipe via an
incremental replay, see How to Replay DAT Files After an MTA Database Wipe via an
Incremental Replay.

Database Wipe via a Remote Replay
This procedure describes how to replay the .dat files following an MTA database wipe via a
remote replay — specifically, how to replay the files on an Exchange server other than the
one where they originally resided. You may choose to perform this procedure for convenience
if, for example, the original Exchange server is a busy bridgehead server that continuously
transfers large quantities of e-mail messages and does not reach an empty MTA work queue.
The remote replay server can be in any routing group in the Exchange organization.
Before You Begin

• The steps for replaying the .dat files remotely are almost the same as the steps
for performing a complete replay, which replays the .dat files on the original server.
However, before you perform the remote replay you must set a special registry key
on the server running Exchange Server where you want to replay the .dat files
• Just as you would do in preparing for a complete replay, before you perform a
remote replay, make sure that the MTA on the Exchange server of origin has nothing
in its queues. If there are no messages currently residing in the MTA queues, the
MTA can be stopped. The current .dat files can be safely moved and eventually
deleted, because there are no messages pending delivery. If there are messages in
the MTA queues, the MTA should be allowed to finish sending the messages until all
of the queues are empty. After all queues are empty, the MTA must be stopped
immediately. After the MTA is stopped, move the current .dat files to a different
location. Do not leave any earlier .dat files in the MTA database directory. Copy the
.dat files that must be replayed to the MTA database directory.
Caution:
any valuable data.
351
Procedure
Replay the .dat files following an MTA database wipe via a remote replay
1. Set the following registry key on the server running Exchange Server where
you want to replay the .dat files.
Location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
Value Dispatch remote MTA messages
Type REG_DWORD
Value Data 0x1
Description Causes the MTA to add extra trace information to each

message before routing, so that receiving Exchange
servers that originally handled the messages do not
recognize the messages as looping.
This registry value is case sensitive and must be entered

exactly as displayed above. When the MTA has
successfully finished delivering all replayed messages,
the registry key should be removed or set to 0x0.
2. Follow the steps in this procedure: How to Replay DAT Files After an MTA
Database Wipe via a Complete Replay
3. When the MTA successfully finishes delivering all of the replayed messages,
the registry key you set up for remote replay should be removed.

• For information about how to replay DAT files after an MTA database wipe via a
complete replay, see How to Replay DAT Files After an MTA Database Wipe via a
Complete Replay.
• For information about how to replay DAT files after an MTA database wipe via an
incremental replay, see How to Replay DAT Files After an MTA Database Wipe via an
Incremental Replay.
352

Database Wipe via an Incremental Replay
This procedure explains how to replay .dat files after an MTA database wipe via an
incremental replay. An incremental replay is a replay in which the .dat files are divided into
several smaller groups, which are replayed one at a time. This approach is more complicated
than a complete replay or remote replay, but can be helpful when dealing with a very large
number of .dat files. An incremental replay may also be a good idea when important
messages must be delivered, but a corrupt message somewhere in a message queue is
causing the MTA to stop unexpectedly.
Before You Begin

• If you are performing an incremental replay on an Exchange server other than

the one on which the .dat files originally resided, you must first set the Dispatch
remote MTA messages registry key to 0x1. For detailed instructions about how to
set this registry key, see How to Replay DAT Files After an MTA Database Wipe via a
Remote Replay.
Caution:
any valuable data.
Procedure
To replay DAT files after an MTA database wipe via an incremental replay
1. Create a second copy of the complete set of .dat files. Keep one set as a
backup while the other set is used during the incremental replay. Ideally, the set
to be replayed is located on the same drive as the MTA database directory.
Note:
It is a good idea to keep a complete set of the .dat files in a separate location
so that a full backup is still available if the incremental replay fails.
2. Verify that the replay server has empty MTA queues.

353
3. If no messages are residing in the MTA work queue, stop the Microsoft
Exchange MTA Stacks service and copy the current .dat files to another location.
Eventually, these .dat files can be deleted, because there are no messages
pending transfer.
4. Delete all .dat files from the MTA database directory.
5. Copy all files that can be found on the Exchange 2003 product CD in the
\Setup\i386\Exchange\Bootenv directory to the active MTA database directory.
6. Remove the read-only file attribute from the copied files.
7. Move a portion of the .dat files to be replayed to the MTA database directory.
For example, if you must replay 30,000 .dat files, you might want to replay the
messages in chunks of 5,000 or 10,000 .dat files.
Note:
Ensure that you move the files. If you copy the files instead, it becomes
difficult to distinguish between files that you already replayed and files that
you must replay. Replaying a message multiple times leads to multiple
message deliveries. When the working copy of the .dat files is on the same
directory as the MTA database directory, moving the files to the MTA
database directory is simplified.
8. Run Mtacheck /V to check the MTA database.
9. Start the Microsoft Exchange MTA Stacks service and monitor the MTA work
queue and event logs to ensure that all messages are processed successfully
and that the MTA is functioning normally.
10. Repeat the steps until all of the .dat files are replayed.
11. If you are performing an incremental remote replay, do not forget to remove
the Dispatch remote MTA messages registry key, or set it to 0x0 when you are
finished.

complete replay, see How to Replay DAT Files After an MTA Database Wipe via a
Complete Replay.
remote replay, see How to Replay DAT Files After an MTA Database Wipe via a
Remote Replay.
354
MTA Transport Stacks and X.400

Connectors
The X.400 standard is based on the Open Systems Interconnection (OSI) reference model as
defined in the X.200 recommendation. The Exchange MTA contains code for the top four
layers of the OSI stack (that is, application, presentation, session, and transport). Below the
OSI transport layer, the MTA relies on drivers installed in the operating system.
The OSI reference model is made up of seven layers, as illustrated in the following figure.
ITU standards in the OSI reference model
As indicated in this figure, the TCP/IP protocol does not fit exactly into the OSI stack. This is
because the TCP/IP protocol, although a layered protocol stack, is not OSI- compliant
(although most elements of TCP/IP can be mapped to OSI). TCP/IP was originally developed
by the Advanced Research Projects Agency (ARPA), based on a four-layer model, called the
TCP/IP model (sometimes called the Internet model). To support X.400 communication over
TCP/IP according to the OSI standard, the Exchange MTA implements a Transport Protocol
Class 0 (TP0) interface on top of TCP/IP, as defined in RFC 1006.
The Exchange MTA can also use RPCs as a transport mechanism to communicate with LAN-
MTAs and XAPI gateways. RPCs represent a communication mechanism at the application
layer, because the RPC runtime library includes presentation and session services. However,
in the context of the MTA stack, RPCs implement an interface under the session layer. The
internal services of the RPC runtime are transparent to the MTA.
The X.25 protocol is an OSI-compliant protocol designed specifically for wide area network
(WAN) connections on packet-switching networks (such as a public X.400 provider). The MTA
355
transport interfaces directly with the X.25 protocol, because X.25 has a Transport Class 0
(TP0) protocol interface to the transport layer. On the OSI side of the data link layer, X.25
relies on the High-level Data Link Control - Link Access Procedure Balanced (HDLC - LAPB)
protocol. HDLC - LAPB is the protocol that the EICON X.25 card uses to communicate with
the synchronous modem that connects the server to the public X.25 network. X.25 is the
network protocol that operates on top of HDLC so that the local system can communicate
with the next node in the X.25 network. Exchange supports EICON X.25 cards only.
Note:
The OSI reference model defines five protocols in the transport layer, TP0 through
TP4. The protocols increase in complexity from 0 through 4. TP0 performs
segmentation and reassembly tasks without any error recovery. TP1 performs
segmentation and reassembly and error recovery. TP2 has multiplexing and de-
multiplexing capabilities. TP3 combines all the features of TP0, TP1, and TP2. TP4
adds reliable transport services to TP3. TP4 is basically the OSI equivalent of TCP
and is most often used by X.400 MTAs that are unable to use the TCP/IP protocol
(such as the earlier Microsoft Mail Gateway to X.400). Exchange Server 2003 does
not support TP4, because a TP4 protocol stack is not available for Windows
Server 2003. Registry parameters, such as TP4 control blocks and TP4 threads
that you can find under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMT
A\Parameters, are legacy parameters for Exchange Server 5.5 running on Microsoft
Windows NT (where a TP4 protocol was available). These settings have no relevancy
for Exchange Server 2003.
Message Transfer Service

The XFER IN and XFER OUT threads in the MTA process, depicted earlier in this section,
initiate the message transfer service of the MTA. The Message Transfer Service Element
(MTSE) uses the Reliable Transfer Service Element (RTSE) to send messages across a
connection to a remote MTA and the Association Control Service Elements (ACSE) to
establish and disconnect connections.
The messages that MTSEs exchange with each other are named P1 messages to indicate
their format. The P1 protocol defines the format of a message transfer envelope. The
envelope contains the actual message, plus routing and control fields, so that the MTSEs can
route and trace a message, and track message contents. The following figure illustrates an
example of a P1 message transfer envelope in the Aspirin tool. Aspirin is an ASN.1 parser
that you can find in the Exchange 2000 Server Resource Kit (available in bookstores). In
X.400, data is formatted using ASN.1 syntax.
356
A P1 message transfer envelope
The actual message is in the X400COM_Content part of the P1 envelope. The message is
usually formatted according to the P2/P22 protocol, which describes the format for
interpersonal messages. Exchange MTAs support other message formats, such as P772 and
P42 for military messages. The following table lists the message formats that the Exchange
MTA supports. However, it should be noted that not all of these formats conform to the X.400
standard. Some message formats are Exchange Server-specific.
357
Supported message formats in Exchange Server 2003
Format Content Type Object Identifier
MDBEF • Microsoft 2A864886F7140501

Database Encoding
Format (MDBEF).
• Microsoft-
defined and
registered content
type.
• Also referred to
as "MS Exchange
Contents."
• Does not
conform to X.400.
Can only be used
between Exchange
MTAs in the same
organization.
Public Folder MDBEF • Microsoft- 2A864886F7140502

defined content type
for public folder
replication
messages.
• Does not
conform to X.400.
Can only be used
between Exchange
MTAs in the same
organization.
P2 • Defined in 56010A00
X.400 of the 1984
conformance year.
• Defines the
format of an
interpersonal
message (IPM).
358
P22 • Defined in 56010A01

X.400 of the 1988
conformance year.
• Extends the
format of an
interpersonal
message (IPM), as
defined in X.400-84.
P772 • Military 2B1A00A236000401

message.
• Extends the
P22 protocol with
extensions defined
for Defense
Message System
(DMS) in "Allied
Communication
Publication (ACP)
123."
• These
extensions
(additional
properties) are
allowed by the
X.400 standard and
are typically only
exposed by DMS-
capable clients, and
STANAG 4406 v1.7
and v3 clients.
359
P42 • Secure military 60864801650201022A

message.
• Military
message that has
been digitally
signed, encrypted,
or signed and
encrypted using
Message Security
Protocol version 3
(MSP3) (encryption
only is not allowed
within DMS).
• Certificates are
X.509 and
analogous to an
S/MIME V1.
as "MSP3."
360
CSP • Common 608648016502010203

security protocol.
• Used within
DMS to define a
secure military
message.
• Military
message that has
been digitally
signed, or signed
and encrypted using
Message Security
Protocol version 4
(MSP4).
• Certificates are
X.509 and
analogous to an
S/MIME V3.
• Within the DMS

Program this is
referred to as
"ACP120" or
"MSP4."
361
TNEF • Transport 2A864886F7140502

Neutral Encoding
Format (TNEF).
• Microsoft-
defined and
registered content
type.
as "MAPI."
• Conforms to
X.400 because the
message and all its
attachments are
encapsulated and
attached to the
message itself as a
binary attachment.
• The receiving
client must be able
to decode TNEF,
otherwise the client
displays a useless
attachment called
Winmail.dat. For a
detailed discussion
of TNEF, see SMTP
Transport
Architecture.
The following figure illustrates how the P1 and P2 protocols map to the architecture of
362
Envelope and message protocols
Note:
The X.400 standard defines protocols for clients to interact with an MTA (P3) and a
message store (P7). However, these protocols are not used in Exchange
Server 2003. In Exchange Server 2003, clients do not communicate directly with the
MTA or use RPCs (such as the Queue Viewer snap-in). Client communication with
the Exchange store is based on MAPI or Internet protocols.
Reliable Transfer Service

When the MTSE wants to send a message to another MTA, it uses the Reliable Transfer
Service Interface (RTSI) to call the RTSE. The MTA contains a state machine that decides
which data packets to send through the RTSE. The RTSE then sends the packets. For
example, the MTA issues an RT_TRANSFER_REQUEST to the RTSE and the RTSE then
attempts to transfer the given message to the other MTA. After the message is sent, the
RTSE returns an RT_TRANSFER_CONFIRMED to the MTSE, so that the MTA can mark the
message as transferred. Details of the state machines are given in X.228.
The RTSE provides reliable data transfer by transforming the data into a string of octets. It
then breaks the string into segments named application protocol data units (APDUs), and
then hands each APDU to the presentation layer for delivery. The RTSE ensures that APDUs
arrive intact, without duplication, when they are transferred between MTAs. When a
connection is interrupted for any reason, the RTSE is responsible for retrying data transfer.
The RTSE supports smart recovery between APDUs by establishing checkpoints.
Checkpoints enable the RTSE to resume the APDU transfer at the point where the disruption
occurred, rather than retransmitting the entire APDU. Activity and minor synchronization
facilities of the session layer support interruption and possible resumption of data transfer, if
the underlying network connection is lost.
363
Note:
You can configure checkpoint size, window size, and recovery timeouts in the RTS
values of an X.400 connector or the MTA directory object.
The services offered by RTSE fall into the following three categories:
• Association establishment An association is a logical connection between two

MTAs that is used for the purpose of message transfer over a physical connection.
MTAs can establish multiple associations over a single physical connection to send
multiple messages concurrently. The RTSE uses an RT-OPEN REQUEST (RTORQ)
APDU to establish an association. An RT-OPEN-ACCEPT (RTOAC) APDU is used in
a positive response to the request to establish an association between two MTAs. On
the other hand, an RT-OPEN-REJECT (RTORJ) APDU is used in a negative
response to the request to establish an association.
• Data transfer The RTSE uses RT-TRANSFER APDUs for data transfer. The
dialog may be one-way or two-way alternate, depending on whether data is
transferred only from one MTA or in both directions by turns. Each association, over a
two-way alternate link, has a turn token that only one MTA can possess at a time.
When an MTA must send a message, but does not have the turn on an open
association, it must determine how many open associations are on the link. If there
are fewer than eight associations, the MTA attempts to open a new association on
which it has the turn. If there are already eight associations open, the MTA sends an
RT_TURN_PLEASE request over one of the associations. If the receiving MTA can
release the turn, it sends back an RT_TURN_GIVE response and the requesting
MTA is allowed to transfer the message. If the receiving MTA cannot release the turn,
it simply does not respond until it is ready to release the turn. In a two-way alternate
communication, the RTSE can use RT-TURN-PLEASE and RT-TURN-GIVE APDUs
to switch data transfer directions, as follows:
• RT-TURN-PLEASE If an MTA has the turn and receives an RT-TURN-

PLEASE request from the other MTA, the MTA issues a P-TOKEN-PLEASE
request primitive, so that the requesting MTA can become the sending MTA.
RT_TURN_PLEASE requests can have different priorities, which relate to the
priority of the message. Priority 0 is reserved for when an MTA wants to shut
down an association or when an MTA wants to send routing information.
• RT-TURN-GIVE If an MTA has the turn and receives an RT-TURN-GIVE

request primitive from a requesting MTA, it issues a P-CONTROL-GIVE
request primitive and becomes the receiving MTA.
• Association termination The RTSE uses RT-CLOSE, RT-U-ABORT, and RT-

P-ABORT APDUs for ending of an association, as follows:
• RT-CLOSE An RTSE may issue an RT-CLOSE request when it has the

turn and if there are no outstanding RT-TRANSFER confirmations. When the
364
RTSE receives an RT-CLOSE response, the RTSE issues an A-RELEASE

packet to end the association.
• RT-U-ABORT This is an MTA-initiated cancellation, which is triggered

when the MTA wishes to cancel an association. For example, an MTA of the
1984 conformance year can cancel an association if the other MTA overtaxes
the MTA by using X.400 features of the 1988 conformance year.
• RT-P-ABORT This is a provider-initiated cancellation of an association,

which is triggered when recovery from a communication failure is not
possible. For example, receiving data packets in invalid states (such as
sending an APDU without first establishing an association) leads to an RT-P-
ABORT.
The Exchange MTA uses an RTS thread pool to handle the RTSE level of the OSI stack. You
can control the number of RTS threads using the following registry parameter.
Caution:
own risk.
Set\Services\
Value RTS threads
Type REG_DWORD
Value Data 0x1
Description Determines the number of RTS threads.

multiple MTAs, either within a routing group
or between routing groups.
Note:
If the RTS threads setting is too
high, RTS threads might overload
other threads in the OSI stack, thus
causing a message transfer
slowdown.
365
Association Control Service

The Association Control Service Element (ACSE) is a component of every connection-
oriented application entity in the OSI model (such as an X.400 MTA) that must establish an
application-to-application (MTA to MTA) association for data transfer over a connection. An
association establishes a context for the communication between the MTAs. For example, if
one MTA process sends data to the other MTA, the other MTA must be able to interpret the
data and respond correctly. MTAs can establish multiple associations over a single physical
connection to transfer multiple messages concurrently.
ACSE offers two types of services to the RTSE:
• Association establishment Association establishment is provided by the A-

ASSOCIATE service.
• Association termination Association termination is provided by three services:
• A-RELEASE This is the normal release mechanism used to end an

association.
• A-ABORT This is an unconfirmed (abrupt) cancellation of an

association.
• A-P-ABORT This is an unconfirmed (abrupt) cancellation of an

association similar to A-ABORT. The difference is that A-P-ABORT indicates
to the remote MTA that the association has been broken by service providers
at lower OSI layers.
Each connection between two MTAs can have up to ten associations, and because each
association is effectively a conversation, up to ten messages can be sent simultaneously over
a single X.400 connector. Two of the ten associations are reserved for sending urgent
messages. Each MTA holds the turn on one of the two associations and never releases the
turn. If a remote MTA attempts to establish more than eight concurrent associations for
messages with normal priority, the Exchange MTA refuses the additional associations and
logs an event with the event ID 58 in the application event log. The following is an example of
this event:
Event Type: Warning
Event Source: MSExchangeMTA
Event Category: X.400 Service
Event ID: 58
Date: 04/01/2004
Time: 4:27:34 AM
User: N/A
Computer: SERVER01
366
Description:
The /O=TAILSPIN TOYS/OU=FIRST ADMINISTRATIVE GROUP/CN=CONFIGURATION/CN=SERVERS/CN=
SERVER01/CN=MICROSOFT MTA entity has reached the per-entity receive association limit
of 8, equal to 80 percent of the total 10. [MTA XFER-IN 36 34] (12)
Note:
The Exchange MTA has a total limit of 2,050 associations over all connections
(including X.400 connectors, RPC connections to LAN-MTAs, and XAPI sessions).
This limit is hard coded and cannot be changed.
Presentation and Session Services

The presentation service provider provides the RTSE with a basic data transfer service to
deliver RT-TRANSFER APDUs to remote MTAs. The presentation service provider packs the
APDUs from the higher level to presentation protocol data units (PPDUs), and the service
provider at the session layer adds further information to the data packets to create valid
session protocol data units (SPDUs).
The first information sent over the presentation layer is a P-ACTIVITY-START indication. If
the message is large, the MTA might have to send more than one P-DATA packet. P-DATA
packets are not confirmed by the receiving MTA, so the sending MTA also sends P-MINOR-
SYNCHRONIZE indications between the P-DATA packets. The receiving MTA confirms the
minor sync points using P-MINOR-SYNCHRONIZE confirm primitives. However, minor sync
points do not have to be confirmed immediately. There is a window size that sets how many
minor sync points can be outstanding at any time. After the entire message has been
transferred, a P-ACTIVITY-END request is sent. When the receiving MTA confirms the P-
ACTIVITY-END, the RTSE passes a RT_TRANSFER_CONFIRMED primitive back to the
MTA, and the MTA marks the recipients as processed.
This transfer procedure is driven by the following events in the presentation layer:
1. RT-TRANSFER request.
2. P-ACTIVITY-START indication, followed by one or more P-DATA packets each,

except for the last, which is followed by a P-MINOR-SYNCHRONIZE indication.
3. P-MINOR-SYNCHRONIZE confirmation.
4. P-ACTIVITY-END indication.
5. P-ACTIVITY-END confirmation.
The RTSE also requires synchronization services provided by the session layer for protection
against data loss. Specifically, the RTSE must distinguish between data that was delivered
successfully to the receiving MTA and data that failed to reach its intended destination, in
which case the RTSE might request the retransmission of the data.
367
To handle the presentation and session services in the OSI stack, the Exchange MTA uses a
pool of kernel threads. You can control the number of kernel threads through the following
registry parameter:
Set\Services\
Value Kernel threads
Type REG_DWORD
Value Data 0x1
Description Determines the number of MTA kernel

threads that handle the presentation and
session level of the OSI stack.
The default value is 0x1. Adjust if this MTA

communicates with LAN-MTAs using RPC
over slow or highly latent network
connections.
Recommended setting:
• 0x3 The standard

recommendation.
• 0x8 If the Exchange

Server 2003 MTA belongs to a
routing group containing more than
15 Exchange 5.5 servers.
• 0xC (12) If the Exchange

Server 2003 MTA belongs to a
routing group containing more than
30 Exchange 5.5 servers.
MTA Transport Stacks

To enable the Exchange MTA to communicate with remote X.400 MTAs, using the OSI
transport stack, you must define several OSI addresses at the network, transport, session,
and presentation layers. This is accomplished through MTA transport stacks. You can install
transport stacks in Exchange System Manager when you right-click the X.400 configuration
object, point to New, and then click TCP/IP X.400 Service Transport Stack or X.25 X.400
Service Transport Stack. A dialog box appears, in which you specify a network address (that
368
is, a host name, IP address, or X.121 address), Transport Service Access Point (TSAP),
Session Service Access Point (SSAP), and Presentation Service Access Point (PSAP). Enter
the TSAP, SSAP, and PSAP in the T Selector, S Selector, and P Selector boxes,
respectively.
TSAP, SSAP, and PSAP are optional parameters on an Exchange server, because the
Microsoft Exchange MTA Stacks service does not share the OSI stack with other MTAs. If,
however, the remote MTA uses OSI address information to connect to the local MTA, you
must define these parameters for the local MTA. Otherwise, communication cannot take
place. It is possible to overwrite the OSI address information per X.400 connector. X.400
connector configuration parameters are discussed later in this section.
Note:
X.400 MTAs that operate according to the 1984 conformance year support only
TSAPs. SSAPs and PSAPs should not be specified.
To support X.400 connectors, you must install one of the following two MTA transport stacks:
• TCP/IP Transport Stack TCP/IP is a good choice for X.400 message transfer
over the Internet and over intranets. The TCP/IP transport stack implements ISO
transport services on top of TCP/IP, as defined in Request for Comments (RFC)
1006. When you install and configure a TCP/IP transport stack, you create a
configuration object in Active Directory that defines the service access points and
other settings that the MTA uses. Transport stack objects are located in the
configuration directory partition under the MTA directory object. You can use the
following LDIFDE command to export all TCP/IP transport stacks configured on all
servers in an Exchange organization to a file named Stacklist.ldf: ldifde -f
c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft
"(objectClass= rFC1006Stack)"
The following table describes the important attributes of the TCP/IP transport stack.
Important attributes of the TCP/IP transport stack object
Attribute Description
objectClass Indicates the class of the directory object as

rFC1006Stack.
nAddressType Indicates the type of information in the

nAddress attribute. The address information
can be a host name or an IP address.
nAddress Specifies the host name or IP address of

the local Exchange MTA.
369
tSelector Specifies the TSAP in the stack's OSI

address information.
sSelector Specifies the SSAP in the stack's OSI

pSelector Specifies the PSAP in the stack's OSI

supportingStackBL Lists the distinguished names of X.400

connectors that use this transport stack.
x400SelectorSyntax Indicates the type of information in the

tSelector, sSelector, and pSelector
attributes. The OSI address information can
be a hex value or a decimal value.
name Specifies the name of the transport stack

object as displayed in Exchange System
Manager.
• X.25 Transport Stack You must install an EICON X.25 card on the server
running Exchange Server 2003 and the EICON WAN drivers in Windows
Server 2003 to support X.400 connectors over X.25. The X.25 configuration is very
complex and can be completed only by using the configuration utilities that come with
the EICON X.25 card. The X.121 address (comparable to a telephone number) is the
most important information that must be configured. X.121 address data, call user
data, and facilities data that you specify in the X.25 transport stack must match the
EICON card configuration, as specified by your X.25 provider.
You can use the following LDIFDE command to export all X.25 transport stack objects
configured on all servers in an Exchange organization from Active Directory to a file
called Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First
Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com"
-p subtree -r "(objectClass= x25Stack)"
The following table describes the important attributes of the X.25 transport stack.
Important attributes of the X.25 transport stack object

x25Stack.
nAddress Specifies the local X.121 address.

370
x25CallUserDataIncoming Specifies the call user data for the X.25

adapter.
x25FacilitiesDataIncoming Specifies the facilities user data for the X.25

adapter.
x25LeasedLinePort Specifies the X.25 adapted port number.



supportingStackBL Lists the distinguished names of X.400

connectors that use this transport stack.
x400SelectorSyntax Indicates the type of information in the

tSelector, sSelector, and pSelector
attributes. The OSI address information can
be a hex value or a decimal value.

object as displayed in Exchange System
Manager.
MTA Communication Example

The following figure illustrates how an MTA opens a connection through RTSI and the OSI
stack. Each transfer of data between MTAs must travel down one side of the OSI stack
through the session and transport layers and back up the stack on the other MTA. When an
MTA sends a message through the OSI stack, the MTA either sends a request or a response.
A request arrives at the other MTA as an indication, and a response appears as a
confirmation.
371
Establishing a connection between two MTAs
To handle the communication at the transport layer in the OSI stack, the Exchange MTA uses
transport threads. You can configure the number of transport threads that the MTA uses
through the following registry parameter.
Set\Services\
Value Transport threads

372
Type REG_DWORD
Value Data 0x1
Description Determines the number of transport

threads.

remote MTAs over multiple X.400
connectors.
X.400 Connectors
In a distributed environment, communication conflicts can occur if the communicating MTA
processes are not carefully coordinated. For example, the Exchange MTA is a 1988 X.400
MTA, and must scale back its features when communicating with a 1984 MTA.
Note:
All Exchange versions include 1988 X.400 MTAs. The Microsoft Mail for PC Networks
Gateway to X.400 is an example of a 1984 X.400 MTA.
Configuring an X.400 Connector

To understand the features that a remote X.400 MTA supports, you must configure an X.400
connector to that remote MTA. First, ensure that you have configured an appropriate MTA
transport stack, and then, in Exchange System Manager, expand the routing group in which
you want to add the X.400 connector, right-click Connectors, point to New, and then click
either TCP X.400 Connector or X.25 X.400 Connector, according to the configuration of
your server.
The following figure shows the Properties dialog box for a sample X.400 connector.
373
Property tabs of an X.400 connector
You will see a dialog box, as shown in Figure 7.12, which has the following tabs:
• General This tab is used to define a name, the remote X.400 MTA and
password, and the transport stack. You can also use this tab to specify whether
remote clients support MAPI and whether to allow public folder referrals.
• Schedule This tab is used to set the communication schedule. Never, Always
(communication occurs constantly), Selected Times (up to 15-minute intervals), and
Remote Initiated may be configured.
• Stack This tab is used to specify required address information, such as remote
host name or IP Address (or X.121 address), and service access points for the
remote system.
• Override This tab is used to override default X.400 attributes of the local MTA.
• Address Space This tab is used to define the type and format of routing
addresses. Cost values are associated with address spaces to optimize routing. In
374
addition, you can specify whether this connector is available to the entire organization
or restricted to the local routing group.
• Advanced This tab is used to specify X.400 message formats and transfer
procedures when sending messages to a remote X.400 system or server running
Exchange.
• Content Restrictions This tab is used to specify which message types can
traverse the connector according to priority (High, Normal, or Low), message type
(System Messages or Non-System Messages), and message size (Allowed Sizes).
• Details This tab is used to specify an administrative note for information

purposes.
• Connected Routing Groups This tab is used to specify the names of remote
routing groups that can be reached through this X.400 connector.
• Delivery Restrictions This tab is used to specify who can send messages over
this connector. By default, messages are accepted from everyone.
Connect Request Information

Every X.400 connection is a secured connection. This means that one MTA attempting to
contact another MTA must identify itself within the connect request. The identification
information includes name and password for the local and remote MTA. If this information
does not match the configuration of the remote X.400 system, the connection request is
refused, and messages are not transferred.
You can specify the name and password of the local MTA, from the server's Protocols
container, in the X.400 object's Properties. The administrator of the remote MTA must ensure
that this information is also specified correctly on the remote MTA. Also, to configure your
local MTA correctly, you must get the name and password of the remote MTA from the remote
administrator. To specify the name and password of the remote MTA, from the General tab,
click Modify.
Note:
The MTA password is case-sensitive. If it is misspelled, connections cannot be
established.
Especially when connecting to a public X.400 network, you might be forced to override the
name and password of the local MTA on a per-connector basis. Public X.400 carriers usually
provide the required information that you must use. To adjust the configuration on a per-
connector basis, use the Override tab. Also, you can adjust the various X.400 protocol
parameters from this tab, such as Maximum Open Retries and Maximum Transfer Retries,
which are discussed earlier in this section.
375
Outgoing and Incoming OSI Address

Information
To specify how a remote MTA should be contacted, in the connector properties, on the Stack
tab, configure the OSI address information. Most importantly, you must specify the network
address of the remote MTA (IP address, host name, or X.121 address) and any TSAPs,
SSAPs, or PSAPs, if they are defined on the remote MTA. The values on the Stack tab all
refer to the remote system. The local OSI address information is specified in the MTA
transport stack, as explained earlier. If you have not specified any OSI address information in
the local MTA transport stack, the Exchange MTA expects the same TSAP, SSAP, or PSAP
values as defined in the outgoing OSI address information for the remote MTA. For more
information about OSI address configurations, see Microsoft Knowledge Base article 152934,
"XCON: X.400 Connector Stack Property Page Behavior."
X.400 Addresses
X.400 systems use a complex addressing scheme for message routing and delivery. The
most important X.400 address type is called a mnemonic originator/recipient (O/R) name or
O/R address. A mnemonic O/R address identifies a recipient based on country, administration
management domains (ADMD), and private management domain (PRMD). Further address
information, such as surname and given name, is required to form a complete address.
Every X.400 address must contain management domain information. A management domain
is basically a messaging network that is maintained by a single organization. This
organization can be a public operating agency (such as a telecommunications company) or a
private organization. As recommended by ITU-T, PRMDs handle internal messages, and
external messages destined to other PRMDs are always handled by public ADMDs (telecom
companies). In theory, PRMDs are supposed to communicate with each other through
ADMDs. However, in practice, PRMDs often bypass telecom-ADMDs to communicate directly
with each other (for example, using TCP/IP over the Internet), which lowers costs.
Note:
The fields for country, ADMD, and PRMD are mandatory. If a messaging network
does not have an ADMD, specify a single space character in the ADMD portion of
your X.400 addresses. A space in the ADMD part is synonymous for "any ADMD."
The following table lists the fields that can be used in an O/R name.
O/R attributes in an X.400 address
Label Abbreviation Attribute Type Example
C Country Country C=US;
A ADMD ADMD name A=MCI;

376
Label Abbreviation Attribute Type Example
P PRMD PRMD name P=TAILSPINTOYS;
S Surname Surname S=BREMER;
G Given Name Given name G=TED;
I Initials Initials I=TB;
Q Generation Generation qualifier Q=SR;
CN Common Name Common name CN=TED

BREMBER;
X.121 X.121 X.121 address X.121=49309872210

2
N-ID N-ID UA numeric ID N-ID=208973240
T-TY T-TY Terminal type T-TY=TTY;
T-ID T-ID Terminal identifier T-ID=309;
O Organization Organization O=EXCHANGE;
OU1 Org.Unit.1 Organizational unit 1 OU1=IT;
OU2 Org.Unit.2 Organizational unit 2 OU2=USA;
OU3 Org.Unit.3 Organizational unit 3 OU3=SEA;
OU4 Org.Unit.4 Organizational unit 4 OU4=DOWNTOWN;
DDA DDA Domain Defined DDA:SMTP=Ted@ta

Attribute ilspintoys.com
(DDA:type=value
attribute)
Note:
With the exception of the DDA field, O/R names are not case sensitive.
X.400 Address Spaces

Each X.400 connector must have at least one associated address space, which you can
specify on the Address Space tab. The routing engine uses this information to determine
possible connectors for a particular message, by comparing recipient addresses with
available address space information. When connecting to a remote X.400 system, you
typically configure X.400 address space. However, you can also associate an X.400
connector with other address types, for example, by specifying SMTP address information, as
377
shown in the following figure. A message sent to a matching SMTP recipient (such as
Ted@tailspintoys.com) is then routed through the X.400 connector. The Exchange MTA
converts the address information to an X.400 address using domain defined attributes (DDA),
as listed earlier in the table above.
Address spaces for an X.400 connector
When specifying non-X.400 address spaces, you must make sure that the receiving MTA can
handle the non-X.400 address information. For example, if the target X.400 system cannot
handle SMTP DDA information, assigning an SMTP address space to a X.400 connector that
points to this system is not a good idea. Messages are not transferred successfully in the
remote system. Some X.400 systems expect encapsulated SMTP address information, as
defined in RFC 2156 "MIXER (Mime Internet X.400 Enhanced Relay)," which describes a
method for mapping message formats and address information between RFC 822/MIME and
X.400. A corresponding DDA address portion looks like this: DDA:rfc-
822=Ted@tailspintoys.com. Exchange Server 2003 uses SMTP DDAs instead of RFC822
DDA and does not support MIXER.
378
Note:
Exchange Server 5.5 supports MIXER functionality. If you require this feature, you
should maintain an Exchange 5.5 bridgehead in your organization.
Conformance Year and Body Parts

Using the Advanced tab, you can specify X.400 features that should be enabled when
connecting the organization to a remote X.400 system. Important settings are the X.400
conformance year and X.400 bodypart. The MTA conformance year, for instance, must match
the conformance year of the external system, because significant differences exist between
1984 and 1988 X.400 standards. Otherwise, the local MTA overtaxes the remote MTA, and
communication problems occur.
The Advanced tab of an X.400 connector

379
Using the X.400 bodypart for message text list, you can also select a bodypart for the
message text as it will appear in the message body. A message can consist of several
bodyparts, which allows for e-mail attachments. The following table lists the bodyparts that
Exchange Server 2003 supports.
X.400 bodyparts of interpersonal messages
Bodypart Number Bodypart
0 IA5 text
1 Telex (ITA2 5-bit)
2 Voice
3 G3 facsimile
4 Text interchange format (TIFO)
5 Telex (T.61)
6 Videotex
7 Nationally defined
8 Encrypted
9 Forwarded IP message
10 Simple Formatable Document (SFD)
11 Text interchange format 1 (TIF1)
12 Octet string
13 ISO6937 text
14 Bilaterally-defined (binary)
15 Binary file transfer (first defined in 1988)
When connecting to a remote Exchange MTA in the same organization, you can select the
Allow Exchange Contents check box. The native Exchange format is not X.400 conforming,
but between Exchange MTAs this is not an issue. However, you must clear this check box
when communicating with an Exchange MTA that is external to the local Exchange
organization, because native Exchange content includes legacyExchangeDN address
information, which is only valid in the local organization. The recipients specified through
legacyExchangeDN addresses do not exist in the directory of the external Exchange MTA.
To send messages in Exchange format to Exchange users in external organizations, from the
General tab of the connector, select the Remote Client Supports MAPI check box. When
you select this check box, the Exchange MTA encapsulates the messages using Transport
Neutral Encapsulation Format (TNEF). The MTA converts the message to a plain text part
380
and an attachment in legacy TNEF. To learn more about TNEF, see SMTP Transport
Architecture.
Message Loop Detection

X.400 defines a concept of organizational boundaries, which influence how MTAs handle
trace information added to the P1 message transfer envelope for loop detection. Each MTA in
an organization adds trace information to indicate that the MTA has already transferred the
message. If a message reaches the same MTA twice, the MTA might determine that the
message is looping and drop it with a non-delivery report (NDR).
Trace information in a P1 message transfer envelope
An MTA can add the following two types of trace information to the P1 message transfer
envelope:
• External trace information External trace information identifies each X.400

domain that transferred the message. The X.400 domain is defined by a global
domain identifier is made up of the X.400 address fields country, ADMD, and PRMD.
The MTA adds external trace information to a message when the message reaches the
organization; for example, when the Exchange store submits a message to the MTA or
when the MTA receives a message from an MTA in another organization. If an MTA
receives a message from an external organization and encounters its own local global
381
domain identifier in the external trace information, a message loop between the
organizations is detected. The presence of the local global domain identifier indicates that
the local X.400 domain already handled the message and routed it to the other domain. If
the MTA accepts the message again, the message routes again to the other domain,
where it is routed back again to the local domain. This represents a message loop, and
the MTA must drop the message with an NDR.
Note:
The Exchange MTA does not remove external trace information from messages.
• Internal trace information Internal trace information identifies each MTA that
transferred the message within an organizational boundary. Internal trace information
is made up of the MTA name and information about routing actions (such as whether
the message was relayed or rerouted, or caused a distribution list (DL) expansion by
that MTA). If a message enters the same MTA twice, it might be dropped with an
NDR.
To detect message loops based on internal trace information, the MTA performs the
following steps:
a. The MTA reads the TraceInformation part of the P1 message transfer

envelope to determine if the MTA previously handled the message.
b. The MTA determines if the global domain identifier matches the local
global domain identifier. If this is the case, the MTA compares the local MTA
name with the names in the internal trace information.
c. If the local MTA name is not present, no message loop is detected. The
MTA stops checking at this point.
d. If the local MTA name is present, the MTA checks the routing action
information in the internal trace information. If no routing action is present,
the message was not transferred across the local domain and no message
loop is detected. The MTA stops checking at this point.
e. If the routing action indicates that the message was relayed, a message
loop is possible. The MTA then checks the other actions field to determine if
the message was rerouted or the distribution-list was expanded. If either
condition exists, the message might legitimately revisit an MTA, so it is not
dropped with an NDR. The remote replay scenario is another scenario in
which a message might legitimately revisit an MTA. This scenario is
explained in the section "Replaying DAT Files" in Exchange MTA in
Exchange Server 2003 Architecture.
f. However, if the message was relayed and no other actions are specified,
the MTA marks the message as looping and drops it with an NDR to inform
the message sender that the message did not arrive at its final destination.
382
The MTA adds internal trace information to the P1 message transfer envelope of all
messages it processes. However, when the MTA detects that the message is transferred to
an external X.400 domain, it must remove all internal trace information from the message
envelope, because between X.400 domains, only external trace information is used for loop
detection. To determine when to remove the internal trace information, the MTA compares its
local global domain identifier to the global domain identifier of the target MTA.
To determine its local global domain identifier, the Exchange MTA reads the default recipient
policy. Specifically, the Exchange MTA reads the country, ADMD, and PRMD information from
the primary X.400 address space defined in the default recipient policy to create the local
global domain identifier. You can configure the default global domain identifier for the
Exchange MTA in Exchange System Manager. Under Recipient Policies, display the
properties of the Default Policy, and then edit the X.400 e-mail address entry. By default, the
global domain identifier is c=US;a= ;p=<first 16 letters of the name of the Exchange
organization>.
Note:
The Exchange MTA determines the local global domain identifier when the MTA is
initializing, that is, when you start the Microsoft Exchange MTA Stacks service.
To determine the global domain identifier of the remote MTA, the local MTA reads the country,
ADMD, and PRMD information from the address space assigned to the X.400 connector on
the Address Space tab, but you can overwrite this information on the Advanced tab if you
click Global Domain Identifier. Click Specified Global Domain Identifier, and then define
the global domain identifier in terms of country, ADMD, and PRMD. Under ADMD (a), select
Any, if you want to allow the X.400 connector to use any ADMD, which corresponds to a
blank ADMD field. If you select Specific, you must type a value for the ADMD.
Note:
If, on the Advanced tab, you choose 1984 as the conformance for the X.400
connector, you must configure the global domain identifier explicitly.
X.400 Connector Objects in Active Directory

When you install and configure an X.400 connector, you create a configuration object in
Active Directory that defines the X.400 features and protocol parameters that the MTA must
use. Connector objects are located in the configuration directory partition under the
connector's routing group, in the Connections container. The routing engine reads this
information to initialize the link state table, as discussed in Message Routing Architecture
You can use the following LDIFDE command to export all X.400 connectors in an Exchange
organization named First Organization to a file called X400Connectors.ldf: ldifde -f
c:\X400Connectors.ldf -s localhost -d "CN=First Organization,CN=Microsoft
"(objectClass=x400Link)"
383
The following table describes the important attributes of X.400 connector objects.
Important attributes of X.400 connector objects
activationSchedule Specifies the activation schedule for this

X.400 connector.
activationStyle Specifies the activation style for this X.400

connector. (0=Never schedule, 1=Use
schedule)
aDMD Specifies the ADMD portion of a manually

defined global domain identifier.
associationLifetime Specifies the amount of time in seconds

that the system keeps an association open
to a remote X.400 MTA after a message is
sent.
c Specifies the country portion of a manually

delivEITs Specifies the deliverable message types in

encoded format according to the content
restrictions configured for this connector.
delivExtContTypes Specifies the object IDs for content types

supported by this connector.
gatewayLocalDesig Specifies the name of the remote X.400

MTA that the local MTA uses when
establishing a connection.
homeMTA Specifies the distinguished name of the

MTA that uses this X.400 connector.
lineWrap Specifies the number of characters in the

message text after which the MTA inserts a
line break.
localInitialTurn Specifies whether the local MTA or the

remote MTA has the initial turn on new
associations.
msExchConnectorType Designates this connector object as an

X.400 connector.
384
msExchEncryptedPassword Specifies the override password for the

local MTA.
Note:
The password is protected in Active
Directory, but X.400 MTAs transmit
MTA names and passwords in clear
text.
msExchEncryptedPassword2 Specifies the password, in encrypted form,

that the local MTA must use when
establishing a connection to the remote
X.400 MTA.
Note:
The password is protected in Active
Directory, but X.400 MTAs transmit
MTA names and passwords in clear
text.
msExchNoPFConnection Specifies whether public folder referrals are

allowed over this X.400 connector. This
setting is relevant only if this connector is
used to connect to another routing group in
the same Exchange organization.
mTALocalDesig Specifies the override name for the local

MTA.
nAddress Specifies the host name or IP address of

the local Exchange MTA.
nAddressType Indicates the information type in the

nAddress attribute. The address information
can be a host name or an IP address.

object, as displayed in Exchange System
Manager.
numOfOpenRetries Specifies the maximum number of times

that the Exchange MTA tries to open a
connection before it sends a non-delivery
report (NDR).
385
numOfTransferRetries Specifies the maximum number of times

that the Exchange MTA tries to transfer a
message across an open connection.

x400Link. The following object classes are
derived from this class:
• rFC1006X400Link TCP/IP
X.400 connectors
• x25X400Link X.25 X.400

connectors
openRetryInterval Specifies the number of seconds that the

system waits after an error, before
attempting to reopen a connection.
pRMD Specifies the PRMD portion of a manually


routingList Specifies the address spaces configured for

this X.400 connector.
rTSCheckpointSize Specifies the amount of data (in kilobytes)

transferred before a checkpoint is inserted.
If an error occurs and the message must be
resent, the process restarts from the most
recent checkpoint. A value of zero indicates
that no checkpoints are inserted.
rTSRecoveryTimeout Specifies the amount of time after a broken

connection that the MTA waits for
reconnection before deleting the information
(with its checkpoints) and restarting the
transfer from the beginning.
rTSWindowSize Specifies the number of checkpoints that

can go unacknowledged before data
transfer is suspended. The window size has
no meaning if the checkpoint size is zero.
386
sessionDisconnectTimer Specifies the amount of time in seconds

that the Exchange MTA waits before
disconnecting a connection after all
associations over this connection are
cancelled.

supportedApplicationContext Specifies the object identifiers of application

contexts that an OSI application, such as
the Exchange MTA, supports.
supportingStack Specifies the distinguished name of the

MTA transport stack that the MTA uses to
communicate over this connector.
tempAssocThreshold Specifies the maximum number of queued

messages that the system can send to a
remote system. When this is exceeded, the
MTA opens another association.
transferRetryInterval Specifies the number of seconds that the

system waits after a message transfer fails
before re-sending a message across an
open connection.
transferTimeoutNonUrgent Specifies the amount of time in seconds per

sending an a non-delivery report (NDR) for
a non-urgent message.
transferTimeoutNormal Specifies the amount of time in seconds per

sending a non-delivery report (NDR) for a
normal message.
transferTimeoutUrgent Specifies the amount of time in seconds per

sending a non-delivery report (NDR) for an
urgent message.
translationTableUsed Specifies the translation table that the MTA

uses to encode the message text.
387
transportExpeditedData Specifies whether expedited data is

supported over the X.400 connector.
Expedited data bypasses the flow control
procedures and provides a means for
expediting the delivery of urgent data, such
as an abrupt disconnection request. When
an MTA requests the expedited data
service, the other MTA must agree to its use
on the connection. Otherwise, the feature is
not available.

twoWayAlternateFacility Specifies whether the MTA association is

one-way or two-way alternate.
x400SelectorSyntax Specifies the syntax of the P, S, and T

selectors. (0 or undefined=Hex, 1=Text)
Running Multiple X.400 Connectors

The maximum number of X.400 connectors that you can install on a single server running
Exchange Server varies depending on practical limits for each server, such as hardware and
network bandwidth. However, by default, Exchange 2003 is not optimized for numerous
X.400 connectors, because the server supports a maximum of 20 concurrent connections per
connector type (that is, TCP/IP and X.25). At ten associations per connector, this is two X.400
connectors over TCP/IP. If you configure 30 or more TCP/IP X.400 connectors on a central
bridgehead server, and all the associations are in use, event ID 9156 might appear in the
application event log:
Event ID: 9156
Type: Warning
Category: Resource
Description: A resource limit has been reached while attempting to open an

association. There are no free control blocks available for network type 1. The
configured count is 70. [BASE IL MAIN BASE 1 282] (10)
To support more than two X.400 connectors on a bridgehead server, you should increase the
number of control blocks by using the following registry parameter.
388
Set\Services\
Values TCP/IP control blocks
TP4 control blocks
Eicon X.25 connections
Type REG_DWORD
Value Data 0x14 (20)
Description Determines the maximum number of buffers

available for X.400 connections. It is best to
provide ten control blocks for each X.400
connector, plus one control block for an
incoming connection, if the maximum
number of associations is exceeded. For
example, if you have 30 TCP/IP X.400
connectors, set TCP/IP control blocks to
0x12D (301) for maximum performance.
To handle the communication load at the TCP/IP layer, you might also have to increase the
number of TCP/IP threads that the MTA uses, through the following registry parameter.
Set\Services\
Value TCP/IP threads
Type REG_DWORD
Value Data 0x2
Description Determines the number of MTA threads that

handle RFC1006 connections.
The default value is 0x2. This number is

multiplied by two for the two subtypes of
RFC1006 threads (driver and async notify).
The actual maximum number of control blocks that the Exchange MTA can use is 1,250, but
this number is taken from a pool of control blocks for the TCP/IP, TP4, and X.25 transport
389
stacks. The registry values indicated correspond to TCP/IP control blocks, TP4 control blocks,
and X.25 control blocks, respectively. By default, all of these values are set to 20 decimal, so
the TCP/IP control blocks value can be increased up to 1,210 decimal without creating a
problem. This permits a maximum of 121 TCP/IP X.400 connectors on a single server, each
using the maximum number of allowable associations. This number is theoretical. The
capacities of the bridgehead server might limit the actual number of X.400 connectors.
It is unlikely that each X.400 connector will process enough mail to require the maximum
number of associations for each connector. Furthermore, if the X.25 transport stack is not in
use, you can reduce the Eicon X.25 connections parameter to a value of zero, thus
increasing the available control blocks for the TCP/IP stack by 20. However, TP4-based
X.400 connectors are not supported in Exchange Server 2003, and reducing the TP4 control
blocks does not allocate additional control blocks for TCP/IP.
If you set the maximum number of pooled control blocks too high, the Microsoft Exchange
MTA Stacks service cannot start, and the following event is logged in the application event
log:
Event ID: 4300
Type: ERROR
Category: Configuration
Unable to initialize due to a bad configuration. Contact Microsoft Technical Support.

Error code=<variable> [1 POP4 MAIN BASE 1] (16)
Connecting Routing Groups Using X.400

Connectors
It might be a good idea to use X.400 connectors between routing groups, particularly over
unreliable network links. X.400 is advantageous because it supports graceful recovery of
transfer associations. In many situations, message transfer can be resumed from the
interruption point. Also, the X.400 connector does not inflate message size, because it
transfers message content in native Exchange format without conversions. In contrast,
routing group connectors and SMTP connectors must convert messages to RFC 822 and
Multipurpose Internet Mail Extensions (MIME) format. This causes a 30 percent size
increase. To specify remote routing groups for an X.400 connector, in the connector
properties, use the Connected Routing Groups tab.
390
Load Balancing between Routing Groups

The local and remote MTAs of an X.400 connector are the only bridgehead servers that the
connector can use in each routing group. If you want multiple bridgehead servers, you must
configure additional X.400 connectors to point to different remote MTAs in the target routing
group. A single server can support multiple X.400 connectors, each using the same or
different MTA transport stacks. However, you can also configure multiple X.400 connectors on
multiple servers, as illustrated in the following figure.
Multiple bridgehead servers and X.400 connectors between two routing groups
Note, however, that Exchange Server 2003 does not perform true load balancing over
multiple connector instances. As explained in Message Routing Architecture, the advanced
queuing engine calls the routing engine to determine a message route one time, caches this
information, and then transfers all messages of the same type over the same connector.
Additional connectors are used only if the first connector fails. However, a second server
might select the second connector and in this way balance the load to some degree.
Note:
Because the routing engine cannot differentiate between local and remote
connectors, it is possible for the advanced queuing engine on one bridgehead server
in the local routing group to transfer all messages for the target routing group to
another bridgehead server in the same local routing group, even if the local server is
also a bridgehead server that could transfer the message.
391
Message Routing over Exchange MTAs

In an Exchange organization in which messages are transferred through Exchange MTAs,
message routing is performed twice by the routing engine. The first routing event occurs in
the advanced queuing engine. The routing engine informs the advanced queuing engine that
a message must be routed through a connection controller by the Exchange MTA, and the
advanced queuing engine places the message in the message queue for the MTA. The
Exchange store driver places the message in the MTS-IN folder for the MTA in the Exchange
store. The Exchange store then passes the message to the MTA, using an SMTP XAPI
gateway. The following event example shows a message passed to the MTA as just
described. The relevant information is in boldface.
Event ID: 272
Type: Information
Category: X.400 Service
Object 0600002D received from entity

/DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST
ORGANIZATION/CN=CONNECTIONS/CN= , object is a Normal priority Message, the MTS
identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4, and content
length is 1719. The number of objects sent so far = 1. External trace information
(first 100 bytes) =
3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D
3034303530333136303234315A8201008302060000000000. (10)
SMTP XAPI Gateway

From an Exchange MTA viewpoint, the SMTP service performs similar to a MAPI-based
connector, such as Connector for Lotus Notes or Connector for Novell GroupWise. The
Exchange MTA obtains messages from the SMTP XAPI gateway through the gateway's MTS-
IN folder and routes messages to this gateway through the gateway's MTS-OUT folder.
These message queue folders exist in the SMTP mailbox. The name of the SMTP mailbox is
SMTP (<server name> - {<GUID of the mailbox store>}). In the event above, the mailbox
name is SMTP (SERVER01-{43D5C017-4A4B-4AFD-85AF-06EAB90057AA}). A
corresponding connector object for the XAPI gateway exists in Active Directory in the
Connections container, directly under the Exchange organization object. This container is not
displayed in Exchange System Manager, but you can view it using ADSI Edit or export its
contents using LDIFDE. For example, you can use the following command line to export all
SMTP XAPI gateway objects into a file called SMTPXAPI.ldf: ldifde -f c:\SMTPXAPI.ldf -s
localhost -d "CN=Connections,CN=First Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -r
"(objectClass=mailGateway)".
392
The following table describes the important attributes of the SMTP XAPI gateway object.
Important SMTP XAPI gateway attributes
objectClass Identifies the directory object as a

mailGateway and msExchConnector object.
Common name Represents the name of the connector

object in Active Directory, relative to its
parent container.
computerName Points to the bridgehead server that is

running the SMTP service. This attribute
must exactly match the network basic
input/output system (NetBIOS) name for the
bridgehead server, otherwise the Queue
Viewer snap-in in Exchange System
Manager is not able to display the message
queues.
deliveryMechanism Identifies the delivery mechanism that is

used by Exchange Server 2003 to pass
messages to the XAPI gateway.
distinguishedName Represents the distinguished name of the

connector object in Active Directory.
homeMDB Identifies the private mailbox store that

holds the connector mailbox.
homeMTA Identifies the Exchange MTA that is

responsible for message routing to the
XAPI gateway.
legacyExchangeDN Represents the distinguished name of the

connector object in the earlier Exchange
Server 5.5 directory format. This attribute
must be set on the connector object for the
Queue Viewer snap-in to work.
delivExtContTypes Lists the object IDs for content types

supported by this connector.
Name Represents the name of the connector

object.
393
canPreserveDNs Indicates whether the connector object can

handle distinguished names in recipient
information.
Exchange MTA Message Transfer

The following figure illustrates how the SMTP service and the Exchange MTA interact with
each other.
394
Message transfer through the Exchange MTA
After receiving a message from the SMTP XAPI gateway, the MTA must determine a suitable
connector to transfer the message to the next hop. In Exchange 2000 Server and Exchange
Server 2003, the MTA no longer performs actual message routing, but contacts the routing
395
engine through MTARoute.dll, which then routes the message. However, the MTA might
change the O/R recipient names to a form that can pass to the routing engine.
The MTA does not call the routing engine for messages it receives from LAN-MTAs, X.400
MTAs, or MAPI connectors. It passes these messages straight to the MTS-OUT folder of the
SMTP XAPI gateway. The advanced queuing engine, in turn, then handles the messages and
calls the routing engine if a message is not directed to local recipients. In fact, a message
might transfer back to the Exchange MTA through the Exchange store and SMTP XAPI
gateway, if it must transfer to another LAN-MTA, X.400 MTA, or non-Exchange messaging
system. The SMTP service sets a flag on all messages that it transfers to the Exchange MTA,
to indicate that the MTA should call the routing engine. For detailed information about the
message routing process, see Message Routing Architecture.
If the routing engine can determine a next hop for a message, the MTA determines whether
the next hop is reached through the local SMTP service. It is possible, for example, that an
X.400 connector and a routing group connector both point to the same routing group. If this
occurs, the advanced queuing engine might pass the message to the MTA for transfer over
the X.400 connector, and the MTA might then pass the message back to the SMTP service
for transfer over the routing group connector, and so forth. To avoid this situation, the MTA
calls the routing engine a second time if the initial routing suggests that the MTA should send
the message back to the SMTP service. The MTA passes the recipient's X.400 proxy address
in the initial routing call and the legacyExchangeDN in the second routing call, with the
expectation that this will yield a different route than the route through the SMTP service.
Link State Information and Message Rerouting

If the routing engine can determine a next hop for a message, it returns the routing object
name of a connector or MTA back to the MTA. The MTA converts this routing object name to
a distinguished name to determine the connector or MTA directory object that the MTA must
use for message transfer in Active Directory. The directory object defines the delivery
mechanism and communication parameters.
If the routing engine cannot determine a next hop due to a temporary link failure, the routing
engine flags the message to inform the MTA that it must reroute the message the next time
link state information changes. As explained in Message Routing Architecture, link state
information changes when you change the connector configuration in your organization or
when the advanced queuing engine or MTA marks a connector as down or up. The link state
algorithm ensures that updates to link state information are propagated to all servers in the
organization that are running Exchange Server 2003.
When the routing engine on the local server discovers that link state information is changed, it
calls the RoutingReset() function of the MTA. The MTA then calls the routing engine on all
messages that are routed but not yet sent, to perform rerouting. Until the routing engine
receives updated link state information from its routing group master, routing calls result in a
temporary error, and the MTA places the messages in a Pending Reroute queue. The
396
rerouting succeeds when the link state information is synchronized across the entire routing
group.
Note:
Frequent changes to link state information can cause message transfer problems in
the Exchange MTA. For example, messages might be dropped with non-delivery
reports (NDRs) indicating unrecognized O/R names. In an environment with
unreliable network connections, you might have to disable the propagation of link
state information, as discussed in Message Routing Architecture.
Exchanging Link State Information Between

Routing Groups
In an Exchange organization with routing group connectors, link state information is
exchanged between routing groups using SMTP. If X.400 connectors are deployed to connect
routing groups, then link state information must be exchanged over X.400 also. To
accomplish this task, the Exchange MTA calls the routing engine to obtain the current MD5
digest, which is an encrypted signature that represents the version number for the link state
table. Based on this information, routing engines determine whether they have the same link
state information.
Before sending messages, the local MTA sends the GUID attribute of the Exchange
organization and the current MD5 digest in a DIGEST_QUERY packet to the remote MTA.
When the remote MTA recognizes the DIGEST_QUERY packet, it passes the information to
its routing engine. The routing engine compares the digest with its own digest copy, and
passes the comparison results back to its MTA. The remote MTA then sends the response
back to the local MTA.
397
An example of a digest query and a query response
If the MD5 digests on the servers running Exchange Server differ, then a more detailed
conversation follows between the MTAs to exchange OrgInfo packets. The OrgInfo packet
contains the link state table, with all details and states of the routing topology. The MTAs pass
the OrgInfo packets to their local routing engines, and the routing engines determine which
server has the most up-to-date information. The server with the most up-to-date information
discards the received OrgInfo packet. The other server passes the updated link state
information to its routing group master, and the routing group master updates the link state
information on all servers in its local routing group.
Exchange MTAs transfer digest queries even if they connect to MTAs outside the local
Exchange organization. The receiving routing engine checks the organization GUID in the
DIGEST_QUERY packet to determine if the link state information is from the local
organization and ignores the MD5 digest if it is from a different organization. The query
response indicates that no OrgInfo packets must be exchanged.
Exchange MTA in a Mixed-Mode

Organization
The Exchange MTA is a critical component in a mixed-mode organization for backward
compatibility with servers running Exchange Server 5.5. Within the local site, Exchange
Server 5.5 MTAs communicate directly with each other using remote procedure calls (RPCs),
398
and Exchange Server 2003 must use the same mechanisms. MTAs and RPCs are also used
over routing group connectors that have a server running Exchange Server 5.5 as a remote
bridgehead (that is, a routing group connector operates as a site connector in Exchange 5.5).
RPC-Based MTA Communication

Communication through RPCs does not require you to configure an OSI transport stack or an
X.400 connector. When Exchange components communicate directly with each other, all
parameters are known. For example, Exchange Server 2003 MTAs do not require you to
configure a connector when communicating with servers running Exchange 5.5 Server in the
local routing group. The Exchange MTA also communicates with the Exchange store through
XAPI to transfer messages to the SMTP service and MAPI-based connectors that have their
message queues in the Exchange store. This communication is based on MAPI, which is an
RPC-based API. When you view messages in MTA message queues by using the Queue
Viewer snap-in in Exchange System Manager, this communication is also based on RPCs.
The Exchange MTA uses an RPC thread pool to support communication with LAN-MTAs, the
Exchange store, and administrative tools. You can control the minimum and maximum
number of RPC threads by using the following registry parameters.
Set\Services\
Value Min RPC Threads
Type REG_DWORD
Value Data 0x4
Description Determines the minimum number of RPC

threads that the RPC runtime library should
create and maintain for the MTA process.
The default value is 0x4.
Set\Services\
Value Max RPC Calls Outstanding
Type REG_DWORD
Value Data 0x32

399
Set\Services\
Description Determines the maximum number of RPC

threads. This limits the maximum number of
RPC calls that are guaranteed to be
processed at one time.
The default value is 0x32 (50). The

recommended value is 0x80 (128) in
Exchange Server 5.5 and Exchange
Server 2003 co-existence scenarios. The
Max RPC Calls Outstanding value should
not be zero, and should be larger than Min
RPC Threads.
If you increase the maximum number of

RPC threads, you should also increase the
number of gateway in and gateway out
threads for each mailbox store in the
Exchange store process using the Gateway
In Threads and Gateway Out Threads
registry parameters under
HKEY_LOCAL_MACHINE
\System\CurrentControlSet
\Services\MSExchangeIS\<server_name>
\Private-<database_guid>, as explained
earlier in this section.
RPC Performance Impact

You must make sure that there are no RPC communication issues on your bridgehead server.
For example, you should not have servers running Exchange Server 5.5 that are down
frequently in the routing group of the bridgehead server. Because RPC communication is
performed synchronously, the MTA must wait for a timeout to expire before the MTA can
service other outbound connections, which take precedence over incoming connections.
Thus, RPC communication problems can degrade the performance of the entire MTA,
including all X.400 connectors. In contrast, X.400 connectors establish asynchronous
connections, which have little to no effect on other connectors.
400
Note:
The MTA uses RPCs to transfer messages in and out of the Exchange store.
However, this RPC communication should not encounter any problems during normal
server operation and should not affect server performance.
RPC Bindback Error

Establishing an RPC connection is a bind-and-bindback process, in which the local MTA first
confirms that it is communicating with the remote MTA (the remote MTA name and password
are checked), and then the remote MTA confirms the identity of the local MTA (the local
MTA's name and password are sent back and checked). An Exchange MTA logs RPC
bindback errors when establishing RPC connections to a remote MTA that cannot resolve the
fully qualified domain name (FQDN) of the local MTA. When the remote MTA attempts to
bindback with the connection string that it was given, and cannot resolve the FQDN, the
bindback fails, and the following error is logged in the event log:
Event ID: 9322
Description: An interface error has occurred. An MtaBindBack over RPC has failed.
Locality Table (LTAB) index: %1, NT/MTA error code:1722. Comms error %3, Bind error
%4,Remote Server Name %5, Protocol String IP Address of Server.
When the bindback fails, the binding server does not receive a response from the remote
system. Eventually, the RPC run-time library encounters a timeout and logs the following
error in the event log:
Event ID: 9318
Source: MSExchangeMTA - Interface
Description: An RPC communications error occurred. Unable to bind over RPC. Locality
Table (LTAB) index: 151, NT/MTA error code: 1722. Comms error 1722, Bind error 1722,
Remote Server Name SERVERNAME [MAIN BASE 1 500 %10] (14)
To resolve this issue, you must make sure that the two MTAs both can resolve each other's
FQDNs to IP addresses.
Gateway Address Routing Table

To perform message routing, servers running Exchange Server 5.5 use Gateway Address
Routing Table (GWART), and servers running Exchange Server 2003 use link state
information. In a mixed-mode organization, Site Replication Service (SRS) replicates
Exchange Server 5.5 directory information with Active Directory. Therefore, servers running
Exchange Server 2003 can find all connectors in the configuration directory partition. The
routing engine can therefore include connectors installed on Exchange Server 5.5 in the link
401
state table. This gives Exchange Server 2003 users the ability to use connectors that are not
available in Exchange Server 2003, such as Connector for Lotus cc:Mail, Connector for
Professional Office System (PROFS), or Connector for SNA Distribution System (SNADS).
To enable servers running Exchange Server 5.5 to use connectors on Exchange Server 2003,
a GWART is generated that includes all connector information. Exchange Server 5.5 users
can then send messages to Internet users through SMTP connectors installed on Exchange
Server 2003. This is advantageous because all Exchange users can benefit from the spam
and connection filtering capabilities of Exchange Server 2003.
For backward compatibility, an Exchange Server 2003 MTA generates the GWART and
communicates with Active Directory through Active Directory Services Interface (ADSI) to
write the GWART object. The MTA writes the routing information in binary form to the
gatewayRoutingTree attribute and updates the gWARTLastModified attribute of the directory
object to indicate when the GWART was last updated. The GWART object resides in the
administrative group of the server running Exchange Server. The Site Replication Service
(SRS) replicates the GWART object to the Exchange Server 5.5 directory, and Exchange
Server 5.5 replicates the GWART to all servers running Exchange Server 5.5, so that these
servers can include Exchange Server 2003 connectors in their routing decisions.
You can use the following command line to export all GWART objects from an Exchange
organization: ldifde -f c:\GWART.ldf -s localhost -d " CN=Administrative
Groups,CN=First Organization,CN=Microsoft
"(objectClass=siteAddressing)".
The following table describes the important attributes of the GWART directory object.
Important attributes of GWART object
objectClass Identifies the directory object as a GWART

object, based on the siteAddressing object
class.
gatewayRoutingTree Contains the routing table in the format

required by Exchange Server 5.5 MTAs.
gWARTLastModified Specifies the date and time when the

GWART object was last updated.
ridServer Points to the server that maintains the

GWART for this administrative group.
402
Message Loops Between Exchange Server 5.5

and Exchange Server 2003
In a mixed-mode Exchange organization, you should not specify servers running Exchange
Server 2003 as expansion servers for distribution lists that contain Exchange Server 5.5
users. If an Exchange Server 5.5 user sends a message to such a distribution list, the
Exchange Server 5.5 MTA correctly forwards the message to the Exchange Server 2003
expansion server. In Exchange Server 2003, distribution list expansion is the job of the
categorizer in the SMTP service. However, the SMTP transport subsystem does not amend
the TraceInformation in the P1 message transfer envelope to mark the message as
distribution-list-expanded. After the distribution list is expanded, Exchange Server 2003
routes the message back to Exchange Server 5.5 for all Exchange Server 5.5 recipients. If
the message now revisits a server running Exchange Server 5.5 that already handled the
message, the message is dropped and a non-delivery report is generated. This occurs
because a loop is detected. SMTP has no concept of X.400 trace information, and the X.400-
based Exchange Server 5.5 MTA must drop the message, because the TraceInformation in
the P1 envelope does not indicate that this is a distribution-list-expanded message. To avoid
this issue, servers running Exchange Server 5.5 should be used as expansion servers for
distribution lists that contain Exchange Server 5.5 users.
Gateway Messaging Connectors

Architecture
In Microsoft Exchange Server 2003, there are two types of messaging connectors: native
connectors and gateway connectors. Native connectors include the Routing Group connector
(in Exchange Server 5.5, this is Site Connector), SMTP connector, and X.400 connector. You
can use these connectors to connect Exchange routing groups to each other. However,
because the SMTP connector and X.400 connector use standard protocols (that is, SMTP
and X.400), you can also use these native connectors as gateway connectors to non-
Exchange messaging systems.
Gateway connectors generally use non-standard protocols, or proprietary APIs to connect

Exchange to non-Exchange messaging systems, such as Novell GroupWise or Lotus Notes.
The gateway connectors provided with Exchange Server 2003 (that is, Exchange Connector
for Novell GroupWise and Exchange Connector for Lotus Notes) support directory
synchronization and message conversion. However, these are not the only gateway
connectors available. Non-Microsoft vendors use the Exchange Development Kit (EDK) to
develop proprietary gateway connectors for other types of messaging systems. Gateway
connectors based on the EDK rely on MAPI. For this reason, this section refers to gateway
connectors as MAPI-based connectors.

403
• General EDK connector architecture All MAPI-based connectors have

several characteristics in common. You must understand the EDK connector
architecture to evaluate how both Microsoft and non-Microsoft connectors integrate
with Exchange Server 2003. For detailed information about programming MAPI-
based connectors, see the Exchange 2000 Sample Gateway.
• Connector for Lotus Notes architecture This MAPI-based connector includes

components required for communication with Lotus Notes. You must understand how
these components interact with each other to understand how Exchange Server 2003
accomplishes message transfer and directory synchronization with Lotus Notes.
• Connector for Novell GroupWise architecture This MAPI-based connector

includes components required for communication with Novell GroupWise. You must
know how these components interact with each other to understand how Exchange
Server 2003 accomplishes message transfer and directory synchronization with
Novell GroupWise.
• Calendar Connector architecture Microsoft Exchange Server 2003

Calendar Connector does not transfer messages, as other connectors do. Instead,
this connector provides Exchange Server 2003 and Lotus Notes or Novell GroupWise
users with almost real-time access to each other's free/busy calendar information. If
you want to synchronize Exchange and non-Exchange free/busy information, you
must understand how the components of Calendar Connector integrate with
Connector for Lotus Notes and Connector for Novell GroupWise.
This section explains the architecture of MAPI-based connectors available in Exchange

Server 2003. MAPI-based connectors are exclusively used to connect an Exchange
organization to a non-Exchange messaging system, such as Lotus Notes or Novell
GroupWise. It is assumed that you are familiar with the configuration of connector
components in Exchange System Manager. For more information about how to connect and
migrate a non-Exchange messaging system to Exchange Server 2003, see the Exchange
Server 2003 Interoperability and Migration Guide.
EDK Connector Architecture

For seamless interaction between Exchange and non-Exchange users, connectors to non-
Exchange messaging systems must enable the following key tasks:
• Bidirectional message transfer E-mail message transfer is the most important

of all connector tasks. However, MAPI-based connectors do not perform message
routing in an Exchange organization. MAPI-based connectors obtain outbound
messages from a specific Exchange bridgehead server and transfer inbound
messages to this same bridgehead server. Message routing and delivery is then
404
performed in the SMTP transport subsystem. For detailed information about

Exchange Server 2003 message handling, see Message Routing Architecture.
On the non-Exchange side of a message transfer, message delivery and retrieval depend
on the features and programming interfaces that the non-Exchange messaging system
provides. Typically, only a single point of contact is used on this side of a message
transfer also. For example, Connector for Lotus Notes connects to only one Lotus
Domino server. It is up to the non-Exchange messaging system server to route messages
to their final destinations.
The following figure illustrates the typical steps that a MAPI-based connector must
perform to accomplish outbound and inbound message transfer.
Message transfer through a MAPI-based connector
Message transfer to and from a non-Exchange messaging system includes the following
steps:
a. Message transfer begins with obtaining messages from the source

system. MAPI-based connectors use MAPI to retrieve messages from
Exchange. On the non-Exchange side of the message transfer, message
retrieval is based on the programming interfaces that the non-Exchange
messaging system provides, such as Lotus Notes Client API or Novell
GroupWise API Gateway.
b. The next step in message transfer is converting the messages to the

format of the target messaging system. This step includes mapping
addresses and translating message formats from MAPI to non-Exchange
formats and vice versa.
c. The final step in message transfer is delivering the converted messages

to the target system. Again, EDK connectors use MAPI to deliver messages
to the Exchange store. On the non-Exchange side of the message transfer, a
proprietary programming interface, such as Lotus Notes Client API or Novell
GroupWise API Gateway, is used to accomplish the transfer.
405
• Directory synchronization Directory synchronization is the second most

important task that MAPI-based connectors perform. Directory synchronization is
optional but very useful, because it provides all users with access to complete
address lists that include the recipients in the Exchange and non-Exchange
messaging environments. In Exchange Server 2003, directory information resides in
the Microsoft Active Directory directory service, and directory synchronization is
performed using Lightweight Directory Access Protocol (LDAP) and Active Directory
Service Interfaces (ADSI).
• Performing support functions Message transfer and directory synchronization

are the most important tasks that a MAPI-based connector must perform. In addition,
support functions should be implemented to increase the level of integration with
Exchange Server 2003. Support functions include the following:
• Performance monitoring MAPI-based connectors provide performance
counters so that an administrator can create performance monitoring reports
using the Performance tool, available from Administrative Tools in the Start
menu.
• Event logging MAPI-based connectors track significant events (such as

connector service starts, stops, converts message, transfers message)
according to various diagnostics levels in the application event log. The
administrator can use the Event Viewer tool, available from Administrative
Tools, to determine if the connector is operating correctly. The application
event log is an essential information source when you troubleshoot message
transfer issues.
• Error handling MAPI-based connectors inform message senders about

transfer issues using delivery status notifications. For example, a connector
sends a non-delivery report (NDR) to the message sender if the connector
cannot handle a recipient due to a malformed address.
• Message tracking MAPI-based connectors track information about

messages that pass through the connector in the message tracking log files
of Exchange Server 2003, so that an administrator can analyze the complete
path that a message takes from the sender's server to the point where the
message leaves the Exchange organization. For inbound messages,
message tracking begins when the messages reach the MAPI-based
connector and enter the Exchange organization. By default, message
tracking is not enabled. You must enable this feature on each server for
which you want to track messages, or use a server policy. In Exchange
System Manager, in the server or server policy Properties, select the
General tab, and then select the Enable message tracking check box.
406
Connector Components
MAPI-based connectors consist of a variety of components that enable seamless integration
with Exchange Server 2003. These include configuration objects in Active Directory that hold
connector-specific settings and the actual connector applications that perform message
conversion and transfer. MAPI-based connectors also come with Microsoft Management
Console (MMC) snap-ins, which integrate with Exchange System Manager so that you can
perform system configuration tasks using a unified user interface.
MAPI-based connectors consist of the following components:
• Connector service Typically, MAPI-based connectors are implemented as

Microsoft Windows services that are running directly on the Exchange Server 2003
bridgehead server. Therefore, they start automatically when the server starts and run
in their own security context. In Exchange Server 2003, all services, including the
services of MAPI-based connectors, use the LocalSystem account, as discussed in
Exchange Server 2003 Services Dependencies.
Note:
Connector components can run directly on a server running Exchange
Server 2003 or on a separate computer that communicates with Exchange
Server 2003 over the network. The non-Exchange messaging system is usually
accessed over the computer network, although it might improve connector
performance if the non-Exchange messaging system is local to the connector
server. For example, it is possible to run both Exchange Server 2003 and Lotus
Domino on the same server.
• Conversion DLLs MAPI-based connectors can register conversion DLLs with

the Exchange Server 2003 framework for message translation, so that the
appropriate translation code is called when the connector converts inbound or
outbound messages. These DLLs must be registered in the registry, under the
HKEY_LOCAL_MACHINE\Software\Classes\MAPI Conversions key. A subkey
must then exist for each conversion DLL. The DLL subkey name must be the name of
the DLL file. These DLLs must be installed in the \System32 directory of the
bridgehead server. Each DLL key contains a subkey for each entry point in a
conversion DLL, which the conversion engine uses to perform the conversion.
Note:
Conversion DLLs are optional components. The code to perform message
conversions can also be embedded directly in a MAPI-based connector, in which
case conversion DLLs are not used. For example, Connector for Lotus Notes and
Connector for Novell GroupWise do not rely on conversion DLLs. The
mechanisms that these connectors rely on to perform message conversions are
covered in later sections.
407
• Proxy address generation DLL Proxy addresses are non-Exchange

addresses that the recipient update service assigns to Exchange recipient objects in
Active Directory. This enables non-Exchange users to send Exchange users e-mail
messages and vice versa. For example, the Exchange user Ted Bremer might have a
NOTES proxy e-mail address of Ted@Exchange. A Lotus Notes user can then use
this e-mail address to send Ted a message. In a Lotus Notes environment, Ted
appears to be a user in a Lotus Notes foreign domain called Exchange, which is
associated with Connector for Lotus Notes. Accordingly, Lotus Notes routes the
message addressed to Ted@Exchange to Connector for Lotus Notes. When
Connector for Lotus Notes retrieves the message, the connector performs address
translation and replaces the Lotus Notes (proxy) address of the Exchange user with
the actual Exchange address (the X.500 address of the user, as specified in the
legacyExchangeDN attribute). Similarly, Connector for Lotus Notes replaces Ted's
Exchange address information with his Lotus Notes proxy address information in all
outbound messages to Lotus Notes. The native Exchange Server 2003 address
format is SMTP.
Note:
Exchange users typically appear in non-Exchange messaging systems as regular
recipients who exist in the non-Exchange messaging systems.
To enable recipient update service to generate proxy addresses in the correct format,
MAPI-based connectors must install an appropriate proxy address generation DLL on the
server running Exchange Server 2003. Proxy address DLLs reside in subdirectories that
correspond to address types and computer processor types, under \Program
Files\Exchsrvr\Address. This subdirectory is shared for network access (share name:
\\<server name>\Address), so that the recipient update service can access the DLLs,
even if the messaging connector is installed on another server running Exchange Server.
You can read more about the recipient update service in Exchange Server 2003 and
Active Directory.
The following figure illustrates an example of proxy addresses that the recipient update
service assigned to an Exchange user.
408
Proxy addresses for an Exchange user
Users can have primary and secondary proxy addresses. For example, Figure 8.2 shows
a secondary Lotus Notes proxy address for Ted. The primary proxy address is used as
the sender address in all outbound messages to the non-Exchange messaging system.
Secondary proxy addresses are used to deliver inbound messages to the proper recipient
in Exchange Server 2003, when these messages are not addressed to the primary proxy
address. To continue the example, Ted can also receive Lotus Notes messages
addressed to Ted@Contoso, because this is Ted's secondary NOTES proxy address.
Note:
You can define proxy addresses for Exchange users in recipient policies in
Exchange System Manager. An Exchange user has only one primary proxy
address per address type but might have multiple secondary addresses. All proxy
addresses (primary and secondary) must be unique in the Exchange
409
organization. For example, there cannot be two Exchange recipients with a

NOTES proxy address of Ted@Contoso.
• addrType object Placing a proxy address generation DLL in a subdirectory

under \Program Files\Exchsrvr\Address on a server running Exchange Server 2003
does not cause recipient update service to generate proxy addresses for a particular
address type. To enable an address type, the connector must also register the
address type it supports in an addrType object in Active Directory. All addrType
objects reside in the configuration directory partition of Active Directory, in the
Address-Types container. You can view the content of this container using ADSI Edit.
You can also view this container in Active Directory Sites and Services when you
select the option Show Services Node on the View menu to display the services
node. The path to the Address-Types container is \Services\Microsoft
Exchange\<name of Exchange organization>\Addressing\Address-Types. By default,
addrType objects exist for CCMAIL, GWISE, MS, NOTES, SMTP, and X400.
The following table lists the important attributes of addrType objects.
Attributes of addrType objects
Attributes Description
Common-Name The common name of the Address-Type

that is used to build the distinguished name
of the object in Active Directory.
File-Version The version number of the proxy address

generator DLL file.
proxyGeneratorDLL The name of the proxy address generator

DLL used for this address type. For
example, the addrType object with the
common name NOTES:i386 specifies a
proxy address generator DLL called
Ntspxgen.dll in this attribute.
name The name of the address type, such as

NOTES:i386.
• Address templates In conjunction with the addrType object, MAPI-based

connectors might also install address templates and options templates to provide a
friendly interface that a user can use to create custom recipients for the non-
Exchange messaging system. These templates describe the settings on a dialog box
with which to enter custom addresses. Address templates work with an address
syntax program to convert the data entered by the user to a proxy address string. You
can customize the address templates in Exchange System Manager (in the Address
Templates container, under Recipients).
410
Note:
Address templates and address syntax programs are optional connector
components. Connector for Lotus Notes and Connector for Novell GroupWise do
not install these components.
• msExchConnector object More important than address templates is the actual

connector object that each MAPI-based connector must have in Active Directory. At
server startup, the routing engine enumerates and reads all msExchConnector
objects from all routing groups to initialize the link state table. This is explained in
Message Routing Architecture.
Connector objects reside in the Connectors container under their routing groups in
Exchange System Manager. A corresponding administrative snap-in is required to
configure the settings of the msExchConnector object. Settings include connector type-
specific attributes, in addition to general attributes.
Note:
In addition to the msExchConnector object in Active Directory, configuration
information can also be stored in the registry database on the bridgehead server.
The following table lists important general attributes that all MAPI-based connectors have
in common.
Important general attributes of msExchConnector objects
Common name Represents the name of the connector

object in Active Directory relative to its
parent container.
computerName Points to the bridgehead server that is

running the MAPI-based connector. This
attribute must match exactly the network
basic input/output system (NetBIOS) name
for the bridgehead server, otherwise the
Queue Viewer snap-in in Exchange System
Manager cannot display the connector's
message queues.
deliveryMechanism Identifies the delivery mechanism that is

used by Exchange Server 2003 to pass
messages to the MAPI-based connector.
distinguishedName Represents the distinguished name of the

connector object in Active Directory.
411
homeMDB Identifies the private store that holds the

connector mailbox.
homeMTA Identifies the Exchange MTA that is

responsible for message routing to the
MAPI-based connector.
legacyExchangeDN Represents the distinguished name of the

connector object in the earlier Exchange
Server 5.5 directory format. This attribute
must be set on the connector object for the
Queue Viewer snap-in to work.
msExchConnectorType Identifies the connector type. For example,

the connector type for Connector for Lotus
Notes is NOTES and the connector type for
Connector for Novell GroupWise is GWISE.
name Represents the name of the connector

object. Exchange System Manager uses
this name as the display name of the
connector object.
412
objectClass Identifies the connector as an

msExchConnector and a mailGateway. In
addition, a specific object class is registered
to identify the actual type of the connector.
For example, msExchNotesConnector is
the object class for Connector for Lotus
Notes and msExchGroupWiseConnector is
the object class of the gateway object for
Connector for Novell GroupWise.
Note:
To support connector-specific
attributes, MAPI-based connectors
from non-Microsoft vendors must
extend the schema of Active
Directory to create a new object
class. You should represent MAPI-
based connectors in Active
Directory by objects of a class that
inherits from the mailGateway
class. The mailGateway object, in
turn, is a sub-class of
msExchConnector.
routingList Identifies the address spaces associated

with this connector. Each connector has at
least one associated address space. The
routing engine uses this information to
determine possible connectors for a
particular message by comparing the
recipient addresses with available address
space information.
• Administrative snap-in MAPI-based connectors should add and register an

MMC extension snap-in to Exchange System Manager, so that Exchange
administrators can configure the connector's msExchConnector object in
Active Directory (and possibly registry settings) using a friendly user interface. For
example, Connector for Lotus Notes comes with an Exchange Notes Connector
snap-in and Connector for Novell GroupWise comes with an Exchange GroupWise
Connector snap-in. Both snap-ins are implemented in Exadmin.dll, as explained in
Exchange System Manager Architecture.
413
• Connector mailbox When an msExchConnector object is created in

Active Directory for a MAPI-based connector, Exchange Server 2003 creates a
special mailbox for the connector in the mailbox store that is specified in the
msExchConnector object's homeMDB attribute. The Exchange store creates this
special mailbox on the bridgehead server when the connector service is started for
the very first time or when the first message is routed to the connector. This mailbox
includes the inbound and outbound message queues of the MAPI-based connector,
named MTS-IN and MTS-OUT, and possibly other folders, named Badmail, ReadyIn,
and ReadyOut, Deferred Action, Spooler Queue, and Temp, that the connector might
use during message processing. For example, Connector for Lotus Notes and
Connector for Novell GroupWise place corrupted messages in the Badmail folder.
Whether additional folders beyond MTS-IN and MTS-OUT are used depends on the
actual connector implementation.
Note:
At a minimum, a connector mailbox must have an MTS-IN and an MTS-OUT
folder.
Message Transfer to and from Exchange

Server 2003
Whereas the processes that communicate with the non-Exchange messaging system are
specific to the individual connector type, all EDK connectors use MAPI to access their
connector mailboxes in the Exchange store. As illustrated in the following figure, the
Exchange message transfer agent (MTA) places messages addressed to the non-Exchange
messaging system in the MTS-OUT folder, and the MAPI-based connector places inbound
messages that it has retrieved and converted from the non-Exchange messaging system in
the MTS-IN folder. The Exchange MTA is discussed in detail in X.400 Transport Architecture.
Note:
Because the connector message queues are always available, MAPI-based
connectors are always marked as STATE_UP in the link state table and the
Exchange MTA continues to deliver messages to a MAPI-based connector even if the
connector service is not running. This can cause numerous messages to collect in
the MTS-OUT message queue.
414
Connector queues in the Exchange store
Outbound Message Transfer

Exchange Server 2003 performs the following steps to transfer messages to a non-Exchange
messaging system:
1. An Exchange user sends a message to a non-Exchange user. The message is

passed to the SMTP service for routing and transfer.
2. The SMTP service categorizes and routes the message, as discussed in

Message Routing Architecture. Because this message is for a non-Exchange user,
the routing engine assigns the message to the Exchange MTA. The Exchange MTA is
responsible for MAPI-based connectors to non-Exchange messaging systems.
3. The SMTP service passes the message to the Exchange MTA through the
Exchange store. The Exchange MTA places the message in an internal message
queue, which the MTA maintains separately from the Exchange store on the file
system (\Program Files\Exchsrvr\Mtadata).
4. The Exchange MTA communicates with the routing engine in the SMTP transport
subsystem through MTARoute.dll to determine the target MAPI-based connector.
415
5. The routing engine identifies, by address spaces, the MAPI-based connector that
handles the recipient and returns this information to the Exchange MTA.
6. The Exchange MTA wraps the message in a message transfer envelope (MTE)
and places it in the target MAPI-based connector's MTS-OUT folder. The message
transfer envelope contains a list of recipients to whom the MAPI-based connector
must deliver the message, plus the original message in the form of an attachment.
Note:
A MAPI-based connector can determine when an outgoing message arrives in its
MTS-OUT folder by polling the connector mailbox periodically or by waiting for an
Advise event from the Exchange store that signals a new outbound message.
Inbound Message Transfer

On the Exchange side of a message transfer, inbound message delivery requires fewer steps
than outbound message transfer. When a MAPI-based connector places an inbound
message in the MTS-IN folder, the Exchange MTA passes the message directly to the SMTP
transport subsystem for categorization, routing, and delivery, without performing message
routing itself.
Inbound message transfer is accomplished through the following steps:
1. The MAPI-based connector obtains a message from the non-Exchange

messaging system, performs address translation for intended recipients, converts the
message into MAPI format, and then places the message in its MTS-IN folder in the
Exchange store.
2. The Exchange MTA analyzes a special message property that is set only when
the message comes from the SMTP service. Because this flag is missing, the MTA
recognizes that the message is not from the local SMTP service, which indicates that
it is an inbound message for which the Exchange MTA does not need to perform
message routing. The MTA passes the message straight to the SMTP service's MTS-
OUT folder.
3. The Exchange store driver places the message into the pre-submission queue
and the SMTP transport subsystem categorizes, routes, and delivers the message,
as discussed in Message Routing Architecture and SMTP Transport Architecture.
MAPI Profiles for MAPI-Based Connectors

Similar to typical MAPI clients, such as Microsoft Office Outlook, MAPI-based connectors
require a MAPI profile to access their connector mailboxes. The MAPI profile defines the
settings that the MAPI subsystem uses to communicate with the Exchange store. MAPI-
based connectors use the MAPILogonEx function to create the required profile dynamically
416
and without the need for a MAPI client on the server. For detailed information how to create
MAPI profiles dynamically, see Microsoft Knowledge Base article 306962, "How to Create
MAPI Profiles Without Installing Outlook."
MAPI profiles are stored in the registry under the HKEY_USERS hive. Several subkeys exist
on a bridgehead server, according to the security identifiers (SIDs) of system accounts and
user accounts that the active server processes and administrators use to log on to the
system. In Exchange Server 2003, MAPI-based connectors should run in the context of the
LocalSystem account, which has an SID of S-1-5-18. Accordingly, you can find the MAPI
profile of a MAPI-based connector at the following location: HKEY_USERS\S-1-5-
18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging
Subsystem\Profiles. For example, if you installed and started Connector for Novell
GroupWise on a bridgehead server named Server01, you can find a subkey named
SERVER01-LME-GWISE V5.5 under the Profiles key.
It is possible to copy the connector profile to the subkey of the administrator who is currently
logged on and then use a low-level MAPI tool to open the connector mailbox. Mdbvu32.exe is
such a low-level MAPI tool, available for download from the Downloads for Exchange
Server 2003 Web site.
The Information Store Viewer.doc file that comes with the tool contains detailed information
about how to use the Mdbvu32.exe tool. The following figure shows the Mdbvu32.exe tool in
action. You can see all the system folders in the connector mailbox.
417
System folders in a connector mailbox
For detailed instructions about how to open a connector mailbox using Mdbvu32.exe, see
How to Open a Connector Mailbox Using Mdbvu32.exe.
Message Conversion
When a MAPI-connector retrieves a message from the connector mailbox, it must convert the
message from MAPI format to the format of the target messaging system before it transfers
the message. Similarly, the connector must convert inbound messages from the format of the
non-Exchange messaging system to MAPI format before placing the message in its MTS-IN
folder. Message conversion includes the following two separate processes:
• Address translation A MAPI-based connector must perform address

translation for message sender and all recipients of a message, so that the message
is passed to the target messaging system with correct address information in
supported formats.
418
• Message translation Message translation is the process by which a gateway

connector converts messages between the MAPI message format and a non-
Exchange system message format. This translation is based on message class
information and is done for both inbound and outbound messages.
Address Translation
A MAPI-based connector must perform address translation for all inbound and outbound
messages. The following t three recipient lists are associated with each message that a
MAPI-based connector handles:
• The original list of recipients The list of recipients on the message itself
contains all the recipients to whom the message is addressed. Some of these
recipients might have their mailboxes on the local Exchange server, on another
server in the Exchange organization, or on a messaging system not associated with
the connector. In Exchange Server 2003, the original list of recipients is processed by
the SMTP transport subsystem. The same principle applies to inbound messages. A
message might be addressed to recipients on other servers in the non-Exchange
messaging system, in addition to Exchange users.
• The list of recipients sent to the MTA The SMTP transport subsystem passes
a message only to the MTA, if the message contains recipients to whom the MTA
must deliver the message either directly through remote procedure calls (RPCs),
through an X.400 connector, or through a MAPI-based connector. The recipient list
that the SMTP transport subsystem passes to the MTA might include all recipients or
only a subset of the original list. For example, if a user sends a message to another
user on the same Exchange server and a Lotus Notes user, the SMTP transport
subsystem will deliver the message to the Exchange user directly, but pass another
instance of the message for the Lotus Notes user to the Exchange MTA.
• The list of recipients on the message transfer envelope The Exchange MTA
only passes those messages to a MAPI-based connector that the connector must
transfer. When the Exchange MTA passes a message to a MAPI-based connector, it
creates a message transfer envelope (MTE) to which the MTA adds the original
message as an attachment. The MTA contains information about the recipients to
whom the connector must deliver the message. The Exchange MTA might deliver a
message using several connectors. In this case, a particular connector is not
responsible for all recipients in the list that the SMTP transport subsystem passed to
the MTA.
The following table lists the elements of the MTE.

419
Properties of the message transfer envelope
Properties Description
Per-message properties Many of these properties are native MAPI

properties that define the date and time that
the message arrived at the connector, the
entry ID of the message, subject ID,
originator information, and trace
information.
Trace information indicates the message

path. Each time the Exchange MTA routes a
message, it adds the country/region code,
the administrative management domain
(ADMD), and the private management
domain (PRMD) of the local domain to the
message. The MTA also adds time stamps
and an action flag that indicates whether
the message was expanded, redirected,
relayed, or rerouted. Trace information is
critical for preventing message transfer
loops.
Per-recipient properties For each recipient in the MTE recipient

table, these properties indicate the recipient
type, whether a delivery status notification
is requested for the recipient, whether the
message sender requests the MTA to
attach a physical forwarding address for a
recipient, whether the message sender
requests proof of delivery for a recipient,
and diagnostic codes that can be used as
part of a non-delivery report (NDR).
Attachment properties These MAPI properties identify the type of

attached object and specify how the
contents of the attachment can be
accessed.
Proxy Addresses and One-Off Addresses

Address translation for message sender and recipients is based on proxy addresses. All
Exchange users must have a proxy address of the required type, so that the MAPI-based
connector can perform a lookup in Active Directory and insert the correct non-Exchange
420
address in the message envelope of the outbound message. For inbound messages, the
translation is performed in the opposite direction.
If address information for a non-Exchange sender or recipient does not exist in

Active Directory, the MAPI-based connector must create one-off addresses for these users.
The term "one-off" indicates that something is used only once and not retained permanently.
One-off addresses are used in one message only and are not retained for reuse in other
messages. The one-off address format is defined by MAPI as follows: Display name[Address
type:E-mail address], such as Ted Bremer[NOTES:Ted@Exchange].
One-off addresses can also be used to encapsulate non-Exchange addresses. For example,
if a user sends a message to a Lotus Notes user and a user on the Internet, the user on the
Internet might not have a recipient object in Active Directory with a NOTES proxy address, in
which case Connector for Lotus Notes cannot map the Internet user directly and must
encapsulate the SMTP address in a one-off NOTES address to ensure that all recipients
specified in the outbound Lotus Notes message appear in the non-Exchange system in a
supported format.
Address Mapping Issues

If a MAPI-based connector cannot map the sender address or a recipient address, it must
perform the following tasks:
• Sender address If the MAPI-based connector cannot convert the Exchange

address of a sender into non-Exchange format, the connector must generate an
NDR. The connector must mark as undeliverable each recipient of the message that
the connector is required to handle. This occurs because the connector cannot
generate a return address for replies to the message. The NDR is returned to the
message sender to signal that no recipient was reached.
• Recipient address in target system If the MAPI-based connector cannot

determine the address of a recipient that the connector is required to handle, the
connector must generate an NDR for this recipient to inform the message sender that
the message did not reach all intended recipients.
• Recipient address not in target system If the MAPI-based connector cannot

determine the address of a recipient that the connector is not required to handle (for
example, a recipient in a messaging system that is not connected by this connector),
the connector does not generate an NDR. The connector must preserve as much
address information as possible, by using address encapsulation. The connector can
also drop the recipient from the message, or place the recipient information in a
purely textual field.
421
Message Conversion
Exchange Server 2003 uses message classes to define which properties a message
contains, the type of information the message conveys, and how the message can be
handled. Each message class has an associated set of properties, and because different
MAPI message classes support different sets of properties, multiple algorithms must be used
to convert a MAPI message to the message format of the non-Exchange messaging system.
Similarly, if the message format of the non-Exchange messaging system supports its own
message classes, separate translation algorithms are necessary to handle these message
classes.
To handle a message class, the connector converts outgoing messages to an appropriate

format (when the non-Exchange messaging system has an analogous message class) and
converts incoming messages to an appropriate MAPI message class. The connector also
generates the various REPORT message classes when an incoming or outgoing message
requires them. In addition to handling a message class, the connector also converts message
attachments.
The following table lists the message classes that MAPI-based connectors must handle.
Message classes that MAPI-based connectors must handle
Message Class Description
ENVELOPE.{Message Class} The MTE that contains the message. The

standard message class that is enclosed in
the MTE is IPM.NOTE. This message
object can be opened with the MAPI
IMessage interface.
Note:
In addition to the ENVELOPE
message class, MAPI-based
connectors must handle the
standard message classes, such as
IPM.NOTE, which are enclosed in
the MTE to perform message
conversions.
422
REPORT.{Message Class}.NDR The NDR. The MAPI-based connector

generates an NDR when message delivery
fails. For example, the connector might be
unable to determine addresses for message
sender or required recipients or might be
unable to connect to the non-Exchange
messaging system. Or, the non-Exchange
messaging system might return an NDR,
because a specified recipient does not
exist. The NDR is returned to the original
sender, and the original message and its
recipient list are included in the NDR as an
embedded message attachment.
REPORT.{Message Class}.DR The delivery report. Delivery reports are

optional reports that provide various
amounts of information about the delivery of
the original message, depending on the
non-Exchange messaging system. If the
non-Exchange messaging system does not
support delivery reports, the MAPI-based
connector can generate a delivery report
when it successfully transfers a message to
the non-Exchange messaging system. This
type of report indicates to the sender only
that the non-Exchange messaging system
accepted the message.
REPORT.{Message Class}.IPNRN The interpersonal note receipt notification.

Read receipts are optional report
messages, similar to delivery reports. Read
receipts inform a sender that a recipient has
read a message. Read receipts are
generated by the messaging client of the
recipient. Not all non-Exchange messaging
systems support these reports.
423
REPORT.{Message Class}.IPNNRN The interpersonal note non-receipt

notification. Non-read receipts are similar to
read receipts, only they inform a sender that
a recipient deleted a message without
opening it. Non-read receipts are generated
by the messaging client of the recipient. Not
all non-Exchange messaging systems
support non-read receipts.
Directory Synchronization
MAPI-based connectors, such as Connector for Lotus Notes and Connector for Novell
GroupWise, support directory synchronization, which establishes a consistent global address
list across all messaging systems. MAPI-based connectors must also ensure that directory
information stays current in both directories. For example, if you change or delete a user in
the non-Exchange messaging system, the corresponding recipient object must also be
changed or deleted in Active Directory. Therefore, the MAPI-based connector uses MAPI to
interact with the Exchange store, but it uses ADSI to interact with Active Directory.
Directory synchronization is made up of two separate, sequential processes:
1. Synchronizing recipients from a non-Exchange messaging system to

Active Directory.
2. Synchronizing recipients from Active Directory to a non-Exchange messaging

system.
Directory Synchronization from a Non-

Exchange Messaging System to an Exchange
Organization
Directory synchronization from a non-Exchange messaging system to an Exchange
organization involves the following sequential processes:
1. Extracting directory information from the non-Exchange messaging

system MAPI-based connectors use the programming interfaces that the non-
Exchange messaging system provides to extract the directory information from the
non-Exchange messaging system. For example, Connector for Lotus Notes uses the
Lotus Notes Client API to accomplish this step, and Connector for Novell GroupWise
uses administrator messages, which it passes to Novell GroupWise API Gateway.
424
2. Preparing the directory information for an import to Active Directory MAPI-

based connectors create the following types of recipient objects for non-Exchange
users in Active Directory:
• Disabled mail-enabled user accounts This is a good choice if the

non-Exchange users are not yet in the Active Directory environment, but will
be in the environment after migration to Exchange Server 2003.
• Enabled mail-enabled user accounts This is a good choice for non-

Exchange users who work in your Active Directory environment, even though
they do not have an Exchange mailbox.
• Mail-enabled contacts This is a good choice for non-Exchange users

who are not, and never will be, in the Active Directory environment. Internet
users in external messaging systems are an example.
A MAPI-based connector can synchronize distribution lists as contact objects. This is an

advantage because the connector does not need to maintain distribution list membership
information in Active Directory. However, messages sent to a distribution list must then
first be transferred to the legacy messaging system for distribution list expansion, before
the messages can be delivered to the individual recipients. If the distribution list contains
recipients that refer back to users in the Exchange Server 2003 organization, messages
must travel back to the Exchange Server 2003 organization after the distribution list
expansion. To avoid this unnecessary message transfer, you might choose not to
synchronize distribution lists. If the number of distribution lists is manageable, you can
create mail-enabled groups in Active Directory and specify the individual members
directly. In this case, Exchange Server 2003 can perform the distribution list expansion
immediately and without the overhead of additional message transfer to the legacy
messaging system. Groups in Active Directory can contain any type of recipient objects,
such as user accounts, contacts, or other groups.
3. Importing the directory information to Active Directory MAPI-based

connectors use ADSI to create mail-enabled user accounts or mail-enabled contacts.
Both Connector for Lotus Notes and Connector for Novell GroupWise import recipient
information to a single target organizational unit in Active Directory. The target
organizational unit, where the MAPI-based connector places the recipient objects that
are created during directory synchronization for non-Exchange users, is also named
the import container. There can be only one import container.
Note:
The computer account of the Exchange Server 2003 bridgehead server running
the MAPI-based connector requires permissions to create and modify recipients
in the selected import container.
The following figure illustrates the general process for transferring directory information from
a non-Exchange messaging system to an Exchange organization.
425
Directory synchronization from a non-Exchange messaging system to Active Directory
Directory Synchronization from an Exchange

Organization to a Non-Exchange Messaging
System
Directory synchronization from an Exchange organization to a non-Exchange messaging
system follows the same principle as directory synchronization from a non-Exchange
messaging system to an Exchange organization. The MAPI-based connector must extract
information about mailbox-enabled user accounts from one or multiple organizational units
(also named export containers) in Active Directory by using ADSI, process the information,
and then import, update, or delete the information in the non-Exchange directory. For
Active Directory to non-Exchange directory synchronization to work, the non-Exchange
messaging system must contain directory information for users who are outside the local
messaging system. Most messaging systems support this functionality. For example,
Exchange users appear in Lotus Notes as users in a Lotus Notes foreign domain. In addition
to exporting mailbox-enabled user accounts from Active Directory, MAPI-based connectors
also support exporting contacts and groups, which then appear as regular Exchange
recipients in the non-Exchange directory.
426
Note:
The computer account of the Exchange Server 2003 bridgehead server running the
MAPI-based connector requires permissions to access and read recipient information
in the selected export container.
The following figure illustrates the general process for transferring directory information from
Active Directory to a non-Exchange messaging system, based on ADSI and non-Microsoft
APIs or import tools, which place the recipient objects in the non-Exchange directory. The
APIs and tools that a MAPI-based connector uses to import directory information to a non-
Exchange directory depend on the non-Exchange messaging system. For example,
Connector for Lotus Notes accomplishes directory imports into Lotus Notes using the Lotus
Notes Client API, while Connector for Novell GroupWise uses administrator messages, which
it passes to Novell GroupWise API Gateway.
Directory synchronization from Active Directory to a non-Exchange messaging system

427
How to Open a Connector Mailbox Using

Mdbvu32.exe
This topic explains how to use Mdbvu32.exe, a low-level MAPI tool, to open the connector
mailbox after you have copied the connector profile to the subkey of the administrator who is
currently logged on.
Before You Begin

• Mdbvu32.exe is available for download from the Downloads for Exchange

Server 2003 Web site.
Caution:
any valuable data.
Procedure
To open a connector mailbox using Mdbvu32.exe
1. Ensure that the MAPI-based connector is started.
2. Open Regedit and locate the subkey of the connector under

HKEY_USERS\S-1-5-18\Software\Microsoft\Windows
NT\CurrentVersion\Windows Messaging Subsystem\Profiles.
3. Right-click the key that represents the connector's MAPI profile and select
Export. For example, export the SERVER01-LME-GWISE V5.5 key if you want
to examine the message queues of Connector for Novell GroupWise.
4. Export the key to a .reg file, and then close the registry editor.
5. Open the exported .reg file in Notepad and replace all occurrences of
HKEY_USERS\S-1-5-18 with HKEY_CURRENT_USER.
6. Save the changes and close Notepad.
7. Double-click the .reg file and in the dialog box that informs you that you are
about to import settings into the registry, click Yes. In the dialog box that informs
428
you that this step is complete, click OK.
8. Ensure that the administrator account with which you are working is not a
member of the Enterprise Admins or Domain Admins group. Temporarily, add
your account to the Exchange Domain Servers group to gain access permissions
for the connector mailbox.
9. Start Mdbvu32.exe and in the MAPILogonEx dialog box, click OK.
10. In the Choose Profile dialog box, select the MAPI profile of the connector,
such as SERVER01-LME-GWISE V5.5, and then click OK.
11. From the MDB menu, select OpenMessageStore. In the Select Message
Store To Open dialog box, verify that the MAPI-based connector is selected, and
then click Open.
12. From the MDB menu, select Open Root Folder, and in the MAPI_FOLDER
- Root dialog box, double-click on the system folder that you want to examine,
such as MTS-IN.
13. Close Mdbvu32.exe and remove your account from the Exchange Domain
Servers group.
Connector for Lotus Notes Architecture

Connector for Lotus Notes can connect an Exchange organization to a Lotus Notes and Lotus
Domino network. Lotus Notes releases 3 and 4 and Lotus Domino releases 4.5, 4.6, 5, and 6
are supported with Exchange Server 2003 Service Pack 1 (SP1). This MAPI-based connector
uses the Lotus Notes Client API to communicate with a Lotus Notes or Lotus Domino server.
This requires a Lotus Notes client on the connector server. A license from Lotus Development
is required to use the client software. For information about how to install and configure
Connector for Lotus Notes, see the Exchange Server 2003 Interoperability and Migration
Guide.
Note:
Because Connector for Lotus Notes uses the Lotus Notes Client API to communicate
with a Lotus Notes or Lotus Domino server, the connector requires a dedicated Notes
ID that has permissions to access Lotus Notes databases.
The following table lists the important components of Connector for Lotus Notes.
429
Connector for Lotus Notes components
Component Description
Connector mailbox As a MAPI-based connector, Connector for

Lotus Notes locates its message queues in
a connector mailbox in the default mailbox
store on the bridgehead server. The
mailbox name is Connector for Lotus Notes
(<server name>), such as Connector for
Lotus Notes (SERVER01).
430
Connector service The main executable of the Connector for

Lotus Notes service is called Dispatch.exe.
This is a process controller that is started
using the parameters -cexchconn.ini
-nLME-NOTES -pCONTROL-SERVICE
-l"C:\Program Files\Exchsrvr\bin" -vLME-
NOTES to dispatch the various tasks of
message transfer and directory
synchronization to other processes, based
on the settings from an Exchconn.ini file.
Exchconn.ini is created automatically, as
part of the connector installation and
configuration.
The following components are involved in

information handling:
• Dxanotes.dll This component

checks the Lotus Domino Directory
for recipient updates. This
component also transfers
Exchange address information
changes to the Lotus Domino/Notes
address book.
• Dxamex.dll This component

checks Active Directory for recipient
updates. This component also
transfers Lotus Domino/Notes
address information changes to
Active Directory.
• Lsdxa.exe This is the

directory exchange manager that
controls both Dxanotes.dll and
Dxamex.dll.
• Lsmexin.exe This component

obtains converted messages from
the READYIN folder in the
connector mailbox, verifies the
validity of the recipients, and places
the messages in the MTS-IN
queue.
• Lsmexnts.exe This
431
Lotus Notes databases Connector for Lotus Notes uses the

following databases on the Lotus Notes and
Domino bridgehead server:
• Exchange.box This is the

connector mailbox in Lotus Notes
and Domino that stores messages
being routed from Lotus Domino to
Exchange. You must create a
foreign domain document to
register the Exchange organization
as an external domain in the Lotus
Domino Directory and specify the
name of the connector mailbox in
this document. All mail routed from
Lotus Domino to Exchange
Server 2003 is then sent to the
connector mailbox, from which it is
retrieved by Connector for Lotus
Notes. The connector needs
Manager permissions with Delete
rights to pick up mail from this
database and to run database
maintenance operations.
• Exchange.bad This is the

connector mailbox for badmail that
Connector for Lotus Notes uses to
store any messages that fail to
transfer to Exchange Server 2003.
The connector needs Manager
permissions with Delete rights to
move badmail to this database and
to run database maintenance
operations.
• Mail.box This is the server

mailbox of the Lotus Domino
server. Connector for Lotus Notes
uses this mailbox to deposit all
messages from Exchange
Server 2003 that are bound for
Lotus Domino mailboxes. The
connector needs Depositor
432
Connector store Connector for Lotus Notes uses a folder

structure on the file system to maintain
control files used during directory
synchronization. Control files are schema
definition files and mapping rule files, which
determine how attributes in one directory
are mapped to the other directory. The
connector store is located in the \Program
Files\Exchrvr\Conndata directory.
You can edit the following schema definition

files and mapping rule files in Notepad to
determine how attributes in one directory
are mapped to the other directory:
• AMAP.TBLin the \Dxamex

subdirectory Defines the
Exchange mailbox attributes to be
synchronized.
• AMAP.TBLin the \Dxanotes

subdirectory Defines the Lotus
Notes attributes to be
synchronized.
• MAPMEX.TBLin the
\Dxanotes
subdirectory Determines the
attribute mapping from Exchange
Server 2003 to Lotus Notes.
• MAPNOTES.TBLin the
\Dxamex
subdirectory Determines the
attribute mapping from Lotus Notes
to Exchange Server 2003.
For detailed information about customizing

the directory synchronization between Lotus
Domino and Exchange Server 2003, see
Microsoft Knowledge Base article 180517,
"XFOR: Customizing Directory
Synchronization Between Exchange and
Notes."
433
Registry settings In the Registry, settings for Connector for

Lotus Notes are stored in the following
location:
HKEY_LOCAL_MACHINE\SYSTEM\Curren
tControlSet\Services\LME-NOTES.
Proxy address generation DLL The proxy address generation DLL of

Connector for Lotus Notes is named
Ntspxgen.dll and resides in the \Program
Files\Exchsrvr\address\notes\i386 directory.
addrType object The common name of the addrType object

of Connector for Lotus Notes in
Active Directory is NOTES:i386.
434
msExchConnector object The msExchConnector object of Connector

for Lotus Notes in the configuration
directory partition of Active Directory stores
most of the connector configuration
settings. The following attributes are
specific to the msExchNotesConnector
object class that is derived from the
msExchConnector and mailGateway object
classes:
• exportCustomRecipients Sp
ecifies whether mail-enabled
contacts are propagated to Lotus
Notes through directory
synchronization.
msExchServer1AlwaysCreateAs
Specifies how X.500 objects are
synchronized.
• msExchDeliveryOrder Specif
ies the processing order of
messages in the connector's
queue. The options are FIFO,
Priority (default), and Size.
• msExchExportDLs Specifies
whether mail-enabled distribution
groups are propagated to Lotus
Notes through directory
synchronization.
• msExchPartnerLanguage Sp
ecifies the language (code page) of
the connected Lotus Notes and
Domino server.
• msExchDirsyncSchedule Sp
ecifies the times at which directory
synchronization is performed
automatically.
• msExchDirsyncStyle Specifi
es whether full or incremental
directory synchronization is
435
Administrative snap-in The extension snap-in for Connector for

Lotus Notes is named Exchange Notes
Connector. This snap-in extends the node
for the connector, which you can find in
Exchange System Manager, under
<Organization Name>/Administrative
Groups/<Administrative Group
Name>/Routing Groups/<Routing Group
Name>/Connectors.
Message Transfer
The following figure illustrates the process for sending messages from Exchange Server 2003
to Lotus Domino.
Sending messages from Exchange Server 2003 to Lotus Domino
The process for message transfer between Exchange Server 2003 and Lotus Domino is
made up of the following three steps:
1. Exchange 2003 determines that the recipient is a Lotus Domino user (based on
the target address of the user) and sends the message to the message transfer
agent (MTA).
2. The MTA delivers the message to the MTS-OUT directory, from which the
LSMEXOUT process retrieves it, converts the address from an X.400-based address
to a Lotus Domino address, and then delivers it to the READYOUT directory.
436
3. The LSMEXNTS process converts the message to Lotus Domino format and
delivers it for routing to the mail.box file on the Lotus Domino server.
The following figure illustrates the process for sending messages from Lotus Domino to
Sending messages from Lotus Domino to Exchange Server 2003
The process for message transfer between Lotus Domino and Exchange Server 2003 is
made up of the following three steps:
1. Lotus Domino receives a message sent to an Exchange Server 2003 user from a
Lotus Notes user and places it in the mail router's mail.box database. The mail router
identifies the message sent to Exchange Server 2003 and then deposits it in the
exchange.box file.
2. Connector for Lotus Notes retrieves the message from the exchange.box
database, converts the message to Exchange Server 2003 format using the
LSNTSMEX process, and then delivers it to the READYIN folder on the server
running Exchange Server 2003.
3. The LSMEXIN process receives the message, converts the address from a Lotus
Domino address to an X.400 address, and places it in the MTS-IN folder. The
Exchange MTA then processes the message from the MTS-IN folder and places it in
the Simple Mail Transfer Protocol (SMTP) service's MTS-OUT folder, from which it is
then routed.
437
Message Conversion
Exchange Server 2003 and Lotus Domino support several message types, including meeting
requests, tasks, task requests, and e-mail. Connector for Lotus Notes supports the mapping
of different message types between Exchange Server 2003 and Lotus Domino. However, the
conversion from one format to another might cause some changes in message
characteristics. For example, certain features of a Lotus Domino message, such as the
expiration date, are lost when the message is converted to the Exchange format. Messages
that cannot be mapped to a corresponding message type in the target domain are converted
to e-mail messages.
Note:
Connector for Lotus Notes is not designed to convert HTML-formatted messages. If
you plan to route messages in HTML format between Exchange Server 2003 and
Lotus Notes (for example, because you want to route all messages to and from
Internet recipients through Exchange Server 2003), consider deploying an SMTP
connector instead of Connector for Lotus Notes.
The following table illustrates how different message types are converted between Exchange
Server 2003 and Lotus Domino.
Message conversion between Lotus Domino and Exchange Server 2003
Exchange Lotus Domino Lotus Domino to Exchange

Server 2003 feature feature Exchange Server 2003 to Lotus
Server 2003 Domino
E-mail messages E-mail messages Yes Yes
E-mail delivered E-mail delivered Yes Yes

receipt receipt
E-mail read receipt E-mail read receipt Yes Yes
Non-delivery report Non-delivery report Yes Yes
Importance Importance Yes Yes
Voting buttons No feature No No
Embedded OLE Embedded OLE Yes Yes

object object
Embedded file Embedded file Yes Yes

attachment attachment
Message expiry date Message expiry date No No
No feature Reply By No No
438
Exchange Lotus Domino Lotus Domino to Exchange

Server 2003 feature feature Exchange Server 2003 to Lotus
Server 2003 Domino
Web URL Web URL Yes Yes
No feature URL hotspot No No
Meeting requests Appointments Yes Yes
Meeting accepted Meeting accepted Yes Yes
Meeting declined Meeting declined Yes Yes
Meeting tentatively Meeting accepted Appears as Appears as accepted

accepted accepted
Meeting request Meeting request Yes Yes

read read

delivery delivery
Meeting updates Meeting updates Appear as new Appear as new

meeting requests meeting requests
containing the word containing the word
"Updated" in the "Updated" in the
subject line subject line
Meeting cancellation Meeting cancellation Yes Yes
Task requests Tasks Task requests Task requests

appear as e-mail appear as e-mail
messages or tasks messages
All day meeting No feature No Appear as meetings

requests with midnight as the
start and end time
No feature Phone messages Appear as e-mail No

messages
Other messages Other messages Default to e-mail Default to e-mail

messages messages
Note:
Connector for Lotus Notes does not support signed or encrypted messages.
439
E-Mail Message Type Conversion

E-mail messages that originate in either Exchange or Lotus Domino are converted to the
format of the target messaging system. Connector for Lotus Notes also tracks message
delivery by using delivery confirmation reports, read receipts, and non-delivery reports.
Connector for Lotus Notes handles meeting requests and phone messages as follows:
• Meeting Requests and Appointments Connector for Lotus Notes

synchronizes Exchange meeting requests and Lotus Domino appointments. Updated
meeting requests are identified as Updated in their subject lines. Because of a
limitation of the Lotus Domino API, meeting requests that Exchange Server 2003
users send to Lotus Domino users are not automatically updated in Lotus Domino.
The user must manually update them.
• All Day Meeting Requests All-day meeting requests generated in Exchange

Server 2003 appear with a start and end time of midnight.
• Phone Messages Lotus Notes phone messages appear as e-mail messages in

E-Mail Message Property Mapping

Objects embedded in messages that are sent by the Exchange Server 2003 client (Outlook)
to the Lotus Domino client (Lotus Notes) are converted to attachments. Embedded objects
always appear as attachments to the primary message, regardless of where they appear in
the original thread.
The following table illustrates which Lotus Notes e-mail message features convert correctly to
Microsoft Outlook.
E-mail message conversion between Lotus Notes and Microsoft Outlook
Lotus Notes Microsoft Outlook
Size Converts correctly.
Color Converts correctly.
Bold Converts correctly.
Underline Converts correctly.
Italic Converts correctly.
Strikethrough Converts correctly.

440
Lotus Notes Microsoft Outlook
Tables Convert correctly if Microsoft Word is used

as the primary e-mail editor in Outlook, but
formatting is lost. Do not convert correctly if
Outlook is the e-mail editor.
Embedded OLE objects, including graphics Convert correctly and can be edited.
Double strikethrough Ignored.
Superscript Ignored.
Subscript Ignored.
Shadow Ignored.
Outline Converts to italic.
Emboss Ignored.
Engrave Ignored.
Small caps Ignored.
All caps Ignored.
Drop caps Ignored.
Hidden Ignored; text is visible.
Underline other than single Ignored.
Bitmaps not embedded as OLE objects Not migrated; formatting is lost.
Bullets Ignored.
The following figure depicts the directory connection between Exchange Server 2003 and
Lotus Domino. As mentioned in the table above, the Lsdxa.exe process is responsible for
controlling the actual directory synchronization processes Dxamex.dll and Dxanotes.dll.
Lsdxa.exe is started automatically when the Microsoft Exchange Connector for Lotus Notes
service starts. For more information about how to configure directory synchronization, see the
Exchange Server 2003 Interoperability and Migration Guide.
Note:
Connector for Lotus Notes creates mail-enabled contacts in Active Directory for
recipients in the Lotus Notes messaging system. The legacyExchangeDN address
(that is, the X.500 address of the Exchange user in Exchange 5.5 format) matches in
441
its first part the legacyExchangeDN of the connector. The first part is that portion of
the X.500 address that identifies the connector's administrative group (that is,
/O=<name of organization>/OU=<name of administrative group>).
Directory synchronization between Lotus Domino and Exchange Server 2003
On the Exchange side, Dxamex.dll communicates with Active Directory through ADSI to
extract the recipient information from the export containers specified in the connector
configuration. Dxamex.dll maps the recipient attributes as defined in Amap.tbl and
Mapmex.tbl, and places the results in a temporary file named Dxanotes.text in message
interchange format (MIF) in the \Program Files\Exchsrvr\Conndata\Temp directory.
Dxanotes.dll then parses the Dxanotes.txt file, processes the addresses, and places them in
the target directory on the Lotus Domino server. To communicate with Lotus Domino,
Dxanotes.dll uses the Lotus Notes Client API.
The following listing is an example of a Dxanotes.txt file:

Load
A
FULLNAME:Administrator
MAILDOMAIN:Exchange
COMPANY:
DEPARTMENT:
FIRSTNAME:
LASTNAME:Administrator
LOCATION:
SHORTNAME:Administrator
UNID:DBC07527-91C1F649-8427525F-902428E2
DN:CN=Administrator,CN=Users,DC=contoso,DC=com
USNCreated:8194
Initials:
Title:
Phone:
MobilePhn:
Fax:
Resource:
CALDOM:Exchange
MAILSRV:
442
EndOfBuffer
Dxanotes.dll also performs directory synchronization from Lotus Notes to Active Directory.
The process uses the Lotus Notes Client API to read the Lotus Domino directory.
Dxanotes.dll maps the recipient attributes as defined in Amap.tbl and Mapnotes.tbl, and
writes the recipient information to the Dxamex.txt file in the \Program
Files\Exchsrvr\Conndata\Temp directory. Dxamex.dll processes the Dxamex.txt file and
places the recipient information in the import container specified in the connector
configuration.
The following listing is an example of a Dxamex.txt file:

Load
U
DN:admin
TA:NOTES:admin@Notes
ALIAS:admin
NAME:admin
FULLNAME:admin
FIRSTNAME:
Initials:
LASTNAME:admin
NOTESADDR:admin@Notes
UNID:4a12766d-8684ea55-3e551cde-3bac7ae9
COMPANY:
DEPARTMENT:
TITLE:
OFFICE:
PHONE:
FAX:
MOBILEPHN:
USNCREATED:
EndOfBuffer
Connector for Novell GroupWise

Architecture
Connector for Novell GroupWise supports bidirectional message transfer and directory
synchronization between an Exchange organization and a Novell GroupWise environment.
Novell GroupWise releases 4.2, 5.0, and 5.5 are supported. This MAPI-based connector uses
the Novell GroupWise API Gateway to communicate with Novell GroupWise. For information
about how to install and configure Connector for Novell GroupWise, see the Exchange
Server 2003 Interoperability and Migration Guide.
443
Note:
Microsoft does not officially support Novell GroupWise6.0 or later. However, because
the underlying technologies remain the same as in previous versions, Microsoft
Product Support Services offers "commercially reasonable effort" support. An
alternative to using Connector for Novell GroupWise for interoperability and directory
synchronization is to use the Novell GroupWise Gateway for Microsoft Exchange. If
you plan to migrate from Novell GroupWise6.0 or later to Exchange Server 2003, you
might want to use this connector from Novell.
The following table lists the important components of Connector for Novell GroupWise.
Connector for Novell GroupWise components
Connector mailbox As a MAPI-based connector, Connector for

Novell GroupWise locates its message
queues in a connector mailbox in the
default mailbox store on the bridgehead
server. The mailbox name is Connector for
Novell GroupWise (<server name>), such
as Connector for Novell GroupWise
(SERVER01).
444
Connector service The Connector for Novell GroupWise

service uses the same main executable
named Dispatch.exe as does Connector for
Lotus Notes. This is possible because
Dispatch.exe does not perform the actual
message processing. Dispatch.exe is
started with the parameters -cexchconn.ini
-nLME-GWISE -pCONTROL-SERVICE
-l"C:\Program Files\Exchsrvr\bin" -vLME-
GWISE and dispatches the processes
required to accomplish the various tasks for
message transfer and directory
synchronization with Novell GroupWise.
Dispatch.exe starts the actual processes
based on the settings from an Exchconn.ini
file. Exchconn.ini is created automatically
as part the connector installation and
configuration.
Three of the active connector processes are

also the same as for Connector for Lotus
Notes. These are the processes
Lsmexin.exe, Lsmexout.exe, and
Dxamex.dll, which communicate with
Exchange Server 2003. Connector for
Novell GroupWise-specific components are
Mex2gw.exe, Gw2mex.exe, and
Dxagwise.dll.
The following components are involved in

information handling:
• Dxagwise.dll This component

checks the Novell GroupWise
directory for recipient updates. This
component also transfers
Exchange address information
changes to the Novell GroupWise
directory.
• Dxamex.dll This component

checks Active Directory for recipient
updates. This component also
transfers Novell GroupWise
address information changes to
445
Exchange Router for Novell GroupWise Connector for Novell GroupWise uses a
service Microsoft Exchange Router for Novell
GroupWise service (Gwrouter.exe), which
transfers messages in the form of header
and body files between the connector store
and a Novell GroupWise API Gateway.
446
Connector store The connector store, located in the

\Program Files\Exchrvr\Conndata directory,
acts as the communication media between
Connector for Novell GroupWise and
Router for Novell GroupWise.
Connector for Novell GroupWise uses the

following connector store subdirectories:
• \GwrouterThis directory has

further subdirectories polled by
Router for Novell GroupWise. The
subdirectories are temporary
repositories for message header
files with an .api name extension,
and message body and attachment
files with a .bdy name extension
that Router for Novell GroupWise
transfers to and from Novell
GroupWise API Gateway. Header
and body files are keyword-based
text files that Novell GroupWise API
Gateway can convert to messages
in Novell GroupWise format.
The \Gwrouter directory has the

following subdirectories:
• \Archive This directory

only exists when archiving
is enabled for Connector
for Novell GroupWise. To
enable archiving, you must
configure the REG_DWORD
registry parameter called
Archive that you can find at
the following location:
HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Servic
es\LME-GWISE\Parameters.
You must set this registry

parameter to a value of 0x1.
Exchange 2003 then creates the
\Archive directory in the
447
Novell GroupWise API Gateway Connector for Novell GroupWise uses

Novell GroupWise API Gateway to
communicate with the Novell GroupWise
environment. This is a universal GroupWise
gateway that uses keyword-based text files
to communicate with non-Novell GroupWise
messaging systems, such as Exchange
Server 2003. Novell GroupWise API
Gateway maintains a folder structure with
the following directories:
• \API_IN Receives incoming
message header files from non-
GroupWise systems
• \API_OUT Holds outgoing

message header files to non-
GroupWise systems
• \ATT_IN Receives incoming

message bodies and attachments
from non-GroupWise systems
• \ATT_OUT Holds outgoing

message bodies and attachments
to non-GroupWise systems
• \WPCSIN The GroupWise

MTA inbound queue where
incoming messages are placed
after their processing through the
API Gateway
• \WPCSOUT The GroupWise

MTA outbound queue where
outgoing messages are located
before they are converted to
keyword-based text files and placed
in API_OUT and ATT_OUT through
the API Gateway
448
Registry settings In the Registry, Connector for Novell

GroupWise settings are stored in the
following location:
HKEY_LOCAL_MACHINE\SYSTEM\Curre
ntControlSet\Services\LME-GWISE.
Proxy address generation DLL The proxy address generation DLL of

Connector for Novell GroupWise is named
Gwxpxgen.dll and resides in the \Program
Files\Exchsrvr\address\gwise\i386 directory.
addrType object The common name of the addrType object

of Connector for Novell GroupWise in
Active Directory is GWISE:i386.
449
msExchConnector object The msExchConnector object of Connector

for Novell GroupWise in the configuration
directory partition of Active Directory stores
specific to the
msExchGroupWiseConnector object class
that is derived from the msExchConnector
and mailGateway object classes:
• exportCustomRecipients Sp
ecifies whether mail-enabled
contacts are propagated to Novell
GroupWise through directory
synchronization.
msExchServer1AlwaysCreateAs
Specifies how X.500 objects are
synchronized.
• msExchDeliveryOrder Specif
ies the order of message
processing in the connector's
queue. Options are FIFO, Priority
(default), and Size.
• msExchExportDLs Specifies
whether mail-enabled distribution
groups are propagated to Novell
GroupWise through directory
synchronization.
• msExchPartnerLanguage Sp
ecifies the language (code page) of
the connected Novell GroupWise
post office.
• msExchDirsyncSchedule Sp
ecifies the times at which directory
synchronization is performed
automatically.
• msExchDirsyncStyle Specifi
es whether full or incremental
directory synchronization is
450
Administrative snap-in The extension snap-in for Connector for

Novell GroupWise is named Exchange
GroupWise Connector. This snap-in
extends the node for the connector, which
you can find in Exchange System Manager
under <Organization Name>/Administrative
Name>/Connectors.
Message Transfer
The following figure illustrates the process for sending messages from Exchange Server 2003
to Novell GroupWise.
451
Sending messages from Exchange Server 2003 to Novell GroupWise
The message transfer process between Exchange Server 2003 and Novell GroupWise is
made up of the following four steps:
1. Exchange Server 2003 determines that the recipient is a Novell GroupWise user
(based on the target address of the user) and sends the message to the Exchange
MTA.
2. The MTA delivers the message to the MTS-OUT directory, from which the
Lsmexout.exe process retrieves it, checks Active Directory, replaces target recipient
information with corresponding GroupWise addresses, and then delivers the
message to the READYOUT folder.
3. The Mex2gw.exe process converts the message to Novell GroupWise format

before writing it as header and body files to the connector store on the server running
452
Note:
Header and body files are keyword-based text files that the GroupWise API
Gateway uses to communicate with Connector for Novell GroupWise. You can
use a text editor, such as Microsoft Notepad, to read and write keyword-based
text files in the API Gateway directory structure.
4. The Exchange Router for Novell GroupWise service (Gwrouter.exe) places the
message in the API_IN and ATT_IN directories of Novell GroupWise API Gateway.
The gateway works in conjunction with a Novell GroupWise MTA for delivery in the
GroupWise organization.
The following figure illustrates the process for sending messages from Novell GroupWise to
Sending messages from Novell GroupWise to Exchange Server 2003
The process for message transfer from Novell GroupWise to Exchange Server 2003 is made
up of the following four steps:
453
1. The Router for Novell GroupWise service obtains the message from the
API_OUT and ATT_OUT directories of Novell GroupWise API Gateway in the form of
header and body files and places them in the connector store.
2. The Gw2mex.exe process converts the header and body files to a message in
Exchange Server 2003 format, before it places the message in the READYIN folder.
3. The Lsmexin.exe process obtains the converted message from the READYIN
folder, verifies the validity of the recipient (converting the address to Exchange
format, if necessary), and delivers the message to the MTS-IN folder.
4. The Exchange MTA then processes the message from the MTS-IN folder and
places it in the SMTP service's MTS-OUT folder, from which it is then routed to its
destination in the Exchange organization.
Message Conversion
Novell GroupWise supports several specific message types, such as e-mail messages,
appointments, notes, tasks, forms, presentations, and documents. MAPI message types are
mapped to corresponding message types in Novell GroupWise, when possible. In other
words, e-mail messages appear as e-mail messages, meeting requests as appointments,
and so on. Message types that are not supported in Exchange Server 2003, such as Novell
GroupWise phone messages, are converted to regular e-mail messages. Connector for
Novell GroupWise can track delivery confirmation reports, read receipts, and non-delivery
reports.
Message Conversion between Novell GroupWise and Exchange Server 2003
Exchange GroupWise feature GroupWise to Exchange Server 20

Server 2003 feature Exchange Server 20 03 to GroupWise
03
E-mail messages Messages Yes Yes
E-mail read receipt E-mail read receipt Yes Yes
Non-delivery report Non-delivery report Yes Yes
Importance Importance Yes Yes (low priority

does not have a
representation in
GroupWise)
Sensitivity Sensitivity Yes Yes
Meeting requests Appointments Yes Yes
Meeting accepted Meeting accepted Yes Yes

454
Exchange GroupWise feature GroupWise to Exchange Server 20

Server 2003 feature Exchange Server 20 03 to GroupWise
03
Meeting declined Meeting declined Yes Yes
Meeting tentatively Meeting accepted Appears as Appears as accepted

accepted accepted

read read

delivery delivery
Meeting updates Meeting updates Appear as new Appear as new

meeting requests meeting requests
containing the word containing the word
"Updated" in the "Updated" in the
subject line subject line
Meeting reminder Meeting reminder No No

times times
Meeting cancellation Meeting cancellation No Yes
Task requests Tasks Task requests Tasks appear as

appear as e-mail
e-mail messages
messages
All day meeting Meeting requests Yes Appear as meeting

requests requests, however if
the meeting extends
over multiple days, it
is placed as a single
instance on the first
day with the date
range in the
message field
No Phone messages Appear as e-mail No

messages
Other messages Other messages Default to e-mail Default to e-mail

messages messages
Note:
Connector for Novell GroupWise does not support signed or encrypted messages.
455
E-mail Message Type Conversion

E-mail messages that originate in either Exchange or Novell GroupWise are converted to the
format of the target system. Connector for Novell GroupWise also tracks message delivery by
using delivery confirmation reports, read receipts, and non-delivery reports.
Connector for Novell GroupWise handles meeting requests and phone messages as follows:
• Meeting Requests and Appointments Exchange meeting requests and Novell

GroupWise appointments are transferred through Connector for Novell GroupWise.
Updated meeting requests are identified as "Updated" in their subject lines. Because
of a limitation of the GroupWise API Gateway, meeting requests sent from Exchange
Server 2003 users to GroupWise users cannot be updated automatically in Novell
GroupWise and must be updated manually by the user.
Note:
The API Gateway does not support recurring meeting requests from GroupWise
that use the AutoDate feature. These recurring meeting requests are not
transferred to Exchange Server 2003. Recurring meetings transferred from
Exchange Server 2003 to Novell GroupWise are added to the Novell GroupWise
calendar once, and recurring information is then displayed at the top of the
message body. It is the user's responsibility to remember when the meetings take
place or to enter multiple meeting occurrences individually in the calendar.
• All Day Meeting Requests All day meeting requests generated in

Exchange Server 2003 appear as meeting requests in Novell GroupWise. However, if
the meeting continues over multiple days, the connector creates a single instance on
the first day with the date range in the message field.
• Phone Messages Novell GroupWise phone messages appear as e-mail

messages in Exchange Server 2003.
E-mail Message Property Conversion

The connector discards rich text format (RTF) information in the message body of Exchange
messages, because API Gateway supports plain text only. Objects embedded in messages
sent by Exchange Server 2003 clients (Microsoft Office Outlook) are converted to
attachments. These attachments, if embedded more than one level deep, appear as
attachments to the primary message. If a Novell GroupWise user sends a message that
includes an attached message that contains additional attachments, all attachments appear
in Exchange Server 2003 as single attachments to the primary message.
456
E-mail message conversion between Novell GroupWise and Microsoft Outlook
Novell GroupWise Microsoft Outlook
Size Converts correctly.
Color Ignored.
Bold Ignored.
Underline Ignored.
Italic Ignored.
Strikethrough Converts correctly.
Tables Convert correctly if Microsoft Word is used

as the primary e-mail editor in Outlook. Do
not convert correctly in Outlook.
Embedded OLE objects, including graphics Convert correctly and can be edited.
Double strikethrough Ignored.
Superscript Ignored.
Subscript Ignored.
Shadow Ignored.
Outline Converts to italic.
Emboss Ignored.
Engrave Ignored.
Small caps Ignored.
All caps Ignored.
Drop caps Ignored.
Hidden Ignored, text is visible.
Underline other than single Ignored.
Bitmaps not embedded as OLE objects Not migrated, formatting is lost.
Bullets Ignored.
Note:
If an Exchange user specifies a GroupWise user multiple times in an e-mail message
(if recipient is listed more than once in the To, Cc, or Bcc line, or is in more than one
specified distribution group) the GroupWise user receives duplicate e-mail messages.
457
Directory synchronization with Novell GroupWise follows a pattern similar to directory
synchronization with Lotus Notes. The Lsdxa.exe process is responsible for controlling the
actual directory synchronization processes. However, instead of Dxanotes.dll, the LSDXA
process uses Dxagwise.dll (that is, the Novell GroupWise DX Agent) for directory
synchronization with Novell GroupWise. Dxagwise.dll communicates with Novell GroupWise
by means of Novell GroupWise API Gateway, the Exchange Router for Novell GroupWise
service, and GroupWise administrator messages (Msg-Type= Admin). For more information
about how to configure directory synchronization, see the Exchange Server 2003
Interoperability and Migration Guide.
Note:
Connector for Novell GroupWise creates mail-enabled contacts in Active Directory for
recipients in the Novell GroupWise messaging system. The legacyExchangeDN
address (that is, the X.500 address of the Exchange user in Exchange 5.5 format)
matches in its first part the legacyExchangeDN of the connector. The first part is that
portion of the X.500 address that identifies the connector's administrative group (that
is, /O=<name of organization>/OU=<name of administrative group>).
Connector for Novell GroupWise performs the following steps to synchronize directories with
Novell GroupWise:
1. Dxamex.dll communicates with Active Directory through ADSI to extract the

recipient information from the export containers specified in the connector
configuration.
2. Dxamex.dll maps the recipient attributes as defined in Amap.tbl and Mapmex.tbl

and places the results in the form of a temporary file named Dxagwise.txt in message
interchange format (MIF) in the \Program Files\Exchsrvr\Conndata\Togwise directory.
The following is an example of a Dxagwise.txt:
Load
A
DOMAIN:
POSTOFFICE:
OBJECT:
LASTNAME:
FIRSTNAME:Administrator
DESCRIP:Administrator
ACCOUNTID:
TITLE:
DEPARTMENT:
PHONE:
FAX:
GWADDR:Exchange.First Administrative Group.Administrator
EXCHANGEID:Microsoft Exchange Connector for Novell GroupWise
EndOfBuffer
458
3. Dxagwise.dll parses the Dxagwise.txt file, processes the addresses, and places
an administrator message to perform the update operation (add, modify, or delete
recipient objects) in the Novell GroupWise directory in the \Program
Files\Exchsrvr\Conndata\Gwrouter\Togwise directory. The following is an example of
an administrator message to update recipient objects in the Novell GroupWise
directory:
WPC-API= 1.2;
Msg-Type= Admin;
DS-External-Post-Office=
Operation= Add;
Domain= EXCHANGE;
Post-Office= FIRST ADMINISTRATIVE GROUP;
Time-Zone= gmt;
;
DS-User=
Operation= Modify;
Visibility= System;
Domain= Exchange;
Post-Office= First Administrative Group;
Object= Administrator;
Last-Name= \\;
First-Name= Administrator;
Description= Administrator;
Account-ID= \\;
Title= \\;
Department= \\;
Phone= \\;
Fax= \\;
Network-ID= \\;
User-Def-5= Microsoft Exchange Connector for Novell GroupWise;
;
-END-
4. The Exchange Router for Novell GroupWise service transfers the administrator
message to the Novell GroupWise API Gateway's API_IN directory.
5. Novell GroupWise API Gateway parses the administrator message and performs
the specified action.
6. If Novell GroupWise API Gateway receives an administrator message to request

directory information, the API gateway returns the requested information in the form
of an administrator message. The administrator message is placed in the API_OUT
directory in the form of an .api file. The following is an example of an administrator
message to request directory information from the Novell GroupWise directory:
WPC-API= 1.2;
Msg-Type= Admin;
-GET-DIRECTORY-
-END-
459
7. The Exchange Router for Novell GroupWise service retrieves the .api file and
places it in the \Program Files\Exchsrvr\Conndata\Gwrouter\Dirsync directory.
8. Dxagwise.dll parses the .api file, extracts the recipient information, and writes
updates or the complete list (Full Load) to Dxamex.txt.
9. Dxamex.dll processes the Dxamex.txt file and places the recipient information in
the import container specified in the connector configuration.
Calendar Connector Architecture

Calendar Connector supports synchronization of free/busy information between Exchange
Server 2003 and Lotus Notes or Novell GroupWise, so that users in these messaging
systems can query each other's free/busy information when they create meeting requests.
The requirements for Calendar Connector are similar to those for Connector for Lotus Notes
and Connector for Novell GroupWise. These connectors must be installed in the same
administrative group as Calendar Connector and should be configured before
Calendar Connector. For information about how to install and configure Calendar Connector,
see the Exchange Server 2003 Interoperability and Migration Guide.
Note:
Calendar Connector cannot reside in an administrative group with no servers (that is,
an administrative group that contains a routing group to define specific
administrators), because there is no server to contain free/busy information. Calendar
Connector must be installed on a server that is running Exchange Server 2003 with
an instance of the Free/Busy public folder for the local administrative group.
Free/Busy Information
Free/busy refers to certain information published by a messaging client for a user. This
information consists of the user's personal availability data determined by the contents of the
Calendar folder in their mailbox. As expected, free/busy data is used extensively when
scheduling meetings. Free/busy data is stored as messages in a dedicated system public
folder. Each administrative group in the Exchange organization includes a Free/Busy folder.
You must install Calendar Connector on a server that is running Exchange Server that
contains a replica of the free/busy system folder for the administrative group. Free/busy data
can be replicated within the Exchange organization to any one of the public folder servers, or
it can reside on a single server that runs Exchange Server. Within the organization, the
free/busy data is replicated using standard public folder replication.
You can check whether a server that runs Exchange Server contains a replica of the
free/busy system folder for the administrative group. For detailed instructions, see How to
460
Check Whether a Server Running Exchange Server Contains a Replica of the Free/Busy
System Folder for the Administrative Group.
Note:
Calendar Connector requires permissions to read and create items in the Free/Busy
system folder. In the properties of the Free/Busy folder for your local administrative
group, select the Permissions tab, and then click Client Permissions. In the Client
Permissions dialog box, verify that the Default account is assigned the Editor role.
Publishing of Free/Busy Data

The publishing of free/busy data is a client operation performed by Outlook and Outlook Web
Access. The Exchange store is not involved in this process, with the exception of a system
public folder in a public folder store that is used for storing and publishing data.
Note:
To replicate free/busy data between Exchange organizations, the Exchsync tool is
used together with some additional settings.
Outlook first gets a referral from the mailbox server for the associated Free/Busy public folder.
After the server is located, properties on the user object in Active Directory are used to find
the free/busy message in the public folder.
Free/Busy Messages
Each free/busy message is a representation of the days and times that are busy and the days
and times that are not busy for a single person or resource. This is represented by a stream
of numbers on the Free/Busy server (a public folder server with public folders containing
replicas of one or more of the Free/Busy site folders).
One representation is 002222000033333333, where each number represents X minutes of

increment (as specified in the request, with 6 minutes being the lowest granularity). This
interpretation of the numbers is discussed in the following table.
Free/busy messages
Number Meaning
0 Free
1 Tentative
2 Busy
3 Out of Office (OOF)

461
When there are multiple appointments in a single timeslot, the appointment with the highest
status number is selected. For example, a slot that contains both an OOF (3) appointment
and a tentative (1) appointment is coded as OOF (3).
More specifically, free/busy data is stored in multiple groups of multi-valued integer arrays.
Each group represents one of the busy classifications (busy, tentative, or OOF), and each
item in the group represents one month of data. The array itself is a group of pairs, in which
each pair is the number of minutes into the month the busy period starts and ends, time-
zone-adjusted to the International Date Line. Therefore, no data is stored for free time,
because free time is implicitly computed as being all of the time that is not marked as busy.
The appointment also stores the start month and month count, so that clients can compute
appropriately.
Free/Busy Data Generation

There are various ways to generate free/busy data. For example, Outlook modifies a user's
free/busy items as calendar items are saved, and periodically publishes this message to their
server that is running Exchange Server, using MAPI. Outlook Web Access and Outlook
Mobile Access clients also generate free/busy items as calendar items are saved. From there,
Outlook Web Access or Outlook Mobile Access sends the message through collaboration
data object (CDO) and WebDAV to System Attendant, which is responsible for additional
processing the message and publishing to the server that is running Exchange Server.
Free/Busy Publishing in Outlook

Outlook publishes free/busy data for a user periodically (by default every 15 minutes), and
upon shutdown. Every time that free/busy information is published, the entire free/busy item
is updated (not only the changes). The user may specify the number of months of future
free/busy information to publish on the server. Two months is the default, and 36 months is
the maximum duration. By default, the free/busy data is published for one month in the past.
When Outlook must publish, it first determines the folder to which to publish free/busy data,
based on the legacyExchangeDN of the user. The legacyExchangeDN consists of two parts.
The first part determines the path of the free/busy folder (also the administrative group in
which the user was created, because the legacyExchangeDN does not change when moving
user mailboxes between administrative groups), and the second part is the subject of the
free/busy message. For example, the free/busy data location for a user who has the
legacyExchangeDN of /o=Contoso/ou=CorpUsers/cn=Recipients/cn=UserName is the folder
"EX:/o=Constso/ou=CorpUsers," and the message has a subject of "User-
/cn=Recipients/cn=UserName."
The free/busy folder is a subdirectory of the Schedule+ Free Busy folder, under the
NON_IPM_SUBTREE. The message subject is USER-/cn=RECIPIENTS/cn=UserName. If a
duplicate free/busy message is created, the information store automatically appends the
462
suffix -2 to the URL of the message. Therefore USER-/cn=RECIPIENTS/cn=UserName

becomes USER-/cn=RECIPIENTS/cn=UserName-2. This duplication of messages is not
common, but it can occur because of client errors, replication failures, and so on. If Outlook
discovers duplicate entries for a user while publishing data, it deletes them. The System
Attendant's free/busy publishing agent also deletes duplicate entries when it is updating
free/busy information about behalf of Outlook Web Access or Outlook Mobile Access.
After Outlook determines where to publish the message in the public folder store, it chooses a
free/busy server. The steps are as follows:
1. Upon first logon, the server indicates to the client which default hierarchy server
to contact. This information is stored in the user's profile. If the administrator changes
the setting in Exchange System Manager, the user must log out and log back in to
get the new value. The client then makes an initial connection to this server and
maintains the connection for the duration of the user's logon session.
2. The MAPI client requests a "hierarchy" table for the root of the public folder store.
This request is sent to the configured default public folder store, and folders stored at
the root level of the public folder store are returned to the client.
3. The client enumerates the folder entries in this table, looking for the folder of
interest. If it is required, the client subsequently opens subfolders, opens their table of
sub-subfolders, and enumerates the subfolders again.
4. After the MAPI client identifies the folder of interest, it requests the table of
contents for that folder.
5. The service provider queries the server for the list of content replicas for the
folder.
6. The server obtains the replica list for the folder from the database and sorts it
based on routing group connector costs from that server. Other content replicas in
the same routing group as the requested server have a connector cost of zero.
7. The sorted list is returned to the client, together with the number of items in the
group of lowest-cost servers.
8. If the server to which the client is already connected is in the replica set (its cost
is also zero), the content replica search is finished. Go to Step 10.
9. The user's legacyDN is hashed, and the hash result is then divided by the count
of the lowest-cost servers. The rest of the division is used to index the list of servers
returned and to pick a server to which to connect.
10. The service provider tries a connection to the chosen server. If the connection
succeeds, the entire process is finished, and the server returns the contents table to
the MAPI client.
11. If the connection fails or the server reports "I'm not a replica" (the replica set
might have changed, and that change might not yet have replicated to the server
463
from which the replica list came), the service provider removes this server from the
list, decrements the count of "lowest-cost" servers, and if that count is not at zero,
returns to Step 9.
12. If the list of lowest-cost servers is exhausted, the count is reset to the size of the
remaining servers in the list, and the process returns to Step 9. If the entire list is
exhausted, an error is returned to the MAPI client.
Note:
These steps are identical, regardless of which folder the client wants (Offline Address
Book, Free/Busy, or another folder) or for what reason it wants the content in that
folder.
Free/Busy Publishing in Outlook Web Access

and Outlook Mobile Access
Because they do not use MAPI, Outlook Web Access and Outlook Mobile Access cannot
publish free/busy data directly to the public folder store. Instead, they rely on a free/busy
publishing agent (MadFB) that runs in the System Attendant process (Mad.exe).
MadFB has two functions:
• Publishing free/busy messages for Outlook Web Access and Outlook Mobile
Access
• Deleting duplicate free/busy messages
As part of the transaction involved in the creation, deletion, or update of an appointment that
affects the start or end time, a server-side call sends a free/busy update message to the
System Attendant's mailbox. MadFB, which resides inside System Attendant, processes
these messages and updates the free/busy data in the MAPI public folder. Depending on
System Attendant's message polling interval, there can be up to a 15-minute delay before the
updated free/busy data is published.
MadFB's publishing process is identical to the Outlook publishing process described earlier.
Therefore, if duplicate messages are present, they are appended by a number. Although
Outlook Web Access and Outlook Mobile Access follow a process that is similar to the
process that Outlook follows, the Outlook Web Access and Outlook Mobile Access processes
are generally more reliable, because all the processing occurs between servers that are
running Exchange Server.
Free/Busy Data Lookup

When locating free/busy data, Outlook operates differently than Outlook Web Access and
Outlook Mobile Access, as described in the following bullets However, for all clients, this
464
process involves first locating the free/busy public folder, and then accessing a particular
user's free/busy data in the folder.
• Outlook Before Outlook locates the free/busy public folder, it first receives a
referral from the mailbox server for the associated public folder store, which the
free/busy server then queries against (the referral and querying process is similar to
the publishing process). The free/busy data is stored as messages in the site folder
that is located in the main free/busy folder. Outlook, using Active Directory and
Exchange Server, determines a user's legacyExchangeDN and parses it into two
parts. The first part is the site folder name. The second part is the subject of the
message.
• Outlook Web Access and Outlook Mobile Access These clients perform a
DAV query for the other user, obtain the free/busy information, and then display it to
the user. The DAV query is initiated from the server that hosts the Outlook Web
Access or Outlook Mobile Access service (frequently the front-end server) against the
user's mailbox server (back-end server), where the actual free/busy lookup occurs.
Note:
For free/busy lookups to work, recipient information must be available in Active
Directory, so that the target free/busy system folder can be determined.
Therefore, you must enable directory synchronization with Lotus Notes or Novell
GroupWise, if you want to synchronize free/busy information using Calendar
Connector. As mentioned earlier in this section, Connector for Lotus Notes and
Connector for Novell GroupWise create mail-enabled contacts with a
legacyExchangeDN address that corresponds to the connector's local
administrative group. Because of this dependency, Calendar Connector must be
installed in the same administrative group as Connector for Lotus Notes or
Connector for Novell GroupWise. You should install Calendar Connector on the
same server as Connector for Lotus Notes or Connector for Novell GroupWise.
Free/Busy Publishing Agent (MadFB)

MadFB enables Outlook Web Access and Outlook Mobile Access to publish free/busy data.
As a secondary function, MadFB also purges outdated free/busy data. By default, MadFB
tries to maintain free/busy data on all non-front-end servers running Exchange Server each
day at 2:00 A.M. MadFB on each server maintains the default public folder stores associated
with each server's local mailbox stores (even if those public folder stores are located on
another server). MadFB runs within the System Attendant process.
The MadFB maintenance process includes:
• Fixing the URLs of free/busy items A free/busy item must be in "canonical"

form, which means that the item must have a URL ending with a normalized subject,
such as USER-/CN=RECIPIENTS/CN=TED. Items might be in non-canonical form
465
because of duplicates. For example, one of the URLs might have a tie-breaking "-x"
added, or one of the URLs might point to an item that was upgraded or replicated
from Exchange Server 5.5, in which case, the URL includes a GUID. The normalized
subject is determined by the last part of the legacyDN (for example,
CN=RECIPIENT,CN=TED).
• Deleting duplicate free/busy messages It is possible for Outlook to create a

duplicate free/busy message. To prevent overriding existing messages, the Exchange
store appends an "–X" (without the quotation marks, where x is an incremental
counter for the duplicate) to the normalized subject. MadFB deletes messages that
have subject lines in non-canonical form.
MadFB keeps the earliest dated message and deletes the remaining messages, which
ensures deterministic replication, in which duplicate entries are always deleted. For example,
if MadFB keeps the newest message and deletes the remaining messages, the conflicting
message [X-2] is persisted through replication. This occurs because X on PF1 and X-2 on
PF2 are first deleted, and the newer versions of X-2 on PF1 and X from PF2 are replicated.
Therefore, these become the newest entries, and the cycle then is repeated.
Note:
MadFB is the same as MSExchangeFBPublish, the event log record Source name
that is used to log events in the event log.
Cleaning Free/Busy Data

There are three ways to remove unwanted free/busy data. You can use an Outlook command
line startup switch, you can perform a server-side process on the server that is running
Exchange Server, or you can use Outlook Web Access to delete items manually.
Outlook Startup Switch

Outlook's /cleanfreebusy command-line startup switch is used to solve meeting scheduling
problems. This switch cannot help with general appointment problems, because it does not
delete the free/busy item on the public folder store, but instead deletes the local free/busy
message (LocalFreeBusy) generated by the Outlook client. The LocalFreeBusy message
exists as a hidden item in the user's Calendar folder in the mailbox on the server. This item
contains a binary large object with the user's free/busy information, information about
delegates that are allowed to schedule appointments for the user, and auto-accept settings.
Resource mailboxes are usually configured to accept meeting requests automatically if no
conflict with an existing appointment exists. The LocalFreeBusy item is replicated to the
public folder store so that all users in the Exchange organization can see your free/busy
information and use it for meeting scheduling.
466
If delegates receive an error message when attempting to modify the manager's calendar,
running /cleanfreebusy on the manager's calendar while the delegates have Outlook shut
down resets particular properties on the manager's public folder store. The next time that
delegates start Outlook, they retrieve the new free/busy data from the manager's
LocalFreeBusy item, thereby solving most delegate errors.
This delegate meeting scheduling problem originally occurs because the delegate client (for
various reasons) re-creates the free/busy message, which results in pointers pointing to the
deleted message. When the manager runs Outlook /cleanfreebusy in this state, the
manager's client re-creates the local free/busy message and stamps the root folders with the
new entry ID, which allows everyone to access the local free/busy message again.
Cleaning Using Outlook Web Access

The free/busy messages reside in a public folder under the SCHEDULE+ FREE BUSY
container in the non-ipm subtree of the public folder hierarchy. The non-ipm subtree is a
hidden tree, but you can use Outlook Web Access to access this tree and open the free/busy
folder of an administrative group. It is then possible to delete free/busy items manually. For
example, to access the non-ipm subtree on a server that is named Server01, use the
following URL: http://server01/public/non_ipm_subtree/. The SCHEDULE+ FREE BUSY
container is displayed as a regular public folder. Under this container, you find the free/busy
folders.
Calendar Connector Components

Because Calendar Connector does not transfer e-mail messages between Exchange and
Lotus Notes or Novell GroupWise, this connector does not have a connector mailbox in the
Exchange store or a proxy address generation DLL or adrType object in Active Directory.
Nevertheless, Calendar Connector is a MAPI-based connector, because it relies on MAPI for
Exchange store communication and on Active Directory Service Interfaces (ADSI) for
communication with Active Directory.
The following table lists the important components of Calendar Connector.

467
Calendar Connector components

468
Connector service The main executable of the Connector for

Lotus Notes service is called CalCon.exe.
CalCon.exe, in turn, loads several
components, named providers, which
perform the actual tasks of synchronizing
free/busy information. All files reside in the
\Program Files\Exchsrvr\Bin directory.
• Adminsvc.dll Calendar Conn

ector loads Adminsvc.dll to perform
administrative tasks, such as
polling providers periodically to
report on connector health and
gathering statistics and
performance data that can be
viewed by using the Performance
tool.
• Calsync.dll Calendar Connec

tor loads Calsync.dll at startup to
search Active Directory for the non-
Exchange recipients that Connector
for Lotus Notes or Connector for
Novell GroupWise creates during
directory synchronization. The
MAPI-based connector that
Calendar Connector uses as the
basis for this search is specified in
Exchange System Manager, in the
Calendar Connector configuration,
on the General tab. Calsync.dll
ensures that there is a free/busy
record in the free/busy system
folder for each non-Exchange
recipient that is found in
Active Directory. The free/busy
records are empty at first
initialization.
Note:
It is best to schedule Calendar
Connector to run after each
directory synchronization cycle,
so that Calsync.dll can create
469
Exchange Calendar Connector add-in The Exchange Calendar Connector add-in

(ExCalCon.exe) is a component that must
be installed on the Lotus Notes and Domino
server that Connector for Lotus Notes and
Calendar Connector use as their non-
Exchange bridgehead server.
ExCalCon.exe receives free/busy requests
from Lotus Notes through Lotus Notes
Schedule Manager and forwards them to
the Calendar Connector instance that is
running on a server that is running
Exchange Server.
Registry settings In the Registry, settings for the Connector

for Lotus Notes are stored in the following
location:
HKEY_LOCAL_MACHINE\SYSTEM\Curre
ntControlSet\Services\MSExchangeCalC
on.
470
msExchConnector object The msExchConnector object of

Calendar Connector, in the configuration
directory partition of Active Directory, stores
specific to the msExchCalendarConnector
object class that is derived from the
msExchConnector and mailGateway object
classes.
The msExchCalendarConnector object has

the following attributes that are specific
Calendar Connector:
• msExchCalConQueryWindow
Specifies the time that
Calendar Connector waits for the
non-Exchange messaging system
to return a response for a free/busy
request. If this time is exceeded,
Calendar Connector returns the
information that is currently
available in the free/busy record to
the Exchange user.
When responses are late, Exchange

Server 2003 returns the existing data to
the Outlook client. When new data is
finally received, Calendar Connector
updates the free/busy record for the
non-Exchange user. The updated
information is not returned to the
Outlook client, and the user does not
receive an indication that free/busy
information might not include the most
recent updates or that more up-to-date
information could be obtained with a
subsequent query.
msExchCalConRefreshInterval
Specifies the time frame within
which Calendar Connector
considers the free/busy records for
471
Administrative snap-in The extension snap-in for

Calendar Connector is named Exchange
Calendar Connector. This snap-in is
implemented in Exadmin.dll and extends
the node for the connector, which you can
find in Exchange System Manager under
<Organization Name>/Administrative
Name>/Connectors.
Free/Busy Lookups to and from Lotus Notes

The following figure illustrates how Calendar Connector integrates with a Lotus Notes
messaging environment.
472
Synchronizing free/busy information with Lotus Notes
In Calendar Connector, Notescal.dll communicates with Lotus Notes and Domino through the
Lotus Notes Client API to transfer requests for Lotus Notes free/busy information to the Lotus
Notes Schedule Manager task. Schedule Manager is a task that runs on a Lotus Domino
server, which manages a Lotus Notes database named Busytime.nsf. The Busytime.nsf
database holds free/busy information for all the users on the server and for resources, such
as conference rooms, identified in the server's public address book.
Note:
Calendar Connector can connect to one Lotus Notes environment only. Integrating
multiple disparate Lotus Notes messaging systems with Exchange Server 2003 using
Calendar Connector is not supported.
473
Free/Busy Lookups from Exchange 2003

Calendar Connector performs the following steps for free/busy lookups for Lotus Notes users
from Exchange Server 2003:
1. Mapical.dll intercepts the free/busy request and checks for existing free/busy
records in the free/busy system folder. If the record has been updated within the time
frame specified under Maximum age in minutes of foreign free/busy data in
Exchange that can be used without querying the foreign calendar in the
Calendar Connector configuration, Mapical.dll returns this data immediately.
Note:
This mechanism only works if Calendar Connector is running on the server
where the free/busy folder resides. It is possible, for example, to replicate the
free/busy folder to other servers in remote administrative groups, in which case
the users who query these public folder instances might receive outdated
information. Exchange Server 2003 only returns the information currently
available in the requested free/busy messages. To avoid this problem, you must
install separate Calendar Connector instances for each replica of the free/busy
folder.
2. If a free/busy record does not exist or is beyond the maximum time limit,
Mapical.dll passes the free/busy query to Notescal.dll to update the target user's
free/busy record in the Exchange free/busy folder.
3. Notescal.dll receives the free/busy query from Mapical.dll and passes it to the
Lotus Notes Schedule Manager task.
4. The Schedule Manager task retrieves the information for local users from the
Busytime.nsf database. For users on downstream Lotus Domino servers, Schedule
Manager communicates with the Lotus Notes Calendar Connector task that is also
running on the Lotus Domino server to locate the free/busy information.
5. The Lotus Notes Calendar Connector task determines the domain of the target
user and reads the Calendar Server Name field from the domain document.
Calendar Connector then communicates with the remote calendar server to perform
the free/busy query.
6. The Lotus Notes Calendar Connector task returns the information to the
Schedule Manager task.
7. The Schedule Manager task returns the information to Notescal.dll.
8. Notescal.dll passes the information to Mapical.dll, which updates the Lotus Notes
user's free/busy record in the system folder.
9. Mapical.dll returns the information to the Outlook user.

474
Note:
If the non-Exchange system responds within the period of time specified under
Maximum number of seconds to wait for response from foreign calendars
in the Calendar Connector configuration, the data is written to the target user's
free/busy record in the Exchange free/busy folder and returned to the client. If the
non-Exchange system does not respond within the allowed time frame (or if
Calendar Connector is not running), Exchange Server 2003 returns the existing
data from the free/busy record to the client, without first updating the target user's
free/busy record.
Free/Busy Lookups from Lotus Notes

Calendar Connector performs the following steps for free/busy lookups for Exchange
Server 2003 users from Lotus Notes:
1. The Lotus Notes client passes the free/busy query to the Schedule Manager
task.
2. The Schedule Manager task determines that the request is for a non-local user
and passes it to the Calendar Connector task.
3. The Calendar Connector task reads the Person document for the Exchange user
and determines that the user is in a foreign domain. The Calendar Connector task
checks the Calendar System field in the Foreign Domain document for the
Exchange Server 2003 organization. The Calendar System field identifies the name
of the add-in program that handles the free/busy lookups on the Lotus Domino
server, which is the Exchange Calendar Connector add-in (ExCalCon.exe).
4. The Calendar Connector task passes the free/busy request to ExCalCon.exe.
5. ExCalCon.exe passes the request to the Notescal.dll component, which

processes the request and communicates with Mapical.dll to obtain the free/busy
information for the Exchange user from the free/busy system folder.
6. Notescal.dll passes the response back to ExCalCon.exe, which in turn passes

the information to the Calendar Connector task.
7. The Calendar Connector task passes the data to Schedule Manager.
8. Schedule Manager delivers the free/busy information to the Lotus Notes user.
Note:
Because Lotus Notes identifies all Exchange users as belonging to a non-Lotus
Notes domain, all requests for Exchange free/busy information are received from the
Lotus Notes Calendar Connector task.
475
Free/Busy Lookups to and from Novell

GroupWise
As shown in the following figure, Gwisecal.dll communicates with Novell GroupWise through
Connector for Novell GroupWise and Novell GroupWise API Gateway. Free/busy requests
are transferred within Novell GroupWise in the form of system messages. The architecture of
Connector for Novell GroupWise is discussed earlier in this section.
Synchronizing free/busy information with Novell GroupWise
Calendar Connector performs the following steps for free/busy lookups for Novell GroupWise
users from Exchange Server 2003:
1. Mapical.dll intercepts the free/busy request and checks for existing free/busy
records in the free/busy system folder. If the record is updated within the time frame
476
specified under Maximum age in minutes of foreign free/busy data in Exchange

that can be used without querying the foreign calendar in the
Calendar Connector configuration, Mapical.dll returns this data immediately.
2. If a free/busy record does not exist for the Novell GroupWise user or exceeds the
maximum time limit, Mapical.dll passes the free/busy query to Gwisecal.dll to update
the target user's free/busy record in the Exchange free/busy folder.
3. Gwisecal.dll translates the request to a SEARCH-type keyword-based text file

and puts it in the \Program Files\Exchsrvr\Conndata\GWRouter\Togwise directory.
The message originator of this SEARCH-type message is System Attendant. The
message is addressed to the Novell GroupWise user for whom Calendar Connector
requests the free/busy information. The following is an example of a SEARCH-type
request:
WPC-API= 1.2;
MSG-TYPE= Search;
Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51;
From=
WPD= CONTOSO_DOM;
WPPO= Exchange Gateway;
WPU= Microsoft System Attendant;
CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; ;
To=
WPD= CONTOSO_DOM;
WPPO= CONTOSO_PO;
WPU= FrankM;
CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; ;
Begin-Time= 2/12/2003 21:28;
End-Time= 31/1/2004 21:28;
-END-
4. The Router for Novell GroupWise obtains the message from the \Togwise
directory and puts it in the API_IN directory of Novell GroupWise API Gateway.
5. The API gateway processes the message according to the MSG-TYPE keyword
and puts it in the WPCSIN directory for the Novell GroupWise MTA.
477
6. The Novell GroupWise MTA routes the message to the home post office of the
GroupWise user and passes it to the appropriate Novell GroupWise Post Office
Agent (POA).
7. The Novell GroupWise POA processes the request and returns the resulting
free/busy information to the GroupWise MTA in the form of a SEARCH message.
8. The GroupWise MTA transfers the message to the WPCSOUT directory in the
API gateway directory and the API gateway transfers the message to the API_OUT
directory.
9. Router for Novell GroupWise obtains the SEARCH message from the API_OUT
directory and places it according to the MSG-TYPE keyword in the \Program
Files\Exchsrvr\Conndata\GWRouter\freebusy directory. The following is an example
of a response to a free/busy query:
WPC-API= 1.2;
Header-Char= T50;
Msg-Type= SEARCH;
Orig-Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51;
To=
CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant;
Busy-For=
CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM;
Busy-Report=
Start-Time= 11/12/03 17:00;
End-Time= 12/12/03 8:00; ,
Start-Time= 12/12/03 17:00;
End-Time= 15/12/03 8:00; ,
Start-Time= 15/12/03 17:00;
End-Time= 16/12/03 8:00; ,
Start-Time= 16/12/03 17:00;
End-Time= 17/12/03 8:00; ,
Start-Time= 17/12/03 17:00;
End-Time= 18/12/03 8:00; ,
Start-Time= 18/12/03 17:00;

478
End-Time= 19/12/03 8:00; ,
Send-Options= None;
-END-
10. Gwisecal.dll retrieves the message and translates it to Exchange format.

Gwisecal.dll then passes the data to Mapical.dll.
11. Mapical.dll updates the free/busy record for the Novell GroupWise user in the
free/busy system folder.
12. Exchange Server 2003 returns the free/busy information to the requesting
Outlook user.
Free/Busy Lookups from Novell GroupWise

Calendar Connector performs the following steps for free/busy lookups for Exchange
Server 2003 users from Novell GroupWise:
1. A Novell GroupWise user performs a free/busy search for an Exchange user. The
Novell GroupWise client generates a SEARCH message, which the Novell
GroupWise system transfers to the API gateway.
2. The API gateway transfers the SEARCH message from the WPCSOUT directory
to the API_OUT directory, where Router for Novell GroupWise picks it up and places
it according to the MSG-TYPE keyword in the \Program
Files\Exchsrvr\Conndata\GWRouter\FreeBusy directory. The message is addressed
to the Exchange user for whom the Novell GroupWise user requests free/busy
information. The structure of the message is similar to the one generated by
Gwisecal.dll for queries from Exchange Server users.
3. Gwisecal.dll obtains the SEARCH message from the \FreeBusy directory,

translates it into Exchange Server format, and then passes the request to Mapical.dll.
4. Mapical.dll processes the free/busy query and returns the requested information
to Gwisecal.dll.
5. Gwisecal.dll translates the request to a SEARCH-type response and puts it in the

\Program Files\Exchsrvr\Conndata\GWRouter\Togwise directory. The structure of the
message is similar to the one generated by the Novell GroupWise system for a
response to queries from Exchange users.
6. Router for Novell GroupWise obtains the message from the \Togwise directory
and puts it in the API_IN directory of the API gateway.
7. The Novell GroupWise system routes the response to the user who issued the
free/busy query.
479
Note:
GroupWise users must have a visibility setting of System or higher to receive
calendar information from Exchange.
How to Check Whether a Server Running

Exchange Server Contains a Replica of the
Free/Busy System Folder for the
Administrative Group
This topic explains how to determine if a server running Exchange Server contains a replica
of the free/busy system folder for the administrative group. You would do this when deciding
where to install Calendar Connector, because it can be installed only on a server containing a
replica of that folder.
Before You Begin

Before you perform the procedure in this topic, make sure you have the correct permissions.
Calendar Connector requires permissions to read and create items in the Free/Busy system
folder. In the properties of the Free/Busy folder for your local administrative group, select the
Permissions tab, and then click Client Permissions. In the Client Permissions dialog box,
verify that the Default account is assigned the Editor role.
Procedure
To check whether a server running Exchange Server contains a replica of the
free/busy system folder for the administrative group
1. In Exchange System Manager, click the Folders container.
2. Right-click Public Folders.
3. Select View System Folders. Free/busy folders are named according to

their administrative group and reside in the SCHEDULE+ FREE BUSY container.
4. Display the properties of the system folder for your local administrative
group, and select the Replication tab. Make sure that the public folder store of
the server running Exchange Server that is running Calendar Connector is
included in the list of public folder stores..
480
Protocol Virtual Servers in Exchange

Server 2003
Microsoft Exchange Server 2003 includes protocol virtual servers, several of which provide
client access. Protocol virtual servers rely on Internet Information Services (IIS) and
Active Directory directory service for their operations and services. By default, Exchange
Server 2003 Setup creates the following protocol virtual servers:
• Exchange Virtual Server Enabled by default, this virtual server includes

several virtual directories: Exadmin, Exchange, Microsoft-Server-ActiveSync,
Microsoft Office Outlook Mobile Access and public. It provides WebDAV access to
Exchange mailbox and public folder data in Outlook Web Access, Microsoft Outlook
Mobile Access, and Exchange ActiveSync users.
• IMAP4 Virtual Server Disabled by default, this virtual server provides IMAP4
client access to Exchange mailbox and public folder data.
• NNTP Virtual Server Disabled by default, this virtual server provides NNTP
client access to Exchange public folder data.
• POP3 Virtual Server Disabled by default, this virtual server provides POP3
client access to Exchange mailbox data.
• SMTP Virtual Server Enabled by default, this virtual server provides SMTP
messaging services.
Exchange Server 2003 installs and manages the POP3 and Internet Message Access
Protocol version 4rev1 (IMAP4) client access protocols, but uses the SMTP and NNTP
protocol stacks provided by IIS. SMTP is discussed in detail in SMTP Transport Architecture.
This section focuses on the other Internet client access protocols: HTTP, IMAP4, POP3, and
NNTP.
• How Exchange 2003 Integrates with IIS IIS and Exchange 2003 are tightly
integrated through the use of protocol stubs and a shared memory queue. The
implications of this integration, as they relate to deploying, managing, and
troubleshooting messaging services are discussed throughout this section.
• Internet Standard Client Access Protocols, including HTTP, NNTP, IMAP4,

and POP3 You must understand the way in which Exchange Server 2003 protocol
virtual servers use Internet protocols for client access to Exchange data and services.
• The Architecture of RPC over HTTP Remote procedure call (RPC) over HTTP
enables Microsoft Office Outlook 2003 clients to securely connect to an Exchange
server over the Internet using Microsoft Exchange MAPI transport services. This
section discusses how RPC over HTTP works and how to implement it in your
organization.
481
• Exchange Mobility Features Exchange 2003 includes new mobility features

such as Outlook Mobile Access and Exchange Server ActiveSync, both of which are
also implemented as protocol virtual servers. This section discusses how these
features work and how to implement them in your organization.
IIS Integration
In Exchange Server 2003, all Internet-based client access protocols run as part of IIS. When
you install Exchange Server 2003, it extends, rather than replaces, the SMTP and NNTP
protocol stacks in IIS, using additional command verbs and advanced routing components.
The Exchange Server 2003 Internet protocol stacks are as follows:
• POP3 POP3 is the most basic message retrieval protocol. POP3 can access
only the user's Inbox folder. Exchange 2003 supports POP3 for access by POP3
clients.
• IMAP4 IMAP4 is used to access mailbox information. IMAP4 is more advanced

than POP3, because it supports basic online capabilities and access to folders in
addition to the Inbox. In addition to providing limited access to user mailboxes, the
Exchange 2003 implementation of IMAP4 provides the following:
• Access to public folders
• Delegate access to another user's mailbox
• Anonymous access to specific IMAP account names
• SMTP SMTP is the primary messaging protocol for Exchange Server 2003.
SMTP is used to move messages between servers in the same routing group and is
the preferred protocol for moving messages between routing groups. The
enhancements made by Exchange Server 2003 to the IIS SMTP stack include:
• Commands that support fault-tolerant routing
• An advanced queuing engine
• An enhanced message categorization agent
• NNTP The Exchange Server 2003 implementation of NNTP adds the following
functionality to NNTP:
• Content indexing provides search functionality to public folders
• Full newsfeed acceptance, regardless of storage choice (file system or

public folders) on the back end
• MAPI or NNTP clients can read or post to newsgroups supported by the

Microsoft Exchange Information Store service
482
• WebDAV WebDAV is an extension to HTTP that provides a Web interface to the

Microsoft Exchange Information Store service.
Examining the Interprocess Communication

Between IIS and Microsoft Exchange
Except for MAPI, Exchange Server 2003 client access protocols are not part of the Microsoft
Exchange Information Store service. Rather, they are hosted by IIS. Separating these
protocols from the Microsoft Exchange Information Store service increases the reliability,
flexibility, and scalability of Exchange Server 2003. However, the protocols must be able to
transfer data rapidly between IIS and the Microsoft Exchange Information Store service. To
make the rapid transfer of data easier, Exchange Server 2003 contains a queuing layer
named the Exchange Interprocess Communication (ExIPC) layer, also referred to as EPOXY,
because it is implemented in Epoxy.dll.
As illustrated in the following figure, ExIPC works in tandem with Exchange Installable File
System (ExIFS) to move messages between IIS and Exchange Server 2003.
ExIPC offers high-performance interprocess communication functionality. Like lightweight

remote procedure calls (LRPCs), ExIPC uses shared memory (32 kilobyte mapped memory
sections), built on the Shared Memory Circular Queue (SMQ) model, to communicate
between the INETINFO and STORE processes, and the DSAccess cache. This ensures that
the cache is available to all processes that run DSAccess. ExIPC includes the Microsoft
Exchange Information Store service and a protocol DLL that provides a binding facility (fast
reliable communication between IIS and the Microsoft Exchange Information Store service), a
shared memory heap, and a pair of queues based on shared memory.
483
Exchange Server 2003 storage and protocol architecture
Exchange Installable File System

ExIPC works in tandem with Exchange Installable File System (ExIFS) to move messages
between IIS and Exchange. ExIFS provides access to the Microsoft Exchange Information
Store service through Microsoft Win32 file system APIs. ExIFS makes the streaming file
appear to IIS as many smaller files named virtual files. IIS obtains a handle to a virtual file
and writes incoming data directly to the stream file through ExIFS. Similarly, outgoing
messages are read directly from the stream file through ExIFS. A message becomes a list of
pages (with the page numbers held in the .edb file) in the streaming file, and any needed
properties are promoted from the .stm file to the .edb file.
484
ExIFS architecture
A message then becomes a list of pages (with the page numbers held in the .edb file) in the
streaming file. Any required properties are promoted from the .stm file to the .edb file.
This figure illustrates file streaming between IIS and ExIFS. ExIFS represents streaming files
to IIS as smaller virtual files. Data, such as checksum data and promotion of properties data,
moves first from ExIFS to Extensible Storage Engine, and then to the Exchange information
store. IIS and the Exchange information store also exchange information, such as the page
numbers on which ExIFS placed a message, so that the page numbers are recorded and
stored on the record representing the message in the Exchange information store.
Inbound Messages
When a message enters the system, IIS creates a new file in ExIFS. The data is written to the
new file on reserved pages. ExIFS then returns the list of pages to the Exchange store. The
Exchange information store processes the pages and stores them in a record representing
the message. Extensible Storage Engine then commits the data on the reserved pages by
logging the information to the storage group's transaction log files. At this point the pages
change from a reserved state to a committed state.
Note:
If the storage group has circular logging turned on, Extensible Storage Engine does
not write data that comes in through the streaming file data to the transaction log
files. In this instance, streaming file data is first placed in the streaming file. The data
is only required in the transaction logs for recovery and log roll forward after a
restore. Because log roll forward can only occur when circular logging is turned off,
the streaming file data is only useful in the transaction logs when circular logging is
turned off.
485
Outbound Messages
When a message is retrieved from the system, the Exchange store process receives the list
of pages referenced by the message. This list of pages is passed to IIS. IIS then opens a file
in ExIFS using the list of pages. The message is quickly streamed out of the Exchange
information store, without conversion.
File System Semantics

ExIFS reflects Win32 file calls to the Exchange store. Therefore, you can use the Win32
filesystem API to access data in Exchange Server. For example, calls such as FindFileFirst
can access a public folder for a list of messages. Additionally, you can map a drive to your
own mailbox and use the conventional command line functions to access your Inbox. ExIFS
displays the contents of an Exchange database as ordinary files.
ExIFS interaction with Microsoft Windows Explorer and the Exchange store
This figure illustrates that the interaction with the store achieved through ExWin32.dll.
ExIFS.sys also supports all the file system-related functions that are exported from
kernel32.dll, in addition to the interaction with the Exchange store achieved through
ExWin32.dll.
ExIPC Binding Facility

The ExIPC binding facility enables the creation and connection of an arbitrary number of
queues between two processes such as INETINFO and STORE. This binding facility includes
Central Queue Manager for keeping track of the queues and processes with which a
particular process communicates. This facility is used for unbinding and queue clean-up if a
failure on the other process occurs.
Each protocol queue is circular and fixed in size. During interprocess communications, data is
stored in the shared memory heap and referenced by a data handle. The data handle is
enqueued and dequeued. The IIS or the Exchange store then references a part of shared
memory from the handle.
486
ExIPC Protocol Stubs

Each protocol has an ExIPC interface in STORE.exe. For example, the ExIPC protocol stub
for POP3 is expop.dll. This component passes parameters (for example, a pointer to a
message or an action) from STORE.exe to the ExIPC interface (drviis.dll) in INETINFO.exe.
MAPI and RPC over HTTP

When the Exchange Server transport service is configured in Microsoft Outlook, Outlook uses
the MAPI to communicate with the Exchange Information Store service. These MAPI calls are
all RPC-based. Although RPC calls work well in a LAN or WAN environment, they are
generally discouraged for use over the Internet because of firewall and other security
concerns. With earlier versions of Exchange, external Outlook users who wanted MAPI
access to Exchange had to first establish VPN connections to their organization's private
network.
The RPC Proxy runs on an IIS computer. It accepts RPC requests coming from the Internet,
efficiently connects across the Internet to RPC server programs, and runs remote procedure
calls without first requiring a VPN connection. It also performs authentication, validation, and
access checks on those requests without opening multiple ports on your firewall. This is done
with the help of an intermediary referred to as RPC-over-HTTP Proxy, or RPC Proxy.
If the request passes all tests, RPC Proxy forwards the request to the RPC server that
performs the actual processing. With RPC over HTTP, the RPC client and server do not
communicate directly. Instead, they use RPC Proxy as an intermediary.
RPC over HTTP

RPC over HTTP enables client programs to use the Internet to run procedures that are
provided by server programs on distant networks. RPC over HTTP routes its calls through an
established HTTP port. Therefore, its calls can cross network firewalls on both the client and
server networks. RPC Proxy is located on the RPC server's network. RPC Proxy establishes
and maintains a connection to the RPC server. It serves as a proxy, dispatching remote
procedure calls to the RPC server and sending the server's replies back across the Internet
to the client program.
RPC over HTTP has both server-side and client-side requirements, which are detailed in the
following table.
487
Requirements for implementing RPC over HTTP
Client-side requirements Microsoft Windows XP Professional with

Service Pack 1 or later
Hotfix from Microsoft Knowledge Base

331320
Microsoft Office Outlook 2003
Server-side requirements Microsoft Windows Server 2003 on

Exchange server
Exchange Server 2003 on all front-end and

back-end servers
Windows Server 2003 on global catalog
servers
Windows Server 2003 on RPC proxy

servers
When the client program issues an RPC, using HTTP as the transport, the RPC run-time
library on the client contacts RPC Proxy. Depending on whether the RPC client was asked to
use HTTP or HTTPS, either TCP port 80 or TCP port 443 is used, respectively. RPC Proxy
contacts the RPC server program and establishes a TCP/IP connection. The client and RPC
Proxy maintain their HTTP or HTTPS connection across the Internet.
The client's HTTP or HTTPS connection to RPC Proxy can pass through a firewall (subject to
appropriate access permissions) if a firewall is present. The server can then run the RPC and
use the connection through RPC Proxy to reply to the client.
If either the client or the server disconnects for any reason, RPC Proxy detects that the
connection has been severed, and ends the RPC session. As long as the session continues,
RPC Proxy maintains its connections to the client and the server. It forwards RPCs from the
client to the server, and sends replies from the server to the client.
The RPC client program can route its RPC calls over the Internet by creating a string binding
of the following form:
[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,'rpcprox
y'=rpc_proxy:rpc_port]
Where:
• object_uuid specifies an RPC object universal unique identifier (UUID).
• ncacn_http selects the protocol sequence specification for RPC over HTTP.
• rpc_server is the network address of the computer that is running the RPC server
process. The server address must be specified in a form visible and understandable
488
by RPC Proxy computer, rather than by the client. Because the client does not
connect directly to the server, it does not resolve the name of the server or establish
a connection to it. RPC Proxy establishes the connection on the client's behalf.
Therefore, rpc_server must be a name recognizable by RPC Proxy.
• endpoint specifies the TCP/IP port that the RPC server process listens to for
RPCs.
• HttpProxy optionally specifies an HTTP proxy server on the RPC client's network,
such as Microsoft Proxy Server. If a proxy server is selected, no port number is
specified, the RPC stub uses port 80 by default if SSL is not requested, and port 443
if SSL is specified.
• RPCProxy specifies the address and port number of the IIS computer that acts as
a proxy to the RPC server. You need to specify this only if the RPC server process
resides on a different computer than RPC Proxy. If you do not specify a port number,
by default the RPC client stub uses port 80 if SSL is not specified and port 443 if SSL
(HTTPS) is specified.
RPC Virtual Directory

Although RPC over HTTP is a Windows Server 2003 feature and not an IIS feature, it is
implemented as an Internet Server Application Programming Interface (ISAPI) extension that
runs inside a protocol virtual server. The RPC virtual directory is created under Default Web
Site when RPC Proxy service is installed. You should use SSL together with Basic
Authentication.
RPC over HTTP and the Microsoft Exchange

While RPC over HTTP is implemented as a protocol virtual server, ExIPC is not involved in
the communication process. Outlook clients using RPC over HTTP are treated as
conventional MAPI clients, and they communicate with the Microsoft Exchange Information
Store service using the MAPI interface to the Exchange information store.
Internet Protocol Details

As mentioned, Exchange 2003 supports several Internet standards-based client protocols,
including HTTP, POP3, IMAP4, and NNTP. These protocols are described in more detail in
the following subsections.
489
HTTP
The Microsoft Exchange Information Store service includes native HTTP access to data.
Every object in the Microsoft Exchange Information Store service is URL–accessible with
short, easily understood names. Because every object in the Microsoft Exchange information
store is URL–accessible, users have several different ways to access objects in mailboxes or
public folder hierarchies. The URL for an object is based on its location in the hierarchy and
usually contains the subject of the item.
When a user opens a message through Microsoft Outlook Web Access, the IIS request
processor calls the Exchange HTTP ISAPI application that parses the information in the
request and determines the following:
• The action to be performed Exchange HTTP ISAPI determines whether the

user is opening a mailbox, opening a folder, reading e-mail, creating e-mail, and so
forth.
• Browser information Exchange HTTP ISAPI determines the browser type,

version, and rendering information.
The server then determines whether the user has permissions to access the item. If the user
has access rights, the object state (read, unread), object type (folder, message, and others),
and item type (message, appointment, contact) are determined.
The Exchange HTTP ISAPI extension then matches the object attribute to its corresponding
form definition. If a form definition does not exist for a particular object attribute, the default
form is used, (the one used to read an e-mail item). The Exchange HTTP ISAPI extension
then parses the form and queries the information store to bind to the data. After receiving the
data from the Microsoft Exchange Information Store service, the Exchange HTTP ISAPI
extension renders the data in HTML or XML, based on the browser type and version, and the
client displays the message.
The following steps show this process in more detail:
1. The browser sends a request for an e-mail message.
2. The browser issues a GET request for a URL, such as

http://server/vroot/user/folder/message.eml. This URL does not have any query
strings attached, which would be processed first, so the server returns a rendering of
this resource based on its Message-Class and the default action configured for this
class.
3. Exchange ISAPI processes the request.
4. When IIS receives the request, it is passed to the Exchange ISAPI component
Davex.dll. This component parses the request for the following information and then
sends the request to the Exchange store. The following table illustrates the passed
item and its purpose.
5. The Microsoft Exchange Information store service then determines the item type.
490
6. The server verifies that the user has access to the item, determines the type of
object (folder, message, task, and more), and returns the item type and its state
(read, unread, and more) to the ISAPI application.
7. Exchange ISAPI selects the form.
8. The ISAPI program takes the object attributes and looks for a form definition in
the forms registry that matches the object's type. If a matching form definition is not
found, a default form stored in Wmtemplates.dll is used. If the browser language is
not English, language specific strings are loaded from other template libraries in the
\Exchsrvr\Res\Directory.
9. The Microsoft Exchange Information Store service retrieves data for the form.
10. After a form definition is found, the ISAPI program parses the form, calling the
Microsoft Exchange Information Store service, to retrieve the data it references.
11. Exchange ISAPI renders the form.
12. When the data is returned from the Microsoft Exchange Information Store
service, the form is rendered in the appropriate HTML and XML, and then goes to the
client.
Davex.dll passed items and usage
Passed item Used to
HTTP User-Agent Field header Determine the browser type, version,

operating system, and how to render
content
HTTP Accept-Language header Determine the language for the rendered

content
HTTP Translate header Determine if the content should display in a

browser or if it should return without
rendering to a WebDAV application
Query string Determine a specific action to perform
WebDAV and XML

Web Distributed Authoring and Versioning (WebDAV) is an extension to the HTTP 1.1
protocol (RFC 2518). HTTP and WebDAV enable rich collaborative interaction with the
information store in Exchange 2003. Exchange 2003 HTTP support enables adding,
modifying, copying, moving, and searching of folders and items and manipulation of attributes
on any object in the information store.
491
WebDAV creates improved performance and user experience over the basic Microsoft
Outlook Web Access client by exploiting client-side data binding and rendering. For example,
when you click the column header, you can sort the Inbox in several different ways, enabling
views based on the sender's name, the message subject line, or received date. The browser
caches the user interface elements, such as Internet Explorer HTML components, Microsoft
Jscript libraries, XSL, and Graphics Interchange Format (GIF) files. When the user changes
the sort criteria, the browser can reformat the user interface elements locally and query the
server for the view data.
The following process shows how clients access items in their Inbox using WebDAV:
• The client issues an HTTP GET request for the client's Inbox.
• IIS receives the request on port 80 (unless you change this configuration) and
sends the request to Davex.dll for processing using ExIPC.
• The request is forwarded using ExIPC to the Exchange Store OLE DB driver,
Exoledb.dll.
• Exoledb.dll renders the request in a format that the Exchange store can process,
sends the request to the Exchange store, and then retrieves the client's Inbox
properties from the Exchange store.
• After the clients Inbox properties are retrieved, Exchange 2003 routes the
information back to the client using the same components that it used to process the
client request.
POP3
Exchange Server 2003 implements a POP3 protocol stack that is compliant with RFC 1725,
RFC 1734, and RFC 1939. Exchange 2003 supports the ten POP3 commands listed in the
following table.
POP3 protocol command verbs
Command Description
List Used to display the identifier number and

the size (in bytes) of messages in the
mailbox, or to display the number and size
of a particular message. The list command
uses the following syntax, where n is the
message number that is returned by the list
command: list or list n.
492
Command Description
Uidl Used to return a numeric listing of all

messages in the mailbox and their
associated unique IDs, or the unique ID for
a particular message. The uidl command
uses the following syntax, where n is the
message number (as returned by the list
command) of the uidl that you want to view:
uidl or uidl n.
Retr Used to retrieve a message from the server.

You cannot use this command to retrieve a
message that is marked as deleted. The
retr command uses the following syntax,
where n is the message number that is
returned by the list command: retr n.
Stat Returns the total number of messages in

the mailbox and the total size (in bytes) of
the messages. You cannot use this
command to display more information about
individual messages. To do this, you must
use the list or retr commands, as
appropriate.
Dele Used to select a message for deletion.

When you select a message for deletion,
the message is deleted after you use the
quit command to disconnect the client from
the server. If the connection is interrupted
unexpectedly, the messages are not
deleted. The delete command uses the
following syntax, where n is the message
number that is returned by the list
command: dele n.
Rset Used to deselect all messages that are

selected for deletion.
493
Command Description
Noop This translates to "no operation." Although

this command does not perform any action,
if the command is successful, the server
replies with a positive response (OK+). You
can use this command to test whether the
server is online and receiving client
requests.
Top Used to display the message header and a

particular number of lines of the message.
Uses the following syntax, where x is the
message number that you want to view, and
y is the number of lines in the message that
you want to display: top xy.
Auth An IMAP command that is part of the POP3

specification, as detailed in Internet
Engineering Task Force (IETF) Request for
Comments (RFC) 1734. It permits you to
use alternative IMAP4 authorization
mechanisms.
Quit Used to quit the current POP3 session and

delete any messages that are selected for
deletion.
POP3 is considered a read only protocol. It only includes messages for requesting, reading,
and deleting messages. To send messages, POP3 clients use the SMTP protocol.
The following steps illustrate the interprocess communication steps that ExIPC goes through
when a client such as Microsoft Outlook accesses a mailbox on the Exchange server using
the POP3 protocol.
494
IIS and Exchange Server shared memory architecture
1. The client logs on to the server and gives the command to check e-mail.
2. A Request Mail Message 1 command is created on the IIS side.
3. IIS allocates shared memory from the shared memory heap for the request. A
corresponding handle is assigned to part of the shared memory. The handle, which
functions as a placeholder or pointer to a referenced part of memory, is then placed
in the circular memory queue (enqueued) in the direction of the Exchange information
store.
4. On the Exchange store side, the ExIPC.DLL for POP3 checks for incoming POP3
requests. The DLL receives the Request Mail Message and removes the handle from
the circular memory queue. The Exchange store-side POP3 stub references the
handle to the data in the shared memory heap.
5. If there are no failures or performance problems on the Exchange store side, the
ExIPC process is complete and the data is successfully communicated from the IIS to
the Exchange store. If a queue is full or the Exchange store has stopped, an error
message is returned.
6. A response (the mail message) is generated on the Exchange store side. The
Exchange information store allocates the appropriate shared memory for the
response from the shared memory heap. A corresponding handle is assigned to that
shared memory. The handle is then enqueued in the direction of IIS.
7. IIS removes the handle from the circular queue, references the shared memory,
and binds them together.
If there are no failures or performance problems on the IIS side, the response is complete
and the data is successfully communicated from the Exchange store to IIS.
495
IMAP4
Exchange 2003 is IMAP4 rev 1 compliant, in accordance with RFC 2060, RFC 2088 and
RFC 1731. IMAP is comprised of over 30 commands, through which messages can be
searched, fetched, and expunged from the Exchange server. IMAP is well suited for online
and offline use. IMAP can connect to multiple mailboxes (if permissions are in place) and
public folders and can be used for non e-mail purposes, such as news services.
IMAP4 goes beyond the functionality available by using POP3. IMAP4 allows users to access
any one of their folders, not just their Inbox. Because of this, it is more complex than POP3.
However, it still adheres to the same standard of being a read-only protocol. Like POP3,
IMAP4 also uses SMTP for sending e-mail.
Exchange 2003 supports the IMAP4 commands listed in the following table.
IMAP4 commands supported by Exchange Server 2003
Command Description
APPEND Appends the literal argument as a new

message to the end of the specified
destination mailbox. This argument must be
in the format of an RFC-822 message.
AUTHENTICATE Indicates an authentication mechanism to

the server (for example, AUTHENTICATE
KERBEROS_V5).
CAPABILITY Used to request a list of capabilities that the

server supports.
CHECK Used to request a checkpoint of the

currently selected mailbox. A checkpoint
refers to any implementation-dependent
details associated with the mailbox (for
example, resolving the server's in-memory
state of the mailbox with the state on its
disk) that is not executed as part of each
command.
CLOSE Permanently removes from the currently

selected mailbox all messages that have
the \Deleted flag set, and returns to
authenticated state from selected state.
496
Command Description
COPY Used to copy the specified message(s) to

the end of the specified destination mailbox.
The flags and internal date of the
message(s) are preserved in the copy.
CREATE Used to create a mailbox with the particular

name. An OK response is returned only if a
new mailbox with that name is created.
DELETE Permanently removes the mailbox with the

particular name. A tagged OK response is
returned only if the mailbox is deleted.
EXAMINE The same as SELECT and returns the

same output. However, the selected
mailbox is identified as read-only. No
changes to the permanent state of the
mailbox, including per-user state, are
permitted.
EXPUNGE Permanently removes from the currently

selected mailbox all messages that have
the \Deleted flag set.
FETCH Retrieves data associated with a message

in the mailbox.
LIST Returns a subset of names from the

complete set of all names available to the
client.
LOGIN Identifies the client to the server and carries

the plain text password authenticating this
user.
LOGOUT Informs the server that the client is done

with the connection.
LSUB Returns a subset of names from the set of

names that the user declared as being
"active" or "subscribed."
497
Command Description
NOOP This translates to "no operation." Although

this command does not perform any action,
if the command is successful, the server
replies with a positive response (OK+). You
can use this command to test whether the
server is online and receiving client
requests.
RENAME Changes the name of a mailbox. A tagged

OK response is returned only if the mailbox
is renamed.
SEARCH Searches the mailbox for messages that

match the specified searching criteria.
Searching criteria consist of one or more
search keys.
SELECT Selects a mailbox so messages in the

mailbox can be accessed.
STATUS Requests the status of the indicated

mailbox. It does not change the currently
selected mailbox, nor does it affect the state
of any messages in the queried mailbox.
STORE Alters data associated with a message in

the mailbox.
SUBSCRIBE Adds the specified mailbox name to the

server's set of "active" or "subscribed"
mailboxes as returned by the LSUB
command. This command returns a tagged
OK response only if the subscription is
successful.
UID This command has two forms. In the first

form, it takes as its arguments a COPY,
FETCH, or STORE command with
arguments appropriate for the associated
command. In the second form, the UID
command takes a SEARCH command with
SEARCH command arguments.
498
Command Description
UNSUBSCRIBE Removes the specified mailbox name from

the server's set of "active" or "subscribed"
mailboxes, as returned by the LSUB
command. This command returns a tagged
OK response only if un-subscription is
successful.
NNTP
Network News Transfer Protocol (NNTP) is a TCP/IP protocol based on text strings that are
sent bi-directionally over seven-bit ASCII TCP channels. The IETF owns the NNTP protocol,
which is defined in RFC 977. NNTP is commonly referred to as the Internet News Protocol,
because it contains the rules for transporting news articles from one computer to another.
NNTP is discussed here as a client/server protocol. It also encompasses server-to-server
based news transfer.
The NNTP service in Windows is designed to support a stand-alone newsgroup server that
can easily create group discussions. When Exchange 2003 is installed, the NNTP service is
enhanced with the ability to interface with other news servers through news feeds. The NNTP
service can communicate with external NNTP servers to make popular USENET groups
available to users.
The standard storage location for the NNTP service is in one or more directories in the file
system. With Exchange Server 2003, the NNTP service can also store newsgroups in the
public folders of any available public folder tree. Internet Newsgroups folder is the default
location for newsgroups. The NNTP service uses virtual directories to reference these
locations.
You can arrange multiple news servers in a master server/subordinate server layout. This
enables clients to connect to a large group of servers and still maintain accurate views of
newsgroup content. A bank or group of servers provides additional scalability for many clients
and provides fault tolerance if a subordinate server goes offline.
The Exchange Server 2003 implementation of NNTP provides the following additional
features for this protocol:
• Content indexing provides search features for public folders.
• Full news feeds are accepted independent of back-end storage.
• MAPI or NNTP clients can read or post to newsgroups that are supported by the
Exchange information store.
499
Configuration Settings in Active Directory

Although Exchange integrates with IIS, as soon as Exchange 2003 is installed, protocol
virtual servers are managed by Exchange System Manager, and not by Internet Services
Manager. When you add, remove, or configure an item in Exchange System Manager, the
configuration changes are first saved to the Microsoft Active Directory directory service and
then replicated to the IIS metabase, on the appropriate Exchange 2003 server, by the
Directory Service/Metabase Synchronization (DS2MB) function that runs in the System
Attendant process.
Note:
You can view a semi-graphical representation of Exchange 2003 configuration
information stored in Active Directory in Microsoft Knowledge Base article 252370,
"Layout of Exchange Configuration in Active Directory."
Configuration Settings in the Metabase

The IIS metabase is a hierarchical database that is used to store configuration values for IIS
and Exchange 2003. The IIS metabase is both a storage mechanism and an application
programming interface (API) set used to make changes to the configuration parameters.
The function of the DS2MB process is to transfer configuration information from

Active Directory to the Exchange server's local IIS metabase. For performance and scalability
reasons, this configuration is stored in the local IIS metabase instead of in the registry.
Note:
On computers running Windows 2000 Server, the IIS metabase is located at
System32\Inetsrv\Metabase.bin. On computers running Windows Server 2003, the
IIS metabase is located at metabase.xml. The IIS metabase can be manipulated
through a variety of tools. On computers running Windows Server 2003, the built-in
IISCNFG tool can be used. On computers running Windows 2000 Server, the
MetaEdit 2.2 or later tool from the IIS Resource Kit is a good option. You can
download the IIS 6.0 Resource Kit from the Internet Information Services (IIS) 6.0
Resource Kit Tools Web site.
Paths in the metabase are named keys. Properties can be set at each key, and each property
can have attributes that customize that property. All identifiers that are present in the directory
service image of the subtree are required in the metabase, including identifiers such as
KeyType. Additionally, the Relative Distinguished Name of the object in the directory is
mapped directly to the key name in the metabase.
500
IIS Metabase Updates Through DS2MB

DS2MB is a subprocess that is launched when System Attendant is started, and every 15
minutes thereafter. DS2MB copies all subtrees from Active Directory without changing the
shape of the subtree. This is a one-way write from Active Directory to the metabase; the
metabase never writes to Active Directory. It does not add or compute any attribute when
copying.
Note:
The DS2MB process overwrites changes that are made to Exchange virtual servers
and directories using the IIS snap-in with information that is contained in Active
Directory.
The operation of SMTP, POP3, IMAP4, and HTTP depends on the replication by DS2MB. Not
all settings are synchronized from Active Directory, some are written to the metabase directly
during the installation of Exchange.
Upon instantiation, DS2MB registers with the configuration domain controller. The
configuration domain controller notifies DS2MB, within 15 seconds, of any changes that are
made to the Exchange configuration . As soon as the change is replicated to the configuration
domain controller, it must be replicated to the metabase by DS2MB.
High Water Marks

High water marks are entries in the metabase that enable DS2MB to track changes that have
been synchronized from Active Directory. High water mark entries are entered in the IIS
metabase in the form of GUIDs. These GUIDs appear under the [/DS2MB/HighWaterMarks]
node in the metabase, as illustrated below:
[/DS2MB/HighWaterMarks]
KeyType : (STRING) "Ds2mbHighwatermarks"
[/DS2MB/HighWaterMarks/{BE583A06-9083-400F-954C-CF4ACCA78B04}]
[/DS2MB/HighWaterMarks/{028C8F78-8CF0-43D9-9B35-9819D538849F}]
[/DS2MB/HighWaterMarks/{84ECD394-05BB-4661-BA1D-81D3E32BF804}]
Because DS2MB handles the entry and synchronization of high water marks in the metabase,
there is usually no reason to adjust or manage this information. However, there are known
scenarios in which the resolution includes deleting the high water mark entries from the
metabase to reset them.
Front-End Server Architecture

A front-end server is a server running Exchange Server 2003 that does not host a database
(except when also serving as an SMTP server), but instead forwards client requests to the
back-end server for processing. The front-end server uses Lightweight Directory Access
501
Protocol (LDAP) to query Active Directory to determine which back-end server hosts the
user's mailbox. A back-end server is a server running Exchange Server 2003 that maintains
at least one database.
This architecture is available only for RPC over HTTP, HTTP/WebDAV, POP3, and IMAP4
clients. It is not intended for MAPI or NNTP clients. Clients that are supported connect to a
front-end server that proxies client commands to the user's back-end server, which hosts an
Exchange information store.
This functional division between a front-end server and a back-end server provides several
benefits. For example:
• Single Namespace As multiple back-end servers are configured to handle

additional mailboxes, it is best to identify all the servers with a single name. You can
refer to a front-end server with a single name, and it can proxy user requests to the
correct back-end server containing that user's mailbox. If multiple front-end servers
are configured to manage a high number of requests, a single namespace for these
servers is maintained by configuring the Domain Name System (DNS) with one name
mapped to the IP address on the server. It is not important which front-end server the
client connects to.
• Offload SSL Encrypting and decrypting message traffic uses many CPU cycles.
A front-end server can perform encryption work, giving the back-end server more
cycles to manage the mailbox and public folder information stores.
• Public Folder Referrals for IMAP4 Clients Many IMAP4 clients do not support
referrals. With this architecture, the front-end server can retrieve public folders that
exist on a server other than the user's e-mail server.
• Server Location You can put the back-end servers that contain the databases
behind a firewall for increased protection. You can configure the firewall to allow
traffic only from the front-end server. Additionally, you can put a reverse proxy (such
as ISA Server) in front of a front-end server and only publish the front-end server. It is
not necessary to publish the back-end mailbox servers to the Internet. Therefore, you
can configure your firewalls and reverse proxies to allow traffic only to the front-end
server.
Considerations When Using Front-End Servers

You can configure either Exchange Server 2003 Standard Edition or Exchange Server 2003
Enterprise Edition for use as a front-end server in a front-end and back-end server
configuration. The following considerations apply when you configure either edition as a front-
end server:
• If the front-end server accepts SMTP mail from the Internet, you must start the
Microsoft Exchange Information Store service and mount at least one mailbox store.
502
In certain situations (most notably in the generation of non delivery reports), the
SMTP service requires a mailbox store to perform a conversion.
• If the mailbox store is not mounted, messages that must be converted are stuck
in the local delivery queue. For security reasons, make sure that user mailboxes are
not homed on the mailbox store of a front-end server. If there are servers that are
running Exchange Server 5.5 in the same site (routing group), you must configure the
Microsoft Exchange MTA Stacks service to run on the front-end server. In this
configuration, the MTAs can bind and transfer mail by using RPCs.
• If X.400 connectors or Exchange Development Kit (EDK) gateway connectors

are homed on the front-end server, the MTA service must also run on the front-end
server. If you delete all public folder and mailbox stores, you cannot change the
configuration by using Internet Services Manager.
• If you must change the configuration by using Internet Services Manager, for
example when you change an SSL encryption configuration, make sure that you
either complete the procedures that this guide describes before you remove the
stores, or leave the private information store intact on the front-end server.
• When you create a front-end server, do not delete the First Storage Group object
in Exchange System Manager. The Microsoft Exchange Information Store service
(and its related services) depends on the First Storage Group object.
Exchange ActiveSync and Exchange 2003

Exchange ActiveSync enables you to synchronize data between your mobile device and
Exchange Server 2003. E-mail, contacts, and calendar information (Personal Information
Manager, or PIM, data) can all be synchronized. This feature was previously available
through Mobile Information Server and was referred to as Microsoft Server ActiveSync. It is
now integrated with Exchange Server 2003.
With Mobile Information Server, devices running Microsoft Windows Powered

Pocket PC 2002, Microsoft Windows Powered Pocket PC 2002 Phone Edition, and Microsoft
Windows Powered Smartphone had the Server ActiveSync client component installed and
were supported.
With Exchange ActiveSync, devices that are running Pocket PC 2002, Pocket PC 2002
Phone Edition, and Smartphone are still supported. Additionally, Microsoft Windows Powered
Pocket PC 2003 devices are supported. Pocket PC 2003 devices enable greater granularity
in scheduling synchronization and also support the Always Up To Date functionality that is
introduced in Exchange Server 2003.
Exchange ActiveSync is implemented in the following files:
• Massync.dll OMA Sync ISAPI extension DLL

503
• Masperf.dll OMA Sync Performance Counter DLL
• MasPerf.ini OMA Sync Performance Counter INI
• Masperf.h OMA Sync Performance Counter header
Exchange ActiveSync Protocol Architecture

The sync protocol is a request and response protocol built on a client and server
communications model. It is built on the HTTP protocol, using the HTTP POST request and
response mechanism and the HTTP OPTIONS command. The HTTP POST header specifies
a protocol command and, if the command requires it, command data is sent in the HTTP
POST body. The data is typically formatted as compressed Wireless Binary XML (WbXML),
which makes efficient use of the constrained bandwidth of mobile clients.
The client initiates communication by posting a request. When the server receives the
request, it parses the request and then sends an HTTP POST response that contains the
requested data in its body.
The sync protocol requires a TCP/IP connection between the client and server. However, the
underlying network layers are implementation-specific. Three common transport layers that
support the protocol are GPRS, CDMA 1xRTT, and IEEE 802.11. The sync protocol requires
that any transmission errors are handled by the networking software, and that the protocol
messages sent between the client and server are complete and error-free.
The sync protocol is designed to enable any mobile client to efficiently synchronize PIM data
with data stored on an Exchange server. To do this, the client uses the sync protocol to talk to
the Exchange front-end server component, which provides the synchronization as the means
to retrieve data from the Exchange store.
The following figure shows the functional components of the client and server
communications model that is used by the sync protocol.
504
Exchange ActiveSync communication between client and server
The following steps occur for all commands that the client sends to the server:
1. The client creates a request and sends it to the sync server as an HTTPS POST.
2. The sync server processes the request, communicating with the Exchange back-
end server to access the user's PIM data.
3. The sync server creates a response and sends it to the client as an HTTPS
POST response.
4. The client processes the response and, if necessary, updates the local PIM data.
The following steps occur when the client sends a Sync command:
1. The client identifies any changes made to local PIM data since the last sync.
2. The client creates a Sync command containing these changes.
3. The client sends the command to the sync server as an HTTPS POST.
4. The sync server identifies changes made to data on the server since the last
sync, communicating with the Exchange back-end server to access the user's data.
5. The sync server resolves any conflicts between changes made to items on the
client and on the server.
6. The sync server creates a response containing server changes to be replicated

on the client.
7. The sync server sends the response as an HTTPS POST response.
8. The client processes the response and updates the local PIM data.
505
Sync Protocol Versions and Device Support

Exchange ActiveSync requires that the client and the server use the same protocol version.
Microsoft Mobile Information Server uses the ActiveSync Protocol v1.0 for
Exchange ActiveSync. Exchange Server 2003 uses the new and improved ActiveSync
protocol v2.0 for Exchange ActiveSync, but also supports ActiveSync protocol v1.0 for
backward compatibility.
ActiveSync protocols supported by Mobile Information Server 2002 and Exchange

Server 2003
Server Protocols Supported
Mobile Information Server 2002 1.0
Exchange Server 2003 1.0 and 2.0
The Pocket PC 2002 client uses ActiveSync protocol v1.0 for Exchange ActiveSync. It can be
used against Mobile Information Server and Exchange Server 2003 using v1.0. The
Pocket PC 2003 client supports v1.0 and v2.0 protocols. It can negotiate the protocol to be
used.
Table 9.6 ActiveSync protocols supported by Pocket PC 2002 and Pocket PC 2003
devices
Device Protocols Supported
Pocket PC 2002 1.0
Pocket PC 2003 1.0 and 2.0
Therefore, Pocket PC 2002 and Pocket PC 2003 devices can be used against Mobile
Information Server and Exchange 2003.
Sync Protocol Commands

With ActiveSync protocol v 1.0, a typical sync session includes the following commands:
• GetHierarchy This command is used to retrieve the entire hierarchy of folders.
• GetItemEstimate This command is used by the client to estimate the number of

items that must be synchronized. The client passes a list of folders for which it wants
an estimate. This estimate facilitates the progress bar display on the device.
• Sync This command is used to initiate a sync. The Sync command also has
other commands embedded in it (such as Add and Change).
506
ActiveSync protocol version 2.0 adds support for two additional commands: Folder sync and
AUTD (Always Up-To-Date):
• Folder Sync This command is used instead of the GetHierarchy command. The
FolderSync command synchronizes the collection hierarchy just like individual folders
are synchronized.
• AUTD This command enables the user to automatically synchronize the mobile
device with the server as new items are received on the server. For more information,
see the section "Up-to-Date Notifications" later in this topic.
Sync Command Format

Protocol commands are sent using the HTTP POST mechanism. Some simple commands
are contained in the client request Unified Resource Identifier (URI), and more complex
commands use the HTTP body to convey further information about the command.
A sync session is often made up multiple commands. In this case, the session will consist of
multiple pairs of command requests and responses sent back and forth between the client
and server.
There are three parts to a request:
• URI This part includes the server address and several parameters, including the
command name.
• HTTP Header This part includes additional parameters that are used by the
server and are transmitted in standard HTTP format.
• HTTP Body This part includes data required by the command. The format
varies by command, and some commands have no body.
URI
The following example shows a typical sync request URI:
POST /Microsoft-Server-ActiveSync?User=johndoe&
DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=Sync
The parameters such as Cmd, User, and DeviceId are sent by the client with each request. The
most important parameter is the Cmd parameter. The Cmd parameter indicates to the server
what operation it must perform. In this example, the Sync argument passed in the Cmd
parameter indicates to the server that a sync operation must be performed. Additional data is
contained in the HTTP POST body.
507
HTTP Header
In addition to the URI, the client also sends some general information in the HTTP header.
The following example shows the entire HTTP POST request header, together with the URI:
POST Microsoft-Server-ActiveSync?User=johndoe&
DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=Sync
Accept-Language: en-us
MS-ASProtocolVersion: 2.0
Content-Type: application/vnd.ms-sync.wbxml
The server responds with some general information in the header. The following entry
contains the HTTP POST response header:
HTTP/1.1 200 OK
Content-Length: 114
Date: Mon, 15 Mar 2004 11:07:44 GMT
Content-Type: application/vnd.ms-sync.wbxml
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Pragma: no-cache
MS-Server-ActiveSync: 2.0.3273.0
HTTP Body
The request body contains data sent to the server. The type and format of the data varies by
command. The most common format is XML, and the details depend on the command.
Commands that send e-mail messages use RFC 822 format, instead of XML. Some
commands do not require extra data. In that case, the body is empty.
The response body contains data returned from the server. As with the request body, the
format varies by command. Typically, it is in WbXML format. When the body contains an e-
mail attachment, the format depends on the type of the attachment file. Some commands do
not use the body.
Protocol-Independent Multicast Data on the

Mobile Device
Protocol-independent multicast data is stored in "collections," one for contacts, one for
calendar, and one for each e-mail folder. The sync protocol supports syncing multiple e-mail
folders. For each collection, the client software stores a SyncKey. The SyncKey contains 39
to 48 characters, 38 for the globally unique identifier (GUID), and one to ten for the
incrementing number. The client also stores a CollectionId. The CollectionId is a string of
around 40 characters for each folder that is a unique identifier for the folder.
508
The client sends the SyncKey to the server with each synchronization request. Each object
that is synchronized—whether a message, contact, or calendar item—has a unique identifier
assigned by the server. This ServerId is a 48-character string that is stored by the client. The
identifier is used during synchronization to identify objects that are stored on both the client
and server.
Exchange ActiveSync Profile

The synchronization state is stored in a hidden folder in the user's mailbox on the Exchange
server. The synchronization state for e-mail, calendar, and contacts, and FolderSync is
located in the Microsoft-Server-ActiveSync/PocketPC/DeviceId folder in the
NON_IPM_SUBTREE of a user's mailbox. The Search folder containing the folder hierarchy
is also stored here.
Up-to-Date Notification
Exchange ActiveSync is configured on the device to synchronize with the server at intervals,
as frequently as every five minutes. However, ActiveSync does not provide up-to-date
information about the device. The user can also incur additional charges because of the
frequent sync sessions.
Up-to-Date Notification is a new feature in Exchange Server 2003 that enables the user to
automatically synchronize a pocket PC 2003 or a Microsoft Windows Mobile 2003 device with
the server when new items are received on the server. Up-to-date notification is a feature of
Exchange ActiveSync that is installed with Exchange Server 2003.
An event is generated in a user's Exchange account when a new message arrives. This event
causes a Short Message Service (SMS) notification to be sent to the user's device. The
device synchronizes in the background. The user data is updated to the most current
information, with no intervention on the part of the user.
The notification is sent as an SMS control message to the device. It is different from a regular
SMS notification, because it does not appear as an SMS message in the Inbox. The SMS
router and Exchange ActiveSync on the device process the notification. The notification itself
does not carry any sensitive data.
Notifications can be sent from Exchange Server 2003 directly to the SMS address of the
device, or through an aggregator (for example, a corporate service provider) configured by
the Exchange administrator. For notifications to be sent to the SMS address of the device, the
administrator must create an SMTP carrier in Exchange System Manager.
509
Aggregators
Organizations can choose to send notifications to devices through an aggregator. The only
aggregator currently available is MSN Internet Access. To establish an aggregator, the
organization must log on to a secure Web site using a Passport account and select the
carriers it wants to use through MSN. The organization can then obtain credentials from MSN
for secure notification delivery.
Next, the MSN carrier must be created in Active Directory. A separate file,
MSNCarrierConfigurator.zip is provided. The zip file contains CreateMSNCarrier.cmd and
CarrierConfig.LDF, which are used to set up the MSN carrier.
After the MSN carrier is created in Active Directory, the administrator creates an SMTP
connector for secure notification delivery to MSN, using the credentials received when a user
signs up. When an administrator configures an SMTP carrier to send notifications directly to
the SMS address of the device, the notification goes through the SMTP gateway at the
mobile operator and then to the operator's SMS Center (SMS-C). Operator SMTP gateways
are frequently associated with high message latencies and SMS delivery times are
sometimes greater than an hour. This negates the advantages of up-to-date notifications and
does not provide an up-to-date experience for the user.
There are also security issues with forwarding messages through an SMTP gateway
operator. You can use an aggregator to connect through Transport Layer Security to Microsoft
Mobile Services. This enables an enterprise to connect to one or more of the operators with
which Microsoft Mobile Services has created up-to-date partnerships.
Outlook Mobile Access and Exchange 2003

Microsoft Exchange Server 2003 provides a mobile browse solution, named Outlook Mobile
Access. Outlook Mobile Access generates HTML, xHTML, and cHTML markup for display on
mobile devices on the approved device list. Wireless Markup Language (WML) is also
generated, but Microsoft has not tested WML for all device and gateway configurations.
Therefore, WML is not supported. However, most devices work with Outlook Mobile Access.
Outlook Mobile Access is installed by default but disabled globally (although all users are
enabled for mobile access). The user experience is similar to Microsoft Outlook Web Access.
Connection with Outlook Mobile Access is through a URL, typically, http://server-name/oma.
Unlike Microsoft Outlook Web Access, however, you cannot specify a specific user account in
the URL. This is because Outlook Mobile Access adds a unique identifier to the URL as part
of session state management.
Outlook Mobile Access supports the following messaging and collaboration features:
• E-mail Read, Reply, Forward, Delete, Flag, Compose messages, navigate

multiple folders, and look up sender or other recipients.
510
• Calendar Accept, Decline, Tentative meeting requests, navigate through date

picker control, and compose and edit appointments with attendees support.
• Contacts View, Create, Edit personal contacts, search personal and global
address list (GAL) contacts, save GAL contacts to personal contacts, and e-mail and
call contacts.
• Tasks View, Create, and Edit tasks.
Outlook Mobile Access Dependencies

Outlook Mobile Access has several dependencies, including .NET Framework, IIS, Session
State management, and a modified URL Session ID. The Outlook Mobile Access program is
built on the .NET framework. By default, Windows Server 2003 installs the .NET framework,
whereas Windows 2000 Server requires the addition of the framework. This is handled by
Exchange setup if the framework is not installed. Outlook Mobile Access also requires Basic
as the Authentication method, OMA.ASPX as the default document, and the Outlook Mobile
Access virtual directory executable path configured as
aspx,C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll,1,GET,HEAD,POST,DEB
UG.
Outlook Mobile Access and .NET

Outlook Mobile Access is the only Exchange 2003 component that uses the .NET
Framework. It is impossible to understand the foundation of Outlook Mobile Access without a
cursory understanding of the .NET Framework. Outlook Mobile Access enables you to view
your mailbox with a mobile browser. This section provides a basic explanation of the .NET
Framework and ASP.NET, as they apply to Exchange 2003 Outlook Mobile Access and to
mobility as a whole.
.NET Framework
.NET Framework has two main components: the common language runtime and the .NET
Framework class library. The common language runtime is the foundation of .NET
Framework. The runtime is an agent that manages code at run time. It provides core
services, such as memory management and thread management, while it enforces strict type
safety and other forms of code accuracy that assist with security and robustness issues. In
fact, the concept of code management is a fundamental principle of the runtime. Code that
targets the runtime is named managed code, while code that does not target the runtime is
named unmanaged code.
The class library is a comprehensive, object-oriented collection of reusable types that are
used to develop applications ranging from conventional command-line or graphical user
511
interface (GUI) applications to applications based on the latest innovations provided by

ASP.NET Web Forms and XML Web services.
ASP.NET
ASP.NET enables developers to use the .NET Framework to target Web-based applications.
ASP.NET is more than a runtime host. ASP.NET is a complete architecture for developing
Web sites and Internet-distributed objects using managed code. Both Web Forms and XML
Web services use IIS and ASP.NET as the publishing mechanism for applications. Both have
a collection of supporting classes in the .NET Framework.
The .NET Framework also provides a collection of classes and tools to assist in development
of mobile controls. Mobile controls are used to develop applications for handheld devices and
are device-specific. Mobile controls reduce development time and make sure that the correct
markup is returned to the client device.
ASP.NET Framework 1.1 provides an abstraction of a user interface with objects representing
the fundamental components of a visual display, such as text labels and input boxes. It is the
runtime's task to convert this abstract representation to device-specific markup.
ASP.NET provides mobile Web Form controls that represent individual components of the
user interface. These components are used to define a user interface in a Web page.
ASP.NET delivers the content in the markup language appropriate to the requesting device.
There are two major client protocols that are used by browsers to date: cHTML and xHTML.
ASP.NET automatically renders the correct elements for the specified wireless device.
Session Management
As mentioned at the beginning of this section, Outlook Mobile Access requires Session State
management to operate correctly. The HTTP protocol is effectively stateless, as it provides no
mechanism for identifying or maintaining sessions between a Web server and a client. This
problem is addressed in ASP by providing a Session object that enables you to uniquely
identify a user and store information specific to his or her interactions with a Web server.
ASP.NET offers an updated and improved version of the Session object. This object enables
you to perform the following tasks:
• Identify a user through a unique session ID
• Store information specific to a user's session
• Manage a session lifetime through event handler methods
• Release session data after a specified timeout
Outlook Mobile Access uses ASP.NET default, in-process session state handling, and the
modified URL method of session management.
512
Modified URL Session ID

A modified URL is a URL that contains a session ID. The session ID takes the form of the
standard URL with a unique identifier added between the application and the Web page (such
as http://server/oma/(a5db038hclb4b1g5ukhrsu55)/oma.aspx). When the Web server
receives the request, it parses the session ID from the modified URL. The runtime then uses
the session ID just as it would use a session ID obtained from a cookie. If the client does not
support cookies, runtime does not automatically use modified URLs.
Note:
There is a potential problem with mobile devices that do not support modified URLs
for session ID. Some wireless browsers experience difficulties dealing with relative
URLs after they have been redirected to a modified URL. The problem occurs
because they support URL lengths much shorter than those supported by desktop
browsers. An application in a deeply nested hierarchy might require URLs with
lengths that exceed what is supported by some browsers.
ASP.NET Device Updates

Mobile device updates are incorporated into the .NET Framework Device Updates. After all,
Outlook Mobile Access derives from these base classes. The Device Updates (DUs) are
tentatively scheduled for quarterly updates. Any modifications required to provide proper
rendering on a specific device are included in the web.config in the root of the browse
directory. The web.config is updated as part of the device updates. Any customization will be
overwritten.
Administrators and developers are discouraged from modifying web.config settings for a
device Microsoft has not tested. In many cases, there will be no interoperability problems
between the mobile device and Exchange. However, there is no support for such
modifications, and the end result may remove the ability to debug Outlook Mobile Access.
Outlook Mobile Access Architecture

For data access and processing, CDOEX, DAV, Microsoft Outlook Web Access Templates
and system.directory services are used inside the Outlook Mobile Access process.
Active Directory, the registry, the IIS metabase, and the web.config file are read to obtain
configuration settings.
Outlook Mobile Access must receive the user credentials in clear text through Basic
authentication. Outlook Mobile Access does not support or work with Windows Integrated
Authentication even if the device/browser supports it.
513
ASP.NET works in conjunction with IIS, the .NET Framework, and the underlying security
services provided by the operating system, to provide a range of authentication and
authorization mechanisms.
Outlook Mobile Access and Microsoft Outlook

Web Access Templates
Web Distributed Authoring and Versioning (WebDAV) provides raw access to most data
hosted on Exchange. Some common tasks, such as accepting a meeting request, creating a
meeting request, and resolving an ambiguous e-mail recipient, are difficult to implement using
WebDAV. Generally, Microsoft Outlook Web Access responds to a user request with an HTML
page. The runtime does not automatically use modified URLs if the client does not support
cookies.
The format of the response page is determined by templates. Outlook Mobile Access
leverages Microsoft Outlook Web Access functionality. Outlook Mobile Access uses custom
templates to control the information and the format of the information returned from the
Microsoft Outlook Web Access functions. These templates return data in a format that is
similar to a WebDAV response. This provides unification of the data format returned by
functions using Microsoft Outlook Web Access for data retrieval and those using WebDAV.
WebDAV is the foundation for most operations in the Outlook Mobile Access Exchange Data
Provider. The WebDAV protocol, designed for general data access, extends HTTP to
HTTP 1.1. This enables data storage on the server and retrieval by the HTTP client. The
fundamental operations are:
• Navigate folder
• Enumerate folder items
• Search folder for items
• Get item details
• Modify attributes of message, contact, and task
• Submit composed message
The Exchange Data Provider classes provide the interface with Exchange Server for those
functions not obtained from Microsoft Outlook Web Access.
Outlook Mobile Access Data Sources

Outlook Mobile Access retrieves configuration and other data from a variety of sources,
including Active Directory, the IIS metabase, the Windows registry and Web.config. Retrieving
data for a user through WebDAV and Microsoft Outlook Web Access templates requires
Outlook Mobile Access to construct the WebDAV/OWA URL as follows:
514
http://<servername>/<virtualdirectoryname>/<mailbox>. In this case, the value for

<servername> is retrieved from the User object of the user who is logged on. In cross forest
topologies, this information is read from the disabled user account in the resource forest. The
<virutaldirectoryname> is retrieved from the ExchangeVDir registry.
Determining the correct <mailbox> is more complex. The only way to determine a user
mailbox name is to find the user's SMTP address for the mailbox. You can find this value from
the User object. However, there is a problem with this method. The attribute might contain
more than one SMTP address for the user.
The correct SMTP address is determined by the SMTP Domain of the mailbox in question.
The SMTP Domain is configured through Exchange System Manager per virtual directory for
Microsoft Outlook Web Access, Outlook Mobile Access and Exchange ActiveSync. This
facilitates hosting as the same front-end server can have multiple Outlook Mobile Access
virtual directories and each virtual directory represents a unique SMTP Domain. This setting
is stored in the directory with one SMTP Domain per virtual directory per Exchange server.
Outlook Mobile Access, in addition to Exchange ActiveSync and Microsoft Outlook Web
Access, do not have read access to this attribute. Access rights are restrictive because it is
an administrator setting. The DS2MB process does have read access. The mailbox resolution
process is as follows:
1. Exchange System Manager writes an SMTP Domain value to Active Directory for
a certain virtual directory on a certain server.
2. DS2MB on that server picks the setting up and replicates it to the IIS metabase
on the computer.
3. Outlook Mobile Access reads the SMTP Domain for the virtual directory in which
they are running.
4. Outlook Mobile Access looks up the SMTP addresses on the Active Directory
User object (in cross-forest topologies, this information is read from the disabled user
account in the Exchange resource forest).
5. Outlook Mobile Access picks out the SMTP address using the SMTP Domain in
the list.
6. The SMTP address is on the format <mailboxname>@<SMTP Domain>, Outlook

Mobile Access extracts the <mailboxname>.
The <servername>, <virtualDirectoryName>, and <mailbox> values are then linked together
to provide the DAV/OWA URL that the back-end server requires.
Outlook Mobile Access Directory Settings

Outlook Mobile Access reads configuration settings from Active Directory whenever a new
session is created (and only when a new session is created). The following two tables
515
describe the forest-wide and user-specific Outlook Mobile Access configuration settings in
Active Directory.
Forest-wide Outlook Mobile Access directory settings
Directory Setting Description
Outlook Mobile Access Outlook Mobile Access root node under

Exchange Active Directory settings.
Contains Outlook Mobile Access-global
attributes and containers for more Outlook
Mobile Access settings.
msExchOmaAdminWirelessEnable Admin control for available mobile services:

Bit 0:OMA Push
Bit 1:OMA Browse
Bit 2:OMA Sync
Bit 30: Browse-with-untested-devices
Bit 31: Push-via-user-specified-SMTP-

address
0 = Enabled. 1 = Disabled.
The default value set by the Exchange

Setup program is disabled.
msExchOmaExtendedProperties Reserved for future feature-expansion

(without requiring Active Directory schema
changes).
Per-user Outlook Mobile Access directory settings
Directory Setting Description
msExchOmaAdminExtendedSettings Space for admin controlled settings for a

user. Example: Allow/disallow access to
features such as calendar or contacts in
Outlook Mobile Access.
msExchOmaExtendedProperties Reserved for future feature-expansion

(without requiring Active Directory schema
changes).
The attributes on the User object inherit three access control lists (ACLs) from the User object
container: Domain Admins, Local System on Domain Controllers, and Account Operators.
516
Each of these security principals have full read/write permissions to the user's settings.
Additionally, the two attributes listed in Table 9.8 are part of the Public-Information property
set, which gives Authenticated Users read access. The attributes in the Outlook Mobile
Access Configuration Container are inherited from the Organization Node, and then read
access for Authenticated Users is added.
Because these directory settings are only read at the beginning of a new session, changing
the settings does not affect sessions in progress. For example, disabling a user for Outlook
Mobile Access does not immediately block that user from an ongoing session. A user won't
notice that access is disabled until the next time that user tries to establish a new Outlook
Mobile Access session.
Outlook Mobile Access and DS2MB

DS2MB in Exchange 2003 affects all Exchange Web-based applications. These include
Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. Outlook Mobile
Access has some configuration values that depend on the directory, but deleting the Outlook
Mobile Access virtual directory is a common method of troubleshooting directory to metabase
replication.
IIS obtains the correct configuration from the local metabase. IIS related information is stored
in Active Directory and replicated in one direction from the directory to the metabase by the
DS2MB process. DS2MB runs as part of System Attendant on each computer running
Exchange 2000 or later. DS2MB receives notifications of changes in the directory and directs
DS2MB to do the work.
If you discover that the local metabase is not synchronized with the directory, you can force a
manual update of the directory by manipulating the metabase key below.
LM\DS2MB\HighWaterMarks\{056BE186-E73F-4EBD-A92D-2D985BC97C63}\61472
Changing the data for this value to 0 (zero) or deleting the key and then restarting System
Attendant causes a full replication of the directory information to the metabase. When System
Attendant starts, the key is added to the metabase with the default value. The metabase can
be manipulated through a variety of tools. If Exchange 2003 is running on Windows
Server 2003, the built-in IISCNFG tool can be used. If Exchange is running on
Windows 2000, MetaEdit 2.2 or later can be used.
Outlook Mobile Access and the Windows

Registry
Outlook Mobile Access uses five registry keys. One is used for performance counters, and
four others are used for configuration. One key is shared with Exchange ActiveSync, and
three others are shared with Outlook Web Access. These keys can be found under
517
HKLM\SYSTEM\CurrentControlSet\Services. The registry keys are described in the following

table.
Important Outlook Mobile Access registry values
Key Value Description
MasSync\Parameters\Excha /Exchange or other string Specifies what virtual

ngeVDir that starts with / directory ActiveSync and
Outlook Mobile Access must
use to access Outlook Web
Access templates and
WebDAV on the Exchange
back-end servers where
user mailboxes are located.
If this key does not exist, or
is null, the default value
/Exchange is used.
Otherwise, this key contains
the name of the virtual
directory, including the
forward slash (/).
MSExchangeWEB\OWA\Us 1 or anything If this key is set to '1', then

eRegionalCharset Outlook Web Access and
Outlook Mobile Access use
regional charsets when
sending e-mail. If it doesn't
exist or is set to anything
else, Outlook Web Access
and Outlook Mobile Access
use UTF-8 for sending e-
mail. The regional charset
used is determined based
on the client language the
user specifies.
MSExchangeWEB\OWA\Us 1 or anything When set to '1', the

eISO8859_15 character set iso-8859-15 is
used wherever the iso-8859-
1 would have been used.
MSExchangeWEB\OWA\Us 1 or anything When set to '1', the

eGB18030 character set GB18030 is
used wherever the GB2312
would have been used.
518
Key Value Description
MSExchangeOMA\Performa N/A Used to publish Outlook

nce Mobile Access performance
objects and counters.
Outlook Mobile Access and Web.Config

Under the <browserCaps> section of the Web.config file are Outlook Mobile Access settings
for various mobile browsers and versions of Internet Explorer. Do not adjust these settings, as
they are included in .NET Framework Device Updates.
There are some user configurable settings in web.config file, which are described in the
following table.
Web.config settings for Outlook Mobile Access
Section Setting Description
<appSettings> <add Defines the number of

key="CredentialsTimeout" minutes Outlook Mobile
value="60"></add> Access keeps Kerberos
tickets for DAV and Outlook
Web Access template
access cached.
<add Defines the maximum

key="DefaultConnectionLimi number of simultaneous
t" value="500"></add> connections Outlook Mobile
Access can open to an
individual back-end server.
<add Tells Outlook Mobile Access

key="MaxServicePointIdleTi how many milliseconds to
me" value="60000"></add> wait for replies from the
back-end server before
timing out.
<add When this message is

key="UnsupportedMessage defined, additional text
" shows up on the
value="http://<server>/OMA unsupported warning and
Devices"></add> unsupported error pages. By
default this key is null.
519
<system.web> <sessionState Specifies the session state

mode="InProc" configuration that is used by
cookieless="true" Outlook Mobile Access.
timeout="20" />
The timeout value indicated
for how many minutes the
session state is kept in
memory after the last
request arrives for the
session.
<mobileControls Specifies how many

SessionStateHistorySize="8 previous pages the session
"> state must track (enabling
the user to set the device
back button and still have
the links on pages work).
<globalization Defines the default

requestEncoding="utf-8" characters set Outlook
responseEncoding="utf-8" Mobile Access uses to send
/> HTTP responses and
interpret incoming requests
without a character set
specified.
<browserCAPs> supportsBackNavWithExpir Determines whether Outlook

esHeader Mobile Access sends the
Expires header back on all
requests with a value of
10/08/2000 10:28. The
purpose of sending back a
date and time in the past is
to force expiration of
content.
preferredResponseCharset Sets Response.Charset to

this value for all requests.
preferredResponseCodePa Sets
ge Response.ContentEncoding
to the specified integer. Set
at the same time as
Response.Charset.
520
preferredRequestCodePage Sets
Request.ContentEncoding
to the specified integer.
Should be set at the same
time as Response.Charset.
supportsOpenwaveUniversa Tells Outlook Mobile Access

lLocalSrc to insert access keys before
links.
defaultTextboxMaxlength Sets the MaxLength of

strings permitted in TextBox
controls. The P800, for
example, will default to 64
without this set.
Outlook Mobile Access Client Requests

When an Outlook Mobile Access client issues a Web request, the following sequence of
authentication and authorization events occurs:
1. The HTTP(S) Web request is received from the network. SSL can be used to
verify the server identity. SSL also provides a security channel to help protect
sensitive data passed between client and server.
2. IIS authenticates the caller by using Basic authentication. IIS creates a Windows
access token for the authenticated user.
3. IIS authorizes the caller to access the requested resource. NTFS file system
permissions defined by access control lists (ACLs) attached to the requested
resource are used to authorize access.
4. IIS passes the authenticated caller's Windows Server access token to ASP.NET.
Outlook Mobile Access Security Architecture

The underlying security architecture of Outlook Mobile Access depends on whether
Exchange 2003 is running on Windows Server 2003 or Windows 2000 Server. On Windows
Server 2003, Outlook Mobile Access runs in its own process in a dedicated program pool,
ExchangeMobileBrowseApplicationPool. Outlook Mobile Access runs as the Network Service
account in an ASP.NET worker process (W3WP.EXE). On a Windows 2000-based computer,
Outlook Mobile Access runs in a process together with other ASP.Net applications on the
same computer. Outlook Mobile Access runs as the ASPNET account in an ASP.NET worker
process (ASPNET_WP.EXE).
521
The ASP.NET ISAPI extension, ASPNET_ISAPI.DLL, runs in a process under Inetinfo.exe.

This is controlled by the InProcessIsapiApps Metabase entry. ASPNET_ISAPI.DLL is
responsible for routing requests to the ASP.NET worker process. ASP.NET programs then run
in the ASP.NET worker process, in which program domains provide isolation boundaries.
IIS 6.0 isolates ASP.NET programs by configuring program pools, in which each pool has its
own application instance (Outlook Mobile Access is placed in the
ExchangeMobileBrowseApplication pool).
Exchange Information Store Service

Architecture
The core data storage repository for Microsoft Exchange Server 2003 is the Microsoft
Exchange Information Store service, which contains both mailbox store and public folder
store data. The Microsoft Exchange Information Store service uses a database engine called
Extensible Storage Engine (ESE), a transaction-based database technology.
This section explains the role of the Microsoft Exchange Information Store service in the
Exchange Server 2003 messaging system. The Microsoft Exchange Information Store
service, as its name implies, implements the Exchange store. The Exchange store hosts
mailbox and public folders. The responsibilities of the Exchange store also include public
folder replication, which is covered in a separate section because of its complexity.
• Exchange Storage Architecture Exchange Server 2003 uses a transaction-

based storage architecture that includes a database file, a native content file,
transaction logs, and other files, such as checkpoint files and reserved logs. You
must understand how Exchange Server 2003 uses these files to store messaging
data.
• Extensible Storage Engine Architecture Extensible Storage Engine is at the

core of the Exchange store. You must be familiar with Extensible Storage Engine to
understand the architecture of the Exchange store.
• Responsibilities of the Exchange store In the client/server architecture of

Exchange Server 2003, the Microsoft Exchange Information Store service has
exclusive access to the messaging databases. Exclusive database access entails a
number of responsibilities that you should be familiar with to understand the role of
the Microsoft Exchange Information Store service.
• Public Folder Replication Public folder replication enables you to maintain

multiple instances of the same public folder on different Exchange servers and to
keep these instances synchronized. This feature can be used to provide users in a
distributed Exchange organization with access to a local copy of a public folder.
522
Replicated public folders can also increase fault tolerance for workgroup solutions.
You should know how the Exchange store replicates public folder data across an
Exchange organization.
For information about managing the Exchange store and about backup and disaster recovery,
see the Exchange Server 2003 Administration Guide.
Exchange Storage Architecture

Exchange servers store data in two files: an .edb file and an .stm file. Together, the .edb file
and the .stm file form an Exchange store repository. For example, the default mailbox store
on an Exchange server uses files named Priv1.edb and Priv1.stm. The default public folder
store uses the files Pub1.edb and Pub1.stm. The .edb file contains many tables that hold
metadata for all e-mail messages and other items in the Exchange store, in addition to the
contents of MAPI messages. The .edb file is an ESE database, and because it is used
primarily to store MAPI messages and attachments, it is also referred to as the MAPI-based
database. The .stm file, in contrast, stores native Internet content. Because Internet content is
written in native format, there is no need to convert messages and other items to Exchange
format (as in Exchange 5.5 and earlier). The .stm file is also an ESE database, referred to as
the streaming database. The .edb and .stm files function as a pair, and the database
signature (a 32-bit random number combined with the time that the database was created) is
stored as a header in both files. The internal schema for the .stm pages is stored in the .edb
file.
Note:
You can rename the .edb and .stm databases and move them to different directories
in Exchange System Manager. Because the .edb and .stm files together create a
complete Exchange store repository, you should keep them together and assign them
a common name with different extensions (that is, .edb and .stm).
Exchange Server 2003 uses transactions to control changes in storage groups. These
transactions are recorded in a transaction log, similar to the way transactions are stored in
traditional databases. Changes are committed or rolled back based on the success of the
transaction. If there is a failure, you use transaction logs (together with the database files and,
in some cases, the checkpoint file) to restore a database. The facility that manages
transactions is the Microsoft Exchange Information Store service (Store.exe). Any
uncommitted transaction log entries are also considered part of a current Exchange
database, as illustrated in the following figure.
523
Current Exchange Server 2003 database
The following two types of databases are available in Exchange Server 2003:
• Private store databases These databases store mailboxes and message

queues for MAPI-based messaging connectors.
• Public store databases These databases store public folder hierarchies and
public folder contents.
The following figure illustrates the internal Exchange store architecture. The Microsoft
Exchange Information Store service (Store.exe) uses Extensible Storage Engine (ESE) to
access the database files in the file system, and provides access to the data through various
interfaces, such as MAPIsvr, ExPOP, ExIMAP, ExSMTP, and ExOLEDB. Client application
and application programming interfaces, such as Collaboration Data Objects for Exchange
(CDOEX), can use these interfaces or communicate with the messaging database (MDB)
module.
Exchange store architecture
Storage Groups
Each storage group is made up of a set of log files and auxiliary files (internal temporary
databases, the checkpoint file, and reserve logs) for all the databases (.edb files, .stm files) in
the storage group. Exchange Server 2003 supports multiple storage groups and multiple
databases in each storage group. In Exchange Server 2003, a single server supports up to
four storage groups and a single storage group supports up to five databases. Support for
multiple databases enables you to distribute numerous mailboxes and public folders across
524
numerous, smaller databases, thus making database management easier. Exchange 2000
Server and Exchange Server 2003 can support up to 20 mailbox and public folder databases
on a single server.
Storage Group Architecture

As illustrated in the following figure, all storage groups are hosted from the same Store.exe
process. Each storage group is represented by an ESE instance.
Storage group architecture
Within each storage group, each .edb and .stm database pair represents a mailbox store or a
public folder store. As shown in Figure 10.3, all mailbox and public folder stores in a particular
storage group share a common set of log files and other system files. These files enable
transaction-oriented processing.
The log files and other system files in each storage group have the following purposes:
• <Log Prefix>xxx.chk This is the checkpoint file (for example, E00.chk) that
determines which transactions require processing to move them from the transaction
log files to the databases. Checkpoint files are updated when ESE writes a particular
transaction to a database file on a disk. This update always points the checkpoint file
to the last transaction that was transferred successfully to the database. This update
provides a fast recovery mechanism. However, checkpoint files are not required to
commit transactions to databases. ESE has the ability to process transaction log files
directly and to determine for itself which transactions have not yet been transferred.
This process takes significantly more time than using checkpoints.
Note:
Extensible Storage Engine guarantees that transactions are not written to a
database multiple times.
525
• Exx.log This is the current transaction log file for the storage group. Transaction
log files give ESE the ability to manage data storage with high speed efficiency. ESE
stores new transactions, such as the delivery of a message, in a memory cache and
in the transaction log concurrently. The data is written sequentially. New data is
appended to existing data without the need for complex database operations. At a
later time, the transactions are transferred in a group from the memory cache to the
actual databases, which update them.
By default, the default storage group, named First Storage Group, uses the prefix E00,
which results in a transaction log file name of E00.log. The E00.log is used for all mailbox
and public stores in this storage group. If you create additional storage groups, the prefix
number is incremented to E01, E02, and E03.
• <Log Prefix>XXXXX.log These are transaction log files that have no room
remaining for further data. By default, transaction log files are always exactly
5.242.880 bytes (five megabytes) in size. It is theoretically possible to change the log
file size, but this is not recommended. When a log is full, it is renamed to allow the
creation of a new, empty transaction log file. Renamed transaction log files are
named previous log files. The naming format of previous log files is <Log
Prefix>XXXXX.log (such as E00XXXXX.log), where XXXXX represents a five-digit
hexadecimal number from 00000 to FFFFF. Previous log files reside in the same
directories as the current transaction log file.
• Res1.log and Res2.log These are reserved transaction log files for the storage
group. Reserved log files are an emergency repository for transactions. They provide
enough disk space to write a transaction from memory to the hard disk, even if a
server's disk is too full to admit new transactions to a log file. The reserved log files
can be found in the transaction log directory. They are created automatically when
the databases are initialized. They cannot be created later.
ESE uses reserved transaction log files only to complete a current transaction process. It
then sends an error notification to Store.exe to dismount the Exchange store safely. In the
application event log, there is an entry that indicates the issue. In this situation, you
should create additional free hard disk space (for example, add a new hard disk) before
you mount the database again.
• Tmp.edb This is a temporary workspace for processing transactions. Tmp.edb

contains temporary information that is deleted when all stores in the storage group
are dismounted or the Exchange Information Store service is stopped.
Note:
Tmp.edb is not included in online backups.
• <file name>.edb These are the rich-text database files for individual private or
public stores. The rich-text database file for the default private store is named
Priv1.edb. The file for the default public store is named Pub1.edb.
526
• <file name>.stm These are the streaming Internet content files for individual
databases. The streaming database file for the default private store is named
Priv1.stm. The file for the default public store is named Pub1.stm.
Storage Group Attributes in Active Directory

You can determine the path to a storage group's transaction log file and the log file's name in
Exchange System Manager. Right-click the desired storage group, select Properties, and
from the General tab, look at the information in the Transaction Log Location and the Log
File Prefix fields. Using the Browse buttons, you can move the transaction log and system
files to a new location, such as a separate physical drive.
The configuration settings for a storage group are stored in Active Directory. If you want to
use ADSI Edit to locate the directory object for a storage group, you must open the
configuration naming contacts, expand the services node, then CN=Microsoft Exchange, and
then expand the Exchange organization object, administrative group, and server container.
Underneath it, you can find a container named CN=InformationStore, which contains the
storage groups, such as CN=First Storage Group. The object class for storage group objects
is msExchStorageGroup. If you plan to use custom scripts to manage Exchange store
resources, you can access msExchStorageGroup objects by using Active Directory Service
Interfaces (ADSI).
The following code example demonstrates how to access the default storage group on a
server called SERVER01 in an Exchange organization called Contoso. It displays the current
path to the transaction log files of that storage group.
strStorageGroupDN = "CN=First Storage Group," _
& "CN=InformationStore," _
& "CN=SERVER01,CN=Servers," _
& "CN=First Administrative Group," _
& "CN=Administrative Groups," _
& "CN=Contoso,CN=Microsoft Exchange," _
& "CN=Services,CN=Configuration," _
& "DC=Contoso,DC=com"
Set oStorageGroup = GetObject("LDAP://" & strStorageGroupDN)
MsgBox oStorageGroup.Get("msExchESEParamLogFilePath")
The following are important Exchange attributes of msExchStorageGroup objects that you
can use in custom scripts based on ADSI:
• msExchESEParamCircularLog This is a Boolean flag that determines whether

circular logging is enabled or disabled. A value of 0 indicates that circular logging is
disabled; a value of 1 indicates that circular logging is enabled.
Circular logging causes ESE to discard transactions when the committed changes are
transmitted to the database file on disk. The checkpoint file indicates which log files and
transaction entries are successfully committed to the database. Any existing previous
logs are deleted, while transactions in the current transaction log file are marked as
527
obsolete. New transactions eventually overwrite the obsolete entries in the current
transaction log before a new log file is created.
Note:
Through purging of transactions, circular logging reduces consumption of disk
space. However, circular logging is not compatible with sophisticated fault-
tolerant configurations and several online backup types that rely on the existence
of transaction logs. When circular logging is enabled, you can only perform full
backups. You cannot perform backups that rely on transaction log files, such as
differential or incremental backups. When you recover data, you cannot replay
transaction log files, thus you cannot restore data beyond the most recent
backup. In contrast, if transactions are not automatically deleted through circular
logging, you might be able to recover beyond the most recent backup by
replaying transactions that still exist on a hard disk. Although circular logging is
enabled by default in Exchange Server 5.5, it is disabled by default in
Exchange 2000 Server and Exchange Server 2003.
• msExchESEParamEventSource This is a language-independent process

descriptor string that points to the Microsoft Exchange Information Store service key
(MsExchangeIS) in the registry under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
• msExchESEParamLogFilePath This attribute determines the path to a storage

group's transaction log files, such as C:\Program Files\Exchsrvr\mdbdata.
• msExchESEParamLogFileSize This attribute specifies the log file size in

kilobytes (KB). The default value is 5120.This value should never be changed.
• msExchESEParamSystemPath This attribute specifies the path to the check

point file, such as C:\Program Files\Exchsrvr\mdbdata, in addition to the path to any
temporary databases that might be present.
• msExchESEParamZeroDatabaseDuringBackup This is a Boolean flag that

determines whether deleted records and long values are overwritten with zeros
during backup operations. A value of 0 indicates that records are not overwritten. A
value of 1 indicates that databases are overwritten with zeros.
• msExchESEParamEnableOnlineDefrag This is a Boolean flag that

determines whether the Microsoft Exchange Information Store service should
perform online defragmentation of databases. A value of 0 indicates no online
defragmentation should be performed. A value of 1 indicates online defragmentation
should be performed during scheduled maintenance cycles.
Note:
Online defragmentation frees space in the databases but does not reduce the
size of the database files. Database inconsistencies are corrected during every
start and shutdown of the server in a process referred to as soft recovery.
528
• msExchESEParamEnableIndexChecking This is a Boolean flag that

determines whether the operating system version is checked for Unicode indexes. A
value of 0 indicates that index checking is not performed. A value of 1 indicates that
index checking is performed. This parameter detects changes in the operating
system that result from upgrading to a newer version or from applying a service pack.
This flag determines whether the sort order for Unicode has changed. Whenever the
operating system is changed in this manner, re-indexing occurs automatically.
• msExchESEParamBaseName This attribute specifies the base name for the

log files in this storage group. For example, a base name of E00 results in a
transaction log file name of E00.log.
• msExchESEParamDbExtensionSize This attribute specifies the database

extension size, in pages. The default value is 2 megabytes (MB).
• msExchESEParamPageTempDBMin This attribute specifies the minimum size

of the temporary database, in pages. The default value is 0.
• msExchESEParamCheckpointDepthMax This attribute specifies the preferred

(not hard) maximum checkpoint depth, in bytes.
Storage Group Minimum Disk Space

Requirements
Each storage group consumes about 50 MB of free disk space. The files listed above that are
required by the storage group use a minimum of 11 MB of disk space. The minimum disk
space for private and public stores is 5 MB and 8 MB, respectively. Although the total disk
space used is about 24 MB, extra disk space is also needed for the actual creation of the
storage group and for read and write operations.
When working with storage groups, remember the following:
• A server running Exchange Server 2003 can have up to five storage groups.
Because one of the storage groups is reserved for database recovery operations,
only four storage groups can be used to hold databases that are accessible by
clients. Attempts to create more than four storage groups result in an error message.
• You can create only five databases in a storage group. Attempts to create more
databases result in an error message.
Exchange Store Databases

Exchange Server uses ESE as an embedded database engine that determines the structure
of the databases and manages memory. The database engine caches the databases in
memory by transferring four-kilobyte chunks of data (pages) in and out of memory. It updates
the pages in memory and writes new or updated pages back to the disk. When requests
529
come to the system, the database engine can buffer data in memory, so that it does not have
to access the disk constantly. This makes the system more efficient, because writing to
memory is approximately 200,000 times faster than writing to disk. When users make
requests, the database engine starts loading the requests to memory and marks the pages as
dirty. A dirty page is a page in memory that contains data. These dirty pages are later written
to the Microsoft Exchange Information Store service databases on disk.
Although caching data in memory is the fastest and most efficient way to process data, it
means that while Exchange is running, the information on disk is never completely up-to-date.
The latest version of the database is in memory, and because many changes in memory are
not on disk yet, the database and memory are not synchronized. If there are any dirty pages
in memory that have not been transferred and written to disk, the databases are flagged as
inconsistent. Exchange databases are synchronized only when all dirty pages in memory are
transferred to disk. This happens when you properly shut down the Microsoft Exchange
Information Store service. During the shutdown process, the Microsoft Exchange Information
Store service flushes all pages to disk.
MAPI Database File

The Exchange Server 2003 MAPI database file contains the tables that hold the metadata for
all e-mail messages, other objects in the database, and the contents of MAPI messages.
Every folder displayed in Microsoft Office Outlook is a separate database table in the
Exchange store. Every sort order used to view these folders is represented by a separate
index on that table. The Store.exe process manages these sort orders.
Messages from MAPI clients, such as Outlook, are stored in the MAPI database, just as they
were stored in previous versions of Exchange Server. MAPI-based clients can then access
these messages without conversion. However, if an Internet protocol-based client attempts to
read a message in this database, the message is converted to the requested format.
The traditional .edb file and its accompanying .stm file are a single unit. One of these files is
of little use without the other file. It is important to understand that a single database in the
Microsoft Exchange Server Information Store service contains two files, the .edb file and the
.stm file.
A record in the .edb file contains a column (of data type JET_coltypSLV) that references a list
of pages in the streaming file that contains the raw data. Space usage (maximum of four
kilobytes of page numbers) and checksum data for the data in the streaming file is stored in
the .edb file.
Streaming Database File

Exchange Server 5.5 and earlier store messages in message database encapsulated format
(MDBEF). This is the native format for Outlook clients. When a non-MAPI client requests a
message, the Microsoft Exchange Information Store service converts the contents from
530
MDBEF to the appropriate format, based on what the client requests. This conversion
consumes processor bandwidth and slows server performance.
Later versions of ESE enable Internet messaging clients to store raw data in native format.
The repository for this raw data is referred to as the streaming database, or simply the
streaming file. The streaming file has no balanced tree (B-tree) overhead. Instead, it contains
two four-kilobyte pages of header information and then raw data in four-kilobyte pages. This
flat data structure is designed for binary large objects (BLOBs) of data that are unlikely to
need content conversion and that can be received and transmitted very quickly.
Property Promotion
Property promotion determines where data is stored in an ESE database and is therefore an
important concept to understand. The Microsoft Exchange Information Store service supports
the property promotion of data held in the .stm file to the .edb file. Property promotion enables
folder views and indexes to be maintained efficiently. For example, a message streamed to
the .stm file has its properties, such as sender, subject, and date sent and received, promoted
to the records representing the message in the .edb file.
When a MAPI client, such as Microsoft Outlook, submits a message to the Microsoft
Exchange Information Store service, the contents of that message are stored in the .edb file.
If a non-MAPI client opens the message, the Microsoft Exchange Information Store service
does an immediate conversion of the MAPI content to Internet format by performing some of
the conversion and calling IMAIL, which in turn calls RTFHTML, to complete the conversion.
None of this conversion is persistent, meaning that data is not moved out of the .edb file and
written to the .stm file.
If an Internet client submits a message to the Microsoft Exchange Information Store service,
the contents of that message are stored in the .stm file. Certain headers from the Internet
message are duplicated to the .edb file, so the Microsoft Exchange Information Store service
can find the message. This is referred to as a state 0 conversion.
If any client asks for a property, such as PR_Subject, or one of its many aliases, then the
Microsoft Exchange Information Store service promotes all of the Internet message's header
information to Properties. This is referred to as a state 1 conversion.
If any client asks for attachment information, then the Microsoft Exchange Information Store
service creates a near duplicate (in MAPI form) of the Internet message. At first, the message
is still in the .stm file. However, much of the data needed for MAPI access is in the .edb file. If
a client alters the message in a way that changes the Multipurpose Internet Mail Extensions
(MIME), then the .stm file version of the message is discarded and the .edb file of the
message is preserved. This is referred to as a state 2 conversion.
Regardless of how a message is submitted to the Microsoft Exchange Information Store

service, if Exchange Server receives Internet content that includes Application/ms-tnef
content, the message initially goes to the .stm file, but it is then immediately decoded and
531
moved to the .edb file. The same applies to messages with a winmail.dat attachment,
encoded using UUEncode. Transport neutral encapsulation format (TNEF) and Winmail.dat
are encapsulation methods for MAPI messages to preserve MAPI properties on transports
that do not support MAPI. Therefore, the general principal that MAPI messages reside in the
.edb file and Internet messages reside in the .stm file is correct. The current functionality has
the TNEF decoded before any one of the MAPI properties are read.
Database Size Limit Configuration and

Management
Prior to Microsoft Exchange Server 2003 Service Pack 2 (SP2), there was no method to
configure database size limits for Exchange Server 2003. Exchange Server 2003 SP2
introduces the following new features:
• For the Standard Edition, the default configured database size limit will now be
18 GB, a 2 GB addition to the previous limit, with a new maximum size of 75 GB.
• For the Enterprise Edition, there is no default configured database size limit, and
no software set maximum size.
• Both versions of Exchange Server 2003 with SP2 have the ability to configure a
limit, a warning threshold, and a warning interval set through registry keys.
• Size check done against the database now uses logical database size. Empty or
white space in the database does not count against the configured database size
limit; therefore, no offline defragmenting is required for recovery exceeding the
configured or licensed database limits.
• Limit checks, done at regular intervals, are now controlled by the store process
instead of JET. The default time interval is 24 hours and this interval is configurable
through the registry.
Registry Settings
• The database size limit registry keys are read when the database mounts (not
when the service starts up), and when each limit check task runs.
You must set registry parameters for each database targeted for size limit modification. The
registry entries should be located under each database entry in the local server registry.
Accordingly, you must reset the registry keys manually if the server has to be rebuilt using the
/disasterecovery setup switch.
532
Note:
valuable data.
All registry settings discussed in this topic are created in the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<SERV
ER NAME>\Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00
The GUID in this key (Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00) is an example and

should match the value of the objectGUID attribute on the database’s Active Directory object.
Note:
By default, registry entries mentioned in this article are not present; when you create
the entry, you override the default value set in code.
Note:
All of registry values mentioned in this article are in decimal, not hexadecimal.
• The following new registry settings are available with SP2:
• Database Size Limit in GB
• Database Size Buffer Warning in Percentage
• Database Size Check Start Time in Hours from Midnight
Database Size Limit in GB

The Database Size Limit in GB setting is the configurable maximum size of a database not
to exceed the maximum licensed size of your database. For Standard Edition, you can set the
database size limit between 1 and 75 GB. By default, the limit is 18 GB. For Enterprise
Edition you can set the database size limit between 1 and 8,000 GB. By default, there is no
limit.
The following registry value controls the Configurable Database Size Limit:
Data type Name Value (in GB) Default (in GB)
REG_DWORD Database Size Standard: 1-75 Standard: 18

Limit in GB
Enterprise: 1-8000 Enterprise: 8,000
Unlimited
533
Database Size Buffer Warning in Percentage

The Database Size Buffering Warning in Percentage setting is a configurable error
threshold that will warn you with an event log entry when your database is at or near capacity,
and will shut down within 24 hours of the event being logged. By default, Exchange Server
2003 SP2 logs events when the database has grown to within 10 percent of the configured
database size limit. This threshold is configurable. The smallest buffer is 1 percent of the
configured size limit.
The following registry value controls the Database Size Buffer Warning:
Data type Name Value (in %) Default (in %)
REG_DWORD Database Size 1 - 100 10

Buffer Warning in
Percentage
Database Size Check Start Time in Hours from

Midnight
The Database Size Check Start Time in Hours from Midnight setting allows you to
configure when the system will check your database to see if it is over the currently
configured Database Size Limit. By default, the database size check happens at 05:00 (5:00
A.M.) every day. This time can be changed. If modified, the next task is scheduled at the new
Offset hour. Checks at Database Size Check Interval are skipped until new start time.
First database size check will not take the database offline if the size limit has been
exceeded. Because the database does not go offline, you are ensured at least 24 hour of
availability after the limit is exceeded for default settings.
Data type Name Values Default Description
REG_DWORD Database Size 1 - 24 5 Determines the

Check Start hour the first
Time in Hours database size
from Midnight check will occur
after a database
is mounted.
534
Behavior When the Configured Database Size

Limit or Licensed Database Size Limit Are
Reached
When a database mounts, the store process compares the physical database size against
the Configured Database Size Limit in GB. If the physical size is within or exceeds the
configured Database Size Warning Buffer in Percentage, the store performs a logical
calculation of the database size. If it is below this warning buffer, there is no need to calculate
the free space because the logical size will never exceed the physical size. Generally, the
physical size is less than the warning threshold, so the size check should take under a
millisecond to complete. If the free space calculation must be performed, the size check may
require a few seconds to parse through the database to generate the logical size calculation.
If the Database Size Warning Buffer in Percentage is reached or exceeded, an error event,
event ID 9688, is logged in the Application event log.
With Exchange Server 2003 SP2 or later, the server performs the following tasks when the
configurable (or default configured) database size limit is reached:
• If the first check after a database mount finds the database size above the limit,
the database will not be taken offline but an error event (ID 9689) will be logged in
the Application event log.
• If it is the second check, an error event will be logged in the Application event log
and the database will be taken offline.
After the administrator remounts the database, he or she has 24 hours (or until the next
database size check or 05:00 if the default is set) to take corrective actions.
Licensed Database Size Limit

Exchange Server 2003 Standard Edition is limited to a single storage group with a single
private information store database and a single public folder database. Prior to SP2, each
database was limited to 16 GB of total physical size. SP2 increases the licensed database
size limit for Exchange Server 2003 Standard Edition from 16 GB to 75 GB; the default
configured database size limit will be 18 GB. Exchange Server 2003 Enterprise Edition
storage group and Exchange store options do not change with the application of SP2.
However, a configurable Exchange store size limit is added to the Enterprise Edition.
Exchange Server 2003 Licensed limit Default configuration limit

version
Standard Edition before 16 GB Not applicable

SP2
535
Exchange Server 2003 Licensed limit Default configuration limit

version
Standard Edition with SP2 75 GB 18 GB
Enterprise Edition before 8,000 GB (unlimited) Not applicable

SP2
Enterprise Edition with SP2 8,000 GB (unlimited) 8,000 GB
Note:
The current hard coded limit of the JET database is 8,192 GB, or 8 terabytes (TB).
Disaster Recovery Planning Considerations

If you change the size limit of your Exchange databases, you may want to re-evaluate your
Exchange database backup and restore plan. Specifically, if you increase the size limit of the
Exchange databases, be sure to test your backup and recovery operations using the new
database size limits to make sure that you can still meet your service level agreements. For
example, if the previous size of a mailbox store was 15 GB and you were able to meet your
service level agreement by recovering the data in less than 8 hours, you may no longer be
able to recover the database that quickly if you increase the size of a mailbox store to 20 GB
or larger.
For information about service level agreements, see "Establishing a Service Level
Agreement" in "Setting Availability Goals" in the Exchange 2003 High Availability Guide.
For information about how to configure database size limit options, see "Configure Database
Size Limits" in the Exchange Server 2003 SP2 online Help.
Extensible Storage Engine Architecture

The Exchange store sits on top of an Extensible Storage Engine (ESE) database. ESE is a
multi-user, indexed sequential access method (ISAM) table manager with full data
manipulation language (DML) and data definition language (DDL) capability. ESE allows
applications to store records and create indexes to access those records in different ways.
There are three versions of ESE:
• ESE97 The database engine in Exchange Server 5.5.
• ESENT The database engine for Active Directory and many Microsoft Windows
components. Unlike other versions of ESE (which use five MB log files and four KB
536
page sizes), the Active Directory implementation of ESENT uses ten MB log files and
eight KB pages.
• ESE98 The database engine in Exchange 2000 Server and Exchange

Server 2003.
Note:
ESE was previously referred as Joint Engine Technology (JET) Blue. JET Blue is not
the same as the version of JET found in Access (referred to as JET Red).
Transactions
ESE is a sophisticated, transaction-based database engine. A transaction is a series of
operations that are treated as an atomic (indivisible) unit. All operations in a transaction are
either completed and permanently saved, or no operations are performed. Consider, for
example, the operations involved when moving a message from the Inbox to your Deleted
Items folder. The message is deleted from one folder, added to another folder, and the folder
properties are updated. If a failure occurs, you do not want two copies of the message, no
copies at all, or folder property values (such as item count) that are inconsistent with the
actual folder contents.
To prevent problems such as this, ESE bundles operations inside a transaction. ESE makes
sure that none of the operations are permanently applied until the transaction is committed to
the database file. When the transaction is committed to the database file, all the operations
are permanently applied.
If there is a crash, ESE also handles automatic recovery at start and rolls back any
uncommitted transactions. If ESE fails before a transaction is committed, the entire
transaction is rolled back, and it is as if the transaction never occurred. If ESE crashes after
the transaction is committed, the entire transaction is persisted, and the changes are visible
to clients.
ACID Transactions
Transactions that are this reliable are generally referred to as ACID transactions. ACID
transactions can be identified by the following attributes:
• Atomic This term indicates that a transaction state change is all or none.
Atomic state changes include database changes, and messages and actions on
transducers.
• Consistent This term indicates that a transaction is a correct transformation of

the state. The actions taken as a group do not violate any one of the integrity
constraints associated with the state. This requires that the transaction be a correct
program.
537
• Isolated This term indicates that even though transactions run at the same
time, it appears to each transaction (T) that others executed either before T or after T,
but not both.
• Durable This term indicates that as soon as a transaction is completed

successfully (commits), its changes the state to survive failures.
The Version Store

The version store enables ESE to track and manage current transactions. Therefore, ESE
can pass the Isolated and Consistent part of the ACID test. The version store maintains an in-
memory list of modifications made to the database.
The version store is used in the following situations:
• Rollback If a transaction must roll back, it examines the version store to get the
list of operations it performed. By performing the inverse of all the operations, the
transaction can be rolled back.
• Write-conflict detection If two different sessions try to modify the same record,
the version store notices and rejects the second modification.
• Repeatable reads When a session starts a transaction, it always encounters

the same view of the database, even if other sessions modify the records that it is
viewing. When a session reads a record, the version store is consulted to determine
what version of the record the session should view. Repeatable reads provide an
isolation level in which, after a client starts a transaction, it views the state of the
database as it was when the transaction began, regardless of modifications made by
other clients or sessions. Repeatable reads are implemented by using the version
store. With an in-memory list of modifications made to the database, it can be
determined what view of a record any particular session should view.
• Deferred before-image logging This is a complex optimization that lets ESE

log less data than other comparable database engines.
Snapshot Isolation
After a transaction starts, ESE guarantees that the session views a single, consistent image
of the database, as it exists at the start of its transaction, plus its own changes. Because
other sessions can also modify the data and commit their transactions, these changes are
invisible to any transaction that started before the commit. A user can modify a record only if
that user is viewing the latest version. Otherwise, the update fails with JET_errWriteConflict.
Versions earlier than the latest transaction are automatically discarded.
ESE features a transaction isolation level called Snapshot Isolation. Snapshot Isolation level
allows users to access the last committed row using a transitionally consistent view of the
538
database. Snapshot Isolation is a concurrency control algorithm that was first described in A
Critique of ANSI SQL Isolation Levels. Snapshot Isolation is implemented by ESE by using
repeatable reads.
ESE Database Structure

All data inside the rich-text database file is stored in B-trees. The "B" in B-tree, means
"balanced." "Tree" refers to an arrangement that is similar to a folder structure on a file
system, where a root is the parent of items (database pages) that in turn are parents to
additional items. B-trees are designed to provide fast access to data on disk. Because
reading from and writing to a disk is much slower than performing those operations in
memory, a B-tree is divided into four KB pages. This enables ESE to get the data it needs
using the minimum number of Disk I/Os. An ESE database can contain up to 2^32 (2 to the
32nd power) pages or 16 terabytes. In reality, database size is limited only by your ability to
back up, restore, and perform other maintenance operations on the database (such as offline
defragmentation, and database repairs) in a timely manner.
Database Pages
The page size in ESE is defined by the application that uses it. For example, ESE97
(Exchange Server 5.5) and ESE98 (Exchange 2000 Server and Exchange Server 2003) use
four KB pages, whereas ESENT (Active Directory) uses eight KB pages. Each of these
four KB or eight KB pages contains pointers to other pages or to the actual data that is being
stored in the B-tree. The pointer and data pages are intermixed in the file.
To increase performance wherever possible, pages are cached in a memory buffer for as long
as possible. This reduces the need to go to disk. Each page starts with a 40-byte page
header, which includes the following values:
• pgnoThis This value indicates the page number of the page.
• DbtimeDirtied This value indicates the Dbtime the page was last modified.
• pgnoPrev This value indicates the page number of the adjacent left page on
the leaf.
• pgnoNext This value indicates the page number of the adjacent right page on
the leaf.
• ObjidFDP This value indicates the Object ID of a special page in the database,
referred to as Father of the Data Page (FDP), which indicates which B-tree this page
belongs to. The FDP page is used during repair.
• cbFree This value indicates the number of bytes available on the page.
• cbUncommittedFree This value indicates the number of uncommitted bytes

available (bytes that are free but available for reclaim by rollback) on the page.
539
• ibMicFree This value indicates the page offset for the next available byte at the
top of the page.
ECC Checksum
Exchange Server 2003 Service Pack 1 (SP1) introduces a new feature named Error
Correcting Code (ECC) Checksum. ECC Checksum is a new checksum format that enables
the correction of single-bit errors in database pages (in the .edb file, .stm file, and transaction
log files). This new checksum format uses 64 bits, whereas the earlier checksum format uses
32 bits. Earlier format databases can be used with the new code, but current format
databases cannot be used with earlier versions of ESE. After the database engine is updated,
all pages that are written to the database have the new checksum format. Pages that are
read and not modified do not have their checksum format upgraded.
Note:
After the newer ESE.dll is deployed, any offline defragmentation that you do causes
all pages in the database to have their checksum format upgraded. This could greatly
increase the length of time it takes to defragment the database, and therefore it is not
recommended. Additionally, running eseutil with the /k switch, which also checksums
all pages in the database, is not recommended.
Database pages with the earlier-format checksum start with a four-byte checksum, followed
by a four-byte page number, which is used to verify that the requested page is actually read
off disk.
The new checksum format removes the four-byte page number and instead starts with an
eight-byte checksum. The page number is used as an input parameter in calculating the
checksum. Therefore, if the wrong page is read off disk, there will be a checksum mismatch.
The current checksum format actually consists of two 32-bit checksums. The first is an XOR
checksum, calculated much like the earlier format checksum. The page number is used as a
seed in the calculation of this checksum. The second 32-bit checksum is an ECC checksum,
which allows for the correction of single-bit errors on the page.
Database Consistency and -1018 Errors

• When a page is read, ESE examines a flag on the page to see whether the page
has the current checksum format. The appropriate checksum (current or earlier
format) is then calculated. If there is a checksum mismatch with the current format
checksum, ESE tries to correct the error. If the error cannot be automatically
corrected, Exchange reports a -1018 error.
The Exchange store might be responsible for self-generating a -1018 error, if the Exchange
store does one of the following:
540
• Constructs a page that has the wrong checksum.
• Constructs a page correctly, but tells the operating system to write the page in
the wrong location.
If a system administrator encounters a -1018 error or runs diagnostic hardware tests against
the server and these tests report no issues, the administrator might conclude that Exchange
Server must be responsible for the issue, because the hardware passed the initial analysis.
Frequently, additional investigation by Microsoft or hardware vendors uncovered subtle

issues in hardware, firmware, or device drivers that are actually responsible for damaging the
database file.
Ordinary diagnostic tests might not detect all the transient faults for several reasons. Issues in
firmware or driver software might fall outside the capabilities of diagnostic programs.
Diagnostic tests might be unable to adequately simulate long run times or complex loads.
Also, the addition of diagnostic monitoring or debug logging might change the system enough
to prevent the issue from appearing again.
The simplicity and stability of the Exchange Server mechanisms that generate checksums
and write pages to the database file suggest that a -1018 error is probably caused by
something other than Exchange Server. The checksum and incorrect page detection
mechanisms are simple and reliable, and have remained fundamentally the same since the
first Exchange release, except for minor changes to adapt to database page format changes
between database versions.
A checksum is generated for a page that is about to be written to disk, after all other data is
written to the page, including the page number itself. After Exchange Server adds the
checksum to the page, Exchange Server instructs the Microsoft Windows Server operating
system to write the page to disk by using standard, published Windows Server APIs.
The checksum might be generated correctly for a page, but the page might be written to the
wrong location on the hard disk. This can be caused by a transient memory error, such as a
"bit flip." For example, suppose Exchange constructs a new version of page 70. The page
itself does not experience an error, but the copy of the page number that is used by the disk
controller or by the operating system is randomly changed. This problem can occur if 70
(binary 1000110) has been changed to 6 (binary 000110) by an unstable memory cell. The
page's checksum is still correct, but the location of the page in the database is now wrong.
Exchange Server reports a -1018 error for the page when it detects that the logical page
number does not match the physical location of the page.
Another kind of page numbering error (caused by Exchange Server) might occur if Exchange
Server writes the wrong page number on the page itself. But this causes other errors, not the
-1018 error. If Exchange Server writes 71 on page 70, and then does the checksum on the
page correctly, the page is written to location 71 and passes both the page number and
checksum tests.
541
Frequently, a single -1018 error that is reported in an Exchange Server database does not
cause the database to stop or result in a symptom other than the presence of the -1018 error
itself. The page might be in a folder that is infrequently accessed (for example, the Sent or
Deleted Items folders), or in an attachment that is seldom opened, or even empty.
Even though a single -1018 error is unlikely to cause extensive data loss, -1018 errors are
still cause for concern because a -1018 error is proof that your storage system did not reliably
store or retrieve data at least one time. Although the -1018 error might be a transient issue
that never occurs again, it is more likely that this error is an early warning of an issue that will
become progressively worse. Even if the first -1018 error is on an empty page in the
database, you cannot know which page might be damaged next. If a critical global table is
damaged, the database might not start, and database repair might be partly or completely
unsuccessful.
After a -1018 error is logged, you must consider and plan for the possibility of imminent failure
or additional random damage to the database, until you find and eliminate the root cause.
Database Tree Balancing

One of the primary functions of ESE is to keep the database tree balanced at all times. The
process of balancing the tree is finished when all the pages are either split or merged. As you
can see in the following figure, the same number of nodes is always at the root level of the
tree as is at the leaf level of the tree. Therefore, the tree is balanced.
Balanced tree
Note:
Although the trees inside an ESE database are generally referred to as B-trees, they
are actually B+ trees. B+ trees include all the characteristics of B-trees, but
additionally each data page in the B+ tree has page pointers to its previous and next
adjacent page on the leaf. Although there is an overhead during insertion or split and
542
merge operations to keep these pointers up-to-date, the pointers allow for faster
sequential seeking through the data in the B+ tree structure.
From an ESE perspective, a database table is a collection of B-trees. Each table consists of
one B-tree that contains the data, although there can be many secondary index B-trees used
to provide different views of the data. If a column or field in a table becomes too wide to store
in the B-tree, it is divided to a separate B-tree, named the long-value tree.
The definition of these tables and their associated B-trees is stored in another B-tree, named
the system catalog. Loss of the system catalog is a serious problem. Therefore, ESE keeps
two identical copies of this B-tree in each database, one starting at page four and the other
starting at page 24.
Split
When a page becomes almost full, about half the data is put on a secondary page and an
extra key is put in the secondary page's parent page. This process is performed unless the
parent page is also full. In this event, the parent page is split, and a pointer is added to this
page's parent page. Ultimately, every pointer page up to the root block might need to be split.
If the root block needs to be split, an additional level of pages is inserted into the tree.
Figuratively speaking, the tree grows in height.
Merge
When a page is almost empty, it is merged with an adjacent page, the pointers in the parent
page are updated, and if it is required, the page is merged. Ultimately, if every pointer page
up to the root block is merged, the tree shrinks in height. To obtain to a leaf (data), ESE starts
at the root node and follows the page pointers until it gets to the desired leaf node.
Fan-Out
The tree structure of an ESE B-tree has very high fan-out. High fan-out means ESE can
reach any piece of data in a 50 GB table with no more than four disk reads (three pointer
pages and the data page itself). ESE stores over 200 page pointers per four KB page,
enabling ESE to use trees with a minimal number of parent/child levels (also called shallow
trees). ESE also stores a key of the current tree, which enables ESE to quickly search down
the current tree. The preceding diagram is a tree with three parent/child levels; a tree with
four parent/child levels can store many gigabytes of data.
Indexes
A traditional B-tree is indexed in only one particular way. It uses one key, and the data must
be retrieved using that key. For example, the records in the messages table are indexed on a
543
message's unique identifier, called the message transfer service (MTS)-ID. However, a user
probably wants to view the data in the messages table ordered in a more user friendly format.
Indexes, or more specifically, secondary indexes, are used to retrieve the data. Each
secondary index is another B-tree that maps the chosen secondary key to the primary key.
This makes B-trees small compared to the data they index.
To understand how a secondary index is used, consider what occurs when a user changes
the way messages are presented in a messaging folder. If you change your folder view in
Outlook so that subject, instead of received time, orders the view, Outlook causes the store
and ESE to build a new, secondary index on your message folder table.
When you change views on a large folder for the first time, you will experience a delay. If you
look closely at the server, you see a small spike in disk activity. When you switch to that view
again, the index is already built, and the response is much quicker.
The Microsoft Exchange Information Store services' secondary index B-trees live for eight
days. If they are not used, the Microsoft Exchange Information Store service deletes them as
a background operation.
Long-Values
A column or a record in ESE cannot span pages in the data B-tree. There are values (such as
PR_BODY, which is the message body of a message) that break the 4KB boundary of a
page. These are referred to as long-values (LV). A table's long-value B-tree is used to store
these large values.
If a piece of data is entered in an ESE table, and it is too large to go into the data B-tree, it is
divided into four KB sized pages and stored in the table's separate long-value B-tree. The
record in the data B-tree contains a pointer to the long-value. This pointer is called the long-
value ID (LID) and means that the record has a pointer to LID 256.
Record Format
A collection of B-trees represents a table, and a table is a collection of rows. A row is also
called a record. A record consists of many columns. The maximum size of a record, and
therefore the number of columns that appear in a single record, is governed by the database
page size, minus the size of the header. ESE has a four KB-page size. Therefore, the
maximum record size is approximately 4050 bytes (4096 bytes, minus the size of the page
header).
Column Data Types

Each column definition must specify the data type that is stored in the column. ESE supports
the data types described in the following table.
544
Extensible Storage Engine column data types
Column Data Types Description
Bit NULL, 0, or non-0
Unsigned Byte 1-byte unsigned integer
Short 2-byte signed integer
Unsigned Short 2-byte unsigned integer
Long 4-byte signed integer
Unsigned Long 4-byte unsigned integer
LongLong 8-byte signed integer
Currency 8-byte signed integer
IEEE Single 4-byte floating-point number
IEEE Double 8-byte floating-point number
Date Time 8-byte date-time (integral date, fractional

time)
GUID 16-byte unique identifier
Binary Binary string, length <= 255
Text ANSI or Unicode string, length <= 255 bytes
Long Binary Large value binary string, length < 2 GB
Long Text Large value ANSI or Unicode string, length

< 2 GB
The column data types fall into two categories. The first category is fixed and variable
columns. The second category is tagged columns. Each column is defined as a 16-byte
FIELD structure, plus the size of the column name.
When a table is created in an ESE database, the table is defined by using an array of FIELD
structures. This array identifies the individual columns in the table. Within this array, each
column is represented through an index value, called the column ID. This is similar to an
ordinary array in which you can reference array members by ID, such as array[0], array[1],
and so on. Columns are quickly accessed by ID, but a search by column name requires a
linear scan through the array of FIELD structures.
545
Fixed and Variable Columns

Fixed columns contain a fixed data length. Each record occupies a defined amount of record
space, even if no value is defined. Data type IDs 1 to 10 can be defined as fixed columns.
Each table can define up to 126 fixed columns (column ID 1 to 127).
Variable columns can contain up to 256 bytes of data. An offset array is stored in the record
with the highest variable column set. Each column requires two bytes. Data type Ids 10
and 11 can be defined as variable columns. Each table can define up to 127 variable columns
(column ID 128 to 256).
Tagged Columns
ESE defines columns that occur rarely or have multiple occurrences in a single record as
tagged columns. An undefined tagged column incurs no space overhead. A tagged column
can have repeated occurrences in the same record. If a tagged column is represented in a
secondary index, each distinct occurrence of the column is referenced by the index.
Tagged columns can contain an unlimited, variable length of data. The column ID and length
are stored with the data. All data types can be defined as tagged columns. Each table can
define up to 64,993 tagged columns.
Responsibilities of the Information Store

The primary responsibility of the Exchange store is to maintain Exchange databases and
manage transactions in order to provide other services and messaging clients with access to
mailboxes and public folders. The Exchange store is additionally responsible for space
management (the management of the physical database files) and buffer management (the
management of the Store.exe process memory usage).
Interactivity with other Exchange Services

The Exchange store works in tandem with a number of other services to perform typical
Exchange operations. The following table provides a summary of the services essential to
typical Exchange operations. Note that the services that are available on a particular
Exchange server depend on its configuration.
546
Services essential to the operations of Exchange Server 2003
Service Name Description
Distributed Transaction Coordinator Coordinates transactions that are

distributed across multiple databases,
message queues, and file systems.
Event Log Logs event information, warning, and error

messages issued by Exchange Server and
other applications.
IIS Admin Service Allows you to administer the Exchange

HTTP virtual server in the IIS snap-in.
Microsoft Exchange Event Monitors folders and generates events for

Exchange Server 5.5 applications.
Microsoft Exchange IMAP4 Provides Exchange IMAP4 services.
Microsoft Exchange Information Store Manages Exchange Information storage.
Microsoft Exchange MTA Stacks Provides Exchange X.400 services.
Microsoft Exchange POP3 Provides Exchange POP3 services.
Microsoft Exchange Routing Engine Processes Exchange message routing and

link state information.
Microsoft Exchange Site Replication Replicates Exchange information in the

Service organization.
Microsoft Exchange System Attendant Monitors Exchange and provides essential

service services.
Network News Transfer Protocol (NNTP) Transports newsgroup messages across

the network.
Simple Mail Transfer Protocol (SMTP) Transfers e-mail messages across a

messaging network.
World Wide Web Publishing Service Provides HTTP services for Exchange
Server (Microsoft Outlook Web Access,
Microsoft Outlook Mobile Access, and
Microsoft Exchange ActiveSync), as well as
Internet Information Services (IIS).
547
Space Management
The two types of space in a database file are owned space and available space. Every table,
index, and long-value B-tree has its own list of owned and available pages. Available space is
a list of pages that can be used to store new data. Available space is always a subset of
owned space.
• Owned space ESE organizes owned space in a three-level hierarchy. The

levels are database root, tables, and indexes and long-values. The database root
owns all the space in the database. Tables request chunks of space, which they then
own (as does the database root). Index and long-value trees request space from the
table that in turn owns a chunk of space from the database root. To reduce the
number of requests and to avoid fragmenting the space, requests for more space are
made in chunks (normally 16 pages or 64 KB).
• Available space Available space is slightly different. A page can be available at

the database root, at the table level, or as an index or long-value. A page is available
only at one level.
Database Defragmentation
Defragmentation is the process whereby ESE traverses the pages at the bottom (the leaf
pages) of each B-tree database. ESE determines whether it can merge strings of adjacent
pages to a single page. This frees up pages and returns them to the table's available space.
The locality and contiguity of related pages inside the database file is maximized where
possible.
Defragmentation can be performed in two modes:
• Online defragmentation This runs as part of system maintenance, which by

default is between 1:00 A.M. and 6:00 A.M. If ESE can't complete a full pass through
the database, it notes where it stopped and resumes from this point when the next
Exchange store maintenance window occurs.
Online defragmentation has the following limitations:
• Free space inside the database file (.edb) is not returned to the file
system. Instead, after online defragmentation completes, the Microsoft
Exchange Information Store service logs an event in the application event log
(Event ID 1221) that indicates the amount of available free database space.
This free space is used if needed, before the physical database file grows.
• Available space in a database is in the form of a list of pages that can be

used to store new data. The available space is called a space tree. The
space tree is held as a B-tree that is searched whenever a block of new data
must be added to the database. Space trees are not removed during online
548
defragmentation and remain fragmented until an offline defragmentation is

performed.
• Deleted column IDs and long-value IDs are not reclaimed.
• Secondary indexes are rearranged but not rebuilt (if there is index
corruption, it is not repaired).
• Vertical merge is not supported in the database file (.edb) (tree levels are
not collapsed).
• Offline defragmentation This is a manual process that is accomplished by an

administrator running the ESEUTIL utility against their databases. Eseutil.exe is a
command-line utility located in the \Program Files\Exchsrvr\Bin directory.
Note:
If a mailbox or public folder store is mounted while you try to use ESEUTIL.exe to
compact its databases, the error code -1032 (JET_errFileAccessDenied) is
returned. Remember to perform a full backup both before and after
defragmenting databases offline.
Buffer Management
A fundamental design goal of ESE is to avoid disk access. To do this, ESE uses a
comprehensive buffer manager. The buffer manager performs the following two jobs:
• It decides how much memory the buffer cache should use. This is accomplished
using an internal feature called Dynamic Buffer Allocation (DBA).
• It decides which pages should remain in the buffer cache. An algorithm named
LRU-K makes this decision.
Dynamic Buffer Allocation

Dynamic buffer allocation (DBA), a feature which was first introduced in Exchange Server 5.5,
has become a major factor in Microsoft Exchange Information Store service memory usage.
ESE monitors the state of the cache continuously. It verifies the system's requirements and
makes adjustments to the cache size when necessary.
Dynamic buffer allocation uses four rules to govern how large or small the cache should be:
• The more memory available, the faster the Exchange store's working set grows.
• The more cache memory, the faster the Exchange store's working set shrinks.
• The higher the memory load, the faster the Exchange store's working set grows.
• The higher the available memory load, the faster the Exchange store's working
set shrinks.
549
DBA uses a patented formula to determine how the buffer cache size should grow or shrink
over time.
The LRU-K Replacement Algorithm

DBA manages the size of the buffer. With time, the buffer fills with cached database pages. To
make room for more pages, earlier pages must be removed from the cache. DBA provides a
mechanism to determine which pages stay in the cache. Traditionally, database systems use
the least recently used (LRU) algorithm, first described by Denning in 1968 (P. J. Denning,
Resource Allocation In Multiprocess Computer Systems, Massachusetts Institute of
Technology, Cambridge, MA, 1968). When buffer space is needed, LRU drops from the
memory buffer the page that has not been accessed for the longest time.
However, the LRU algorithm has a flaw. It decides what page to drop from memory based
only on the time of last reference. Specifically, LRU is unable to differentiate between pages
that have relatively frequent references and pages that have very infrequent references. For
example, a page may have been accessed 100 times, followed by another page, accessed
only a single time. According to LRU, the page accessed 100 times would be dropped,
regardless of the fact that this page is more popular than the other page that was only
accessed once.
To optimize database disk buffering, the LRU-K algorithm was introduced in 1993 (Elizabeth
J. O'Neil, Patrick E. O'Neil, Gerhard Weikum, The LRU-K Page Replacement Algorithm For
Database Disk Buffering. SIGMOD Conference 1993). This algorithm surpasses conventional
buffering algorithms by discriminating between frequently and infrequently referenced pages.
Exchange Server 2003 uses the LRU-K algorithm.
The LRU-K algorithm keeps track of the times of the last K references to memory pages (ESE
sets the default value of K to 2) and uses this statistical information to rank-order the pages
according to their expected future behavior. Based on this statistical information, ESE can
decide which memory-resident page to drop in order to make room for a newly accessed
page that must be read into memory. Because statistical information about referenced pages
is constantly collected, the LRU-K algorithm adapts in real time to changing patterns of
access. This algorithm is fairly simple and incurs little bookkeeping overhead. It uses the last
two or more references, generally the last K references, (where K is greater than or equal to
2) for each page to decide which page should be dropped.
Public Folder Replication

The root of a public folder tree, as viewed in Exchange System Manager, is referred to as the
top level hierarchy. In Exchange Server 2003, there can be several top level hierarchies. The
public folder top level hierarchy (also referred to as the MAPI top level hierarchy) is just one
of many public folder trees. The MAPI top level hierarchy in Exchange Server 2003 performs
550
the same tasks that it performed in previous versions of Exchange and also replicates an
Exchange 2000 or Exchange 5.5 public folder tree. Exchange Server 2003 also supports
additional trees, commonly referred to as application top level hierarchies. Each top level
hierarchy has a directory entry. The entry contains a back link to the distinguished names of
all the public stores in the top level hierarchy. The MAPI top level hierarchy is secured in the
directory under the First Administrative Group in the Exchange organization.
A single server can host only one public folder store database in a top level hierarchy. For
active/active clusters, this means that only a single instance of a top level hierarchy database
can exist across both Exchange virtual servers (EVSs) due to the possibility of both EVSs
running on the same physical node. Exchange Server 2003 Service Pack 1 now supports
hosting more than one instance of a public folder tree in an active/passive cluster, because a
single physical node cannot host more than one EVS.
Public Folder Database Trees

The public folder database is divided into two trees: the IPM_Subtree and the non-
IPM_Subtree. The IPM_Subtree contains folders visible to users and clients. For example, a
folder created by Microsoft Outlook exists in the IPM_Subtree. A folder in the IPM_Subtree
can be searched, accessed directly by users, and used to store user data. The non-
IPM_Subtree contains folders not directly accessible by users. The non-IPM_Subtree folders
replicate in exactly the same way as the IPM_Subtree folders, but cannot be manipulated
directly by users.
The non-IPM_Subtree includes the following folders:
• Site Folders These are folders, such as SCHEDULE+ FREE BUSY, Events
registry, MAPI Forms, and Offline Address List.
• Restrictions These folders are not replicated.
• Views These folders are not replicated.
Site folders are visible when viewing system folders in Exchange System Manager. Site
folders replicate in the same way as ordinary folders, and their replication lists can be
modified in the same way as ordinary public folders. The first server running Exchange
Server 2003 in an administrative group holds copies of offline address lists, free/busy data,
and replicas of other site folders. The location of these folders (that is, the public folder store
that hosts these folders) can be changed through Exchange System Manager. Each
administrative group has a site folder server (the first server in the site), which is stored as an
attribute of the administrative group's directory entry. This determines which server is
responsible for making sure that site folders exist.
551
Replication Overview
Public folder replication is the transfer of public folder data between public folder stores in the
same top level hierarchy, using an e-mail-based replication engine. The process is the same
for MAPI top level hierarchies and application top level hierarchies. The folder hierarchy is
replicated through hierarchy replication messages and the content of folders is replicated
through content replication messages between replicas of individual folders. In addition, there
are backfill requests and response messages, and status messages and status request
messages, which keep replication between stores synchronized.
Note:
Internally the store addresses folders by a Folder ID (FID), which is a hex ID; for
example, 1-2A45. An FID is a row in the folders table in the public folder store.
Similarly, messages are referenced by a Message ID (MID), which is a row in the
MsgFolder table. Hierarchy replication messages, for example, are a special type of
content replication message for a folder with the ID 1-1.
Replication uses standard transports to send replication messages to other public folder
stores. If an update must go to multiple public folder stores, then a single replication message
is generated, addressed to the multiple public folder stores (in other words, to the replica list
for the folder, because for a hierarchy, this is all that the public folder stores in the top level).
The SMTP transport engine must categorize and bifurcate the message to deliver it to each
individual public folder store. For more information about message categorization and
bifurcation, see SMTP Transport Architecture.
Public Folder replication is e-mail based. Replication messages are e-mail messages sent
between the public folder stores in each top level hierarchy. Therefore, there must be an e-
mail path between the public folder stores to enable replication.
Folders replicate by sending e-mail between public folder stores. Therefore, public folder
stores require e-mail addresses (added by the recipient update service).
Packing and Unpacking

The process of putting replication data in the replication message ready to be sent is named
packing. The process of retrieving replication data from the replication message is named
unpacking. Multiple hierarchy updates or multiple content updates for the same folder can be
packed in a single replication message. This reduces mail traffic, because a single message
can contain multiple updates (in other words, there is less overhead of message envelope
and message headers). Hierarchy updates cannot be packed in the same replication
message as content updates, and content updates for different folders cannot be packed in
the same replication message.
552
Change Numbers
All updates (create, delete, and modify) are assigned change numbers. Change numbers are
used by the replication engine to track updates. Every modification to a folder is given a
change number. When updates are replicated to another server, the change numbers for the
specific changes are included with the update. The change numbers are then used by the
receiving server to determine whether this is a new change. The replication message also
carries a copy of the complete set of change numbers that exist in the folder on the sending
server, so that the receiving server can determine whether it is missing any data. A set of
change numbers is referred to as a change numbers set (CNset).
Replication Message Types

There are six replication message types. The six types are hierarchy replication messages
(the content replication of FID 1-1), content replication messages (replicating content
between individual folder replicas), backfill request messages, backfill response messages,
status messages, and status request messages. Each of these message types is described
Replication message types
Message Type Description When Used
Hierarchy replication A hierarchy replication Replicates hierarchy

messages (0x2) message is a replication changes from one public
message between replicas folder store to all other
of a special folder with the public folder stores in the
ID 1-1 (FID 1-1). same top level hierarchy.
Content replication Content replication Replicates content changes

messages (0x4) messages replicate content from one replica to all other
updates between replicas of content replicas of that
individual folders. A public folder.
folder store only sends a
content replication to
another public folder store
that holds a replica of the
folder.
553
Backfill request messages Backfilling is the process by Backfill request messages

(0x8) which public folder stores request missing data (in
that miss replication CNSets) from another public
updates can request a re- folder store (both hierarchy
send of missing data. There and content). Backfill
are two parts to the backfill request messages are sent
process: backfill request only to other content
and backfill response. When replicas of the folder (all top
a public folder store level hierarchy members, if
determines that it is not this is for the hierarchy).
synchronized, it issues a
backfill request by detecting
a discrepancy in a folder's
CNSet compared to the
CNSet in some recently
received replication mail.
This is accomplished either
through replication, or
through status messages
sent by other public folder
stores.
Backfill response messages Backfill responses are Backfill response messages

(0x80000002 or structurally identical to their send missing data to a
0x80000004) regular counterparts, but are public folder store that
sent in response to a backfill requested missed updates
request and are addressed (CNSets).
only to the requestor. They
contain the changes
specifically requested.
Multiple responses might be
sent for a single request, if
all requested data is too
large for a single response.
Also, a response might
contain no data at all.
554
Status messages (0x10) A status message is sent in Sends the current CNSets of
response to a status a folder to another replica of
request. It contains the that folder. Used for
complete CNSet of owned hierarchy (replicas of folder
changes on this server. This 1-1) and content (specific
set does not necessarily content replicas).
represent all the changes
that actually occurred,
because all changes might
not have replicated to this
specific public folder store.
Prior to Exchange 2000

Server, status messages for
all folders in the public
folder store were broadcast
every 24 hours. This
resulted in network
overload. Therefore, this
periodic broadcast was
removed in Exchange 2000
Server.
555
Status request messages Sends the folder's current The Exchange store sends a
(0x20) CNSet to all other replicas. status request message in
It simultaneously requests the following situations:
that some subset of those
• An existing
replicas return their own
replica of a public
CNSet. This response
folder might have
comes as a status
missed replication
message. The requested
messages or might
server does not respond if
have been restored
the requesting server's
from an outdated
CNSet is not a strict subset
backup. A status
of the requested server's
request message is
set.
sent by one public
folder store to
another public folder
store to determine if
any changes are
missing locally.
• A new replica of
a public folder was
added to a public
folder store. A new
replica of a folder
generates a status
request for the
content.
• A new public
folder store was
created and
associated with a
particular public
folder hierarchy. A
new public folder
store generates a
status request for
the hierarchy,
because a new
hierarchy folder (FID
1-1) was created.
• An existing
replica of a public
556
Replication Process
Public folder stores send replication messages to each other through e-mail. Therefore, there
must be an e-mail path between the public folder stores for replication messages to be
received. A thread runs continually in the Store.exe process, which polls for replication
events. Replication events occur at specific time intervals. When this timed event occurs, the
replication thread generates a new thread, which performs the specified replication task. The
following are the default replication time intervals:
• Hierarchy replication events occur every five minutes.
• Content replication events occur every 15 minutes.
• A status message is broadcast 24 hours after the last regular replication

broadcast.
Hierarchy Replication
A hierarchy replication message is generated whenever the hierarchy is modified. The
following are examples of hierarchy modification:
• Creating, deleting, or renaming a folder
• Modifying folder permissions or descriptions
• Changing the replication schedule and priority settings
• Adding content to or removing content from a folder
• Modifying replica lists

• Moving the folder in the hierarchy
The following figure illustrates the hierarchy replication process.
Hierarchy replication process

557
In this illustration, Folder 1, Folder 2, and Folder 3 are added to Server A. Server A then
replicates the hierarchy changes to Server B, so that Server B knows about these public
folders in the hierarchy. Users on Server B can now navigate through the hierarchy and select
any one of these folders, but only Server A has the contents of the public folders. When a
client attempts to access Folder 1, Folder 2, or Folder 3, Server B redirects the client to
Server A. Server A returns the content to the client, and the client can display the content.
The redirection process is transparent to the user.
Content Replication
Folder content replicates between individual replicas of folders. When folder content is
modified, the change is tracked with change numbers. When the replication interval is
reached, the changes are replicated to all other public folder stores that have a replica of the
folder.
The following figureillustrates the content replication process.
Content replication process
In this illustration, Item 1 is posted to a folder on Server A, which has a replica on Server B.
The public folder store on Server A replicates the change to the public folder store on
Server B. Similarly, Items 2 and 3 are posted and replicated.
Backfilling
Folders remain synchronized throughout the backfill process. Folders backfill only when they
are missing content. Therefore, for a folder to issue a backfill request, it must first determine
that it missed an update. This is accomplished by determining a missing sequence in the
folder CNSets for individual folders.
Content backfill and hierarchy backfill both work in the same way. A hierarchy backfill is
issued when there is a gap in the CNSets for folder 1-1. A content backfill is requested for
gaps in any other folder.
558
The backfill process can take a long time, especially if a public folder store is down and
missed the original replication update and the subsequent status message. It might not
realize that it is missing content until further replication messages arrive.
Backfill Array
The backfill array is used to store pending backfill requests. When the public folder store
determines that a folder is out of sync, it writes an entry to the backfill array. This entry is a
pending request for the missing data from another replica of the folder. The entry stays in the
backfill array until it times out, at which point a backfill request is issued. The default backfill
timeouts are listed in the following table.
Default backfill timeouts
Backfills Intra Site Inter Site
Initial backfill 6 hours 12 hours
First backfill retry 12 hours 24 hours
Subsequent backfill retries 24 hours 48 hours
If the first backfill attempt is unanswered, subsequent backfill attempts wait longer before they
are sent. These times are extended to prevent unnecessary backfilling. The replication
message might be in transit, delayed, or waiting for a connector's schedule. If the backfill
timeout is too short, public folder stores start issuing backfill requests for messages already in
transit.
Replication Status
There are two categories of status messages: status requests, and status messages. A status
request message is sent from one public folder store to another to request the other public
folder store's current state of a particular folder. A status message is sent from one public
folder store to another to indicate the current state of a particular folder on the sending server.
If the status message indicates that the sending public folder store has more up-to-date
information about the folder, then the receiving store writes an entry to its backfill array to
request a backfill. If the CNSets are shown to be equal (or the receiving server is more
recent) no action is taken.
A public folder store generates a status message under the following two circumstances:
• In response to a status request If a public folder store receives a status

request from another public folder store, it returns a status message. This occurs
when the replica list of folders is changed (for example, when a folder is removed
from a server).
559
• 24 hours after the last local change to a folder This is a significant change
from previous versions of Exchange. When a change is made to a folder, an expiry
time for a status message is set on that folder. If another change is made to that
folder, the expiry time is reset to 24 hours.
After the expiry time is reached, a status message is generated for that folder. After this
occurs, the expiry time is cleared and no other status messages are generated for that folder
unless another change is made, which resets the expiry time to 24 hours.
Replication Status Thread

The thread that determines whether a status message should be sent runs by default at
12:15 A.M. and 12:15 P.M., Greenwich mean time. When it runs, it checks to see if the
timeout has been reached for any folders, in which case it broadcasts a status message.
Therefore, it could take up to 36 hours of zero changes to generate a status message.
The replication status thread timing can be altered with the following registry settings:
• Replication Send Status Timeout
• Replication Send Status Alignment
• Replication Send Status Alignment Skew
With the reduced number of status messages sent by Exchange Server 2003, it should not be
necessary to modify the default values. For more information on these settings, see Microsoft
Knowledge Base article 203170, "XADM: Controlling Public Folder Hierarchy Status
Messages."
Replication Status Requests

A status request occurs when a public folder store requires a remote server's status for a
particular folder. Depending on the circumstances, a status request might trigger a return
status message.
A status request is generated under the following circumstances:
• When a new public store is mounted for the first time When a public folder
store is mounted for the first time, it generates a hierarchy status request for folder 1-
1. (No content replicas can be assigned to this public folder store, so the only thing
that it is missing is the hierarchy). This triggers another public folder store to send a
status message for the hierarchy, which results in the addition of several entries in
the new server's backfill array. Shortly thereafter, backfill requests for the missing
changes are sent, causing other servers to send replication messages containing the
missing updates.
560
• When the replica list of a folder is changed When the replica list of a folder
changes, a status request message is generated. Adding a new replica, deleting a
replica, or a temporary replica re-home all generate status requests.
• When a public store database is restored from backup When a restored

database is out of the replication loop for an indeterminate amount of time, a status
request for the hierarchy and all content replicas in the hierarchy is broadcast. This
request accomplishes two things. All other servers get a revised picture of this
server's change number information, and a mass update of change number
information occurs on the newly restored database. This leads to the filing of backfill
entries, and ultimately to the sending of backfill requests.
Modifying the Replica List

Modifying the replica list is a hierarchy change. However, because the replica list is changing
(folder replicas are either being created or removed from a server), status messages and
status requests are also used.
Adding a Replica
When a new replica is added to a folder, the following steps occur:
1. A hierarchy replication message is sent to replicate the change in the folder's

replica list.
2. The server that was newly added as a replica sends a status request message to
all other content replica servers.
3. Because the newly added server has an empty CNSet, it is a strict subset of all
other content replica's CNSets, so they all respond with a status message.
4. Backfill entries are filed, backfill requests are sent to appropriate servers, and the
servers respond with content.
5. At any point after Step 1, other content replicas might send regular content
replication broadcasts to the new replica server.
Steps 1 and 2 might not always occur in the same order, depending in which public folder
store the original change was made. If the administrator makes the change on a server that
has a content replica, then the steps occur in the above order. If the administrator makes the
change on the server that hosts the new replica, Steps 1 and 2 might occur in the reverse
order.
561
Deleting a Replica
When a replica is removed from a server, the folder is not deleted immediately. Instead, the
folder is put in a delete pending state. When a folder is in a delete pending state, it cannot be
viewed by a client or administered. (Exchange System Manager does not show the folder on
the list of folders hosted on the public folder store.)
The delete pending state exists so that other replicas can replicate any missing data from it.
After the delete pending folder receives status messages from all other replicas, indicating
that the folders are synchronized, the deleted replica is removed. This process ensures that if
you change the sole replica of a folder from one server to another server, no content is lost.
When deleting a replica, the following steps occur:
1. The folder is removed from the replica list.
2. A hierarchy message is replicated indicating the change in the folder's status (for
example, Active -> Delete Pending).
3. The server that hosts the Delete Pending folder sends a status request, which
requires a response.
4. A server with a replica responds to the status request with a status message. If
the status message indicates that CNSets are at least as current as the replica being
deleted, the public folder store proceeds to Step 5. Otherwise, it continues to send
status requests until it receives the correct response.
5. The folder being deleted has its state changed from delete pending to delete
now, and the folder is deleted.
Replication State Tables

Every replicated folder (including the hierarchy) has a set of rows in the replication state
table, which holds replication state information about each folder. Each row in a folder's set of
rows represents a replica of that folder. The row for the local server contains, among other
things, the change number last broadcast, the locally owned CNSet, the backfill array, the
time the next status broadcast should occur, and other data. The rows for other replicas
contain the CNSet information that the local server has last received from each other server
(one per row), the average transmission time for replication e-mail from each other server, the
last time a backfill request was sent to each other server, and more.
Every time a replication message is sent, the CNSet from the replication state table for the
local replica of the folder is included with the message.
The replication state tables themselves do not replicate. Replication is generated by the data
from the CNSets. This is how public folder stores determine what data other replicas of a
folder contain.
562
Note:
Each server tracks updates from other servers using a replication ID (ReplID).
ReplIDs are calculated locally. Therefore, public folder stores do not have the same
ReplIDs across multiple servers.
Default Replication Event Schedule

The following table illustrates some of the more common default timeouts associated with
replication events. The main replication task thread generates additional worker threads to
handle replication tasks when these default timeouts are reached. If there is nothing to
replicate, the thread simply exits, and no replication message is generated.
Default replication event times
Replication Event Default Timeout Comments
Replication Expiry 24 hours How often folders are

checked for expiry.
Replication Send Always 15 minutes This is the default Replicate

Always value. This is how
often the store checks to
see whether it needs to
replicate content. This value
can be adjusted using
Replication Send Folder 5 minutes This is how often the public

Tree folder store checks to see
whether a hierarchy
replication message needs
to be sent.
Replication Send Status 24 hours This is how often the public

Timeout folder store checks to see
whether a status message
for a folder should be sent.
Replication Timeout 5 minutes This is how often the public

folder store checks to see if
any backfill entries have
timed out.
563
Replication Event Default Timeout Comments
Replication New Replica 15 minutes This is the time delay used

Backfill Request Delay before sending a backfill
request for a new folder
replica when the data is
available on the same site.
Replication Short Backfill 6 hours This is the time delay used

Request Delay before sending a backfill
request when the data is
Replication Long Backfill 12 hours This is the time delay used

Request Delay before sending a backfill
request when the data is not
Replication Short Backfill 12 hours This is the timeout value

Request Timeout used when retrying to send
a backfill request when the
data is available on the
same site.
Replication Long Backfill 24 hours This is the timeout value

Request Timeout used when retrying to send
a backfill request when the
data is not available on the
same site
Replication Short Backfill 24 hours This is the timeout value

Request Timeout Retry used when sending a
backfill request when the
data is available on the
same site and when this is a
retry of a previous backfill
request.
Replication Long Backfill 48 hours This is the timeout value

Request Timeout Retry used when sending a
backfill request when the
data is not available on the
same site and when this is a
retry of a previous backfill
request.
564
Default Replication Values

The following table illustrates some of the other default values used in public folder
replication.
Default replication values
Description Value Comments
Replication Folder Count 20 Maximum number of folders

Limit to pack in a hierarchy
replication message.
Replication Deleted Folder 500 Maximum number of folder

Count Limit deletes to pack in a
hierarchy replication
message.
Replication Message Count 100 Maximum number of

Limit messages to pack in a
content replication message.
Replication Message Size 300 KB Maximum replication

Limit message size. This value
can be adjusted using
If necessary, a single
replication message might
exceed the limit. This value
represents the size at which
the packing function should
stop packing. If a single post
in a folder exceeds this limit,
it is sent alone, in its entirety.
Exchange Server 2003 Cluster Architecture

In Microsoft Windows Server 2003, a server cluster is an arrangement of individual
computers that each run the Microsoft Windows Cluster service. The computers that
compose the server cluster are connected to each other through a network and a shared disc
system. Server clusters have two significant advantages. First, the Cluster service monitors
the servers that belong to a cluster. If a service fails on one server, the Cluster service brings
it back online quickly by rerouting the service through another server. This helps minimize
565
system downtime. Second, server clusters simplify hardware and software maintenance. You
can perform a rolling upgrade by moving cluster resources, often referred to as virtual
servers, to alternate nodes and then performing hardware or software upgrades on the
original node. You can prevent downtime and simplify system maintenance by deploying
Microsoft Exchange Server 2003 in a Windows Server 2003 server cluster.
Note:
To install Exchange 2003 in a server cluster with up to eight nodes, you must use
Windows Server 2003 Enterprise Edition or Datacenter Edition, and Exchange
Server 2003 Enterprise Edition. You can find a feature comparison of the Windows
Server 2003 family of products at http://go.microsoft.com/fwlink/?LinkId=33135.
This section discusses the Windows Cluster service architecture, and the interaction between
Exchange Server 2003 Enterprise Edition and the Windows Cluster service. It includes
information on tasks that need to be performed on Exchange servers running in a server
cluster. The following topics are discussed in detail:
• Windows Cluster service architecture The general characteristics of

clustered systems running Windows Server 2003 are discussed in this section. High-
availability solutions for Exchange 2003 mailbox servers require an understanding of
the Windows Cluster service architecture and how the Cluster service interacts with
cluster-aware applications such as Exchange 2003.
• Exchange Virtual Servers An Exchange Virtual Server is an instance of

Exchange 2003 Enterprise Edition that is configured to run in a server cluster. The
characteristics of virtual servers determine how clients connect to Exchange 2003
Enterprise Edition in a server cluster, regardless of the physical node that is running
Exchange 2003.
• Interaction between Exchange 2003 Enterprise Edition and the Cluster

service The Windows Cluster service monitors the physical nodes in a cluster and
the resources hosted on the nodes. There is continuous interaction between the
Cluster service and the various Exchange cluster resources that compose an
Exchange Virtual Server in a cluster.
• Cluster-Specific Configurations While running Exchange 2003 in a Windows

server cluster is very similar to running a standalone (that is, non-clustered)
Exchange server, there are some considerations that are unique to clusters. For
example, certain Exchange 2003 resources that run in a cluster require specific
configurations to communicate in a cluster server.
For more information about Windows clustering technologies, see Clustering Technologies.
566
Windows Cluster Architecture

Microsoft Cluster Server (MSCS) in Microsoft Windows NT Server 4.0 Enterprise Edition was
the first server cluster technology offered by Microsoft. Individual servers that compose a
cluster are referred to as nodes. A Cluster service is a collection of components on each node
that perform cluster-specific tasks. Hardware and software components in the cluster that are
managed by the Cluster service are referred to as resources. Server clusters provide the
instrumentation mechanism for managing resources through resource DLLs, which define
resource abstractions (in other words, they abstract a clustered resource from a specific
physical node, enabling the resource to move from one node to another), communication
interfaces, and management operations.
Resources are elements in a cluster that are:
• Brought online (in service) and taken offline (out of service)
• Managed in a server cluster
• Owned by only one node at a time
A resource group is a collection of resources, managed by the Cluster service as a single,

logical unit. This logical unit is often referred to as a failover unit, because the entire group
moves as a single unit between nodes. Resources and cluster elements are grouped logically
according to the resources added to a resource group. When a Cluster service operation is
performed on a resource group, the operation affects all individual resources contained in the
group. Typically, a resource group is created that contains the individual resources required
by the clustered program.
Cluster resources may include physical hardware devices, such as disk drives and network
cards, and logical items such as IP addresses, network names, and application components.
Clusters also include common resources, such as external data storage arrays and private
cluster networks. Common resources are accessible by each node in the cluster. One
common resource is the quorum resource, which plays a critical role in cluster operations.
The quorum resource must be accessible for all node operations, including forming, joining or
modifying a cluster.
Server Clusters
Windows Server 2003 Enterprise Edition provides two types of cluster technologies for use
with Exchange Server 2003 Enterprise Edition. The first is Cluster services, which provide
failover support for back-end mailbox servers that require a high level of availability. The
second is Network Load Balancing (NLB), which complements server clusters by supporting
highly available and scalable clusters of front-end Exchange protocol virtual servers (for
example, HTTP, IMAP4, and POP3).
567
Server clusters use a shared-nothing model. Model types define how servers in a cluster
manage and use local and common cluster devices and resources. In the shared-nothing
cluster, each server owns and manages its local devices. Devices common to the cluster,
such as common disk arrays and connection media, are selectively owned and managed by
only one node at a time.
Server clusters use standard Windows drivers to connect to local storage devices and media.
Server clusters support multiple connection media for the external common devices, which
must be accessible by all servers in the cluster. External storage devices support standard
PCI–based SCSI connections, SCSI over Fibre Channel, and SCSI bus with multiple
initiators. Fibre connections are SCSI devices that are hosted on a Fibre Channel bus,
instead of on a SCSI bus.
The following figure illustrates components of a two-node server cluster, which is comprised
of servers running Windows Server 2003 Enterprise Edition, with shared storage device
connections using SCSI or SCSI over Fibre Channel.
Sample two-node Windows cluster
Server Cluster Architecture

Server clusters are designed as separate, isolated sets of components, which work closely
together with Windows Server 2003. Modifications to the operating system are enabled when
the Cluster service is installed. These modifications include the following:
• Support for dynamic creation and deletion of network names and addresses
• Modifications to the file system, to enable closing open files during disk drive
dismounts
• Modifications to the storage subsystem, to enable sharing disks and volumes

among multiple nodes
568
Apart from these and other minor modifications, a server running the Windows Cluster
service runs identically to a server that is not running the Windows Cluster service.
Cluster service is at the core of server clusters. Cluster service is comprised of multiple
functional units, including Node Manager, Failover Manager, Database Manager, Global
Update Manager, Checkpoint Manager, Log Manager, Event Log Replication Manager, and
Backup/Restore Manager.
Cluster Service Components

The Cluster service runs on Windows Server 2003 Enterprise Edition, using network drivers,
device drivers, and resource instrumentation processes specifically designed for server
clusters and their component processes. The Cluster service includes the following
components:
• Checkpoint Manager This component saves application registry keys in a

cluster directory stored on the quorum resource. To make sure that the Cluster
service can recover from a resource failure, Checkpoint Manager checks registry
keys when a resource is brought online and writes checkpoint data to the quorum
resource when a resource goes offline. Checkpoint Manager also supports resources
with application-specific registry trees that are instantiated at the cluster node, where
the resource comes online. A resource can have one or more registry trees
associated with it. When the resource is online, Checkpoint Manager monitors
changes to these registry trees. If Checkpoint Manager detects changes, it transfers
the registry tree to the owner node of the resource. Checkpoint Manager then
transfers the file to the owner node of the quorum resource. Checkpoint Manager
performs batch transfers, so that frequent changes to registry trees do not place too
heavy a load on the Cluster service.
• Database Manager Database Manager maintains cluster configuration

information about all physical and logical entities in a cluster. These entities include
the cluster itself, cluster node membership, resource groups, resource types, and
descriptions of specific resources, such as disks and IP addresses.
Persistent and volatile information stored in the configuration database tracks the current
and desired state of a cluster. Each instance of Database Manager running on each node
in the cluster cooperates to maintain consistent configuration information across the
cluster and to ensure consistency of the configuration database copies on all nodes.
Database Manager also provides an interface for use by other Cluster components, such
as Failover Manager and Node Manager. This interface is similar to the registry interface
of Microsoft Win32 APIs. However, the Database Manager interface writes changes
made to cluster entities in both the registry and in the quorum resource.
Database Manager supports transactional updates of the cluster registry hive and only
presents interfaces to internal Cluster service components. Failover Manager and Node
569
Manager typically use this transactional support to get replicated transactions. The
Cluster API presents all Database Manager functions to clients, with the exception of
transactional support functions. For additional information on the Cluster API, see Cluster
API on MSDN.
Note:
The application registry key data and changes are recorded by Checkpoint
Manager in quorum log files, in the quorum resource.
• Event Service Event Service serves as a switchboard, sending events to and

from applications, and to the Cluster service components on each node. The Event
Processor component of the Event Service helps Cluster service components to
disseminate information about important events to all other components. The Event
Processor component supports the Cluster API event mechanism. It also performs
miscellaneous services, such as delivering signal events to cluster-aware
applications and maintaining cluster objects.
• Event Log Replication Manager The Event Log Replication Manager

replicates event log entries from one node to all other nodes in the cluster. By default,
the Cluster service interacts with the Windows Event Log service in the cluster to
replicate event log entries to all cluster nodes. When the Cluster service starts on the
node, it invokes a private API in the local Event Log service and requests that the
Event Log service bind to the Cluster service. The Event Log service then binds to
the CLUSAPI interface by using local remote procedure calls (RPCs). When the
Event Log service receives an event to be logged, it logs it locally, drops the event
into a persistent batch queue, and schedules a timer thread to run within the next 20
seconds, if there is no timer thread that is active already. When the timer threads
fires, it processes the batch queue and sends the events, as one consolidated buffer,
to the Cluster API interface, where the Event Log service was previously bound. The
Cluster API interface then sends the event to the Cluster service.
After the Cluster service receives batched events from the Event Log service, it drops the
events into a local outgoing queue and returns from the RPC. The event broadcaster
thread, in the Cluster service, then processes this queue and sends the events, using the
intra-cluster RPC, to all active cluster nodes. The server side API then drops the events
into an incoming queue. An event log writer thread then processes this queue and
requests, through a private RPC, that the local Event Log service write the events locally.
The Cluster service uses lightweight remote procedure call (LRPC) to invoke the Event
Log service's private RPC interfaces. The Event Log service also uses LRPCs to invoke
the Cluster API interface and then request that the Cluster service replicate events.
• Failover Manager Failover Manager performs resource management and

initiates appropriate actions, such as startup, restart, and failover. Failover Manager
stops and starts resources, manages resource dependencies, and initiates failover of
570
resource groups. To perform these actions, Failover Manager receives resource and
system state information from Resource Monitors and cluster nodes.
Failover Manager also decides which nodes in the cluster should own which resource
group. When resource group arbitration finishes, nodes that own an individual resource
group return control of the resources in the resource group to Node Manager. If a node
cannot handle a failure of one of its resource groups, Failover Managers on each node
work together to reassign ownership of the resource group.
If a resource fails, Failover Manager restarts the resource or takes the resource offline
together with its dependent resources. If Failover Manager takes the resource offline, it
indicates that the ownership of the resource will be moved to another node. The resource
is then restarted, under the ownership of the new node. This is referred to as failover, as
explained in the section "Cluster Failover" later in this topic.
• Global Update Manager Global Update Manager provides the global update
service that is used by cluster components. Global Update Manager is used by
internal cluster components, such as Failover Manager, Node Manager, and
Database Manager, to replicate changes to the cluster database across nodes.
Global Update Manager updates are typically initiated as a result of a Cluster API
call. When a Global Update Manager update is initiated at a client node, it first
requests a locker node to obtain a global lock. If the lock is not available, the client
waits for one to become available.
When the lock is available, the locker grants the lock to the client, and issues the update
locally (on the locker node). The client then issues the update to all other healthy nodes,
including itself. If an update succeeds on the locker, but fails on some other node, that
node will be removed from the current cluster membership. If the update fails on the
locker node itself, the locker merely returns the failure to the client.
• Log Manager Log Manager writes changes to recovery logs that are stored on
the quorum resource. Log Manager, together with Checkpoint Manager, ensures that
the recovery log on the quorum resource contains the most recent configuration data
and change checkpoints. If one or more cluster nodes are down, configuration
changes can still be made to the remaining nodes. While these nodes are down,
Database Manager uses Log Manager to log configuration changes to the quorum
resource.
When failed nodes return to service, they read the location of the quorum resource from
their local cluster registry hives. Because the hive data could be stale, mechanisms are in
place to detect invalid quorum resources read from a stale cluster configuration
database. Database Manager then requests that Log Manager update the local copy of
the cluster hive, using the checkpoint file in the quorum resource. The log file is then
replayed in the quorum disk, starting from the checkpoint log sequence number. The
result is a completely updated cluster hive. Cluster hive snapshots are taken whenever
the quorum log is reset and once every four hours.
571
• Membership Manager Membership Manager monitors cluster membership and

the health of all nodes in the cluster. Membership Manager (also referred to as the
Regroup Engine) maintains a consistent view of which cluster nodes are currently up
or down. The core of the Membership Manager component is a regroup algorithm
that is invoked whenever there is evidence that one or more nodes failed. At the
completion of the algorithm, all participating nodes reach identical conclusions on the
new cluster membership.
• Node Manager Node Manager assigns resource group ownership to nodes,

based on group preference lists and node availability. Node Manager runs on each
node and maintains a local list of nodes that belong to the cluster. Periodically, Node
Manager sends messages, named heartbeats, to its counterparts running on other
nodes in the cluster to detect node failures. All nodes in the cluster must have exactly
the same view of cluster membership.
If a cluster node detects a communication failure with another cluster node, it transmits a
multicast message to the entire cluster. This regroup event causes all members to verify
their view of the current cluster membership. During the regroup event, the Cluster
service prevents write operations to any disk devices common to all nodes in the cluster,
until the membership stabilizes. If an instance of Node Manager on an individual node
does not respond, the node is removed from the cluster, and its active resource groups
are moved to another active node. To make this change, Node Manager identifies
possible owners (nodes) that may own individual resources and the node on which a
resource group prefers to run. Node Manager then selects the node and moves the
resource group. In a two-node cluster, Node Manager simply moves resource groups
from a failed node to the remaining node. In a cluster comprised of three or more nodes,
Node Manager selectively distributes resource groups among the remaining nodes.
Node Manager also acts as a gatekeeper, allowing joiner nodes into the cluster and
processing requests to add or evict a node.
• Resource Monitor Resource Monitor verifies the health of each cluster

resource by using callbacks to resource DLLs. Resource Monitors run a separate
process and communicate with Cluster Server through RPCs. This protects the
Cluster service from failures of individual cluster resources.
Resource Monitors provide the communication interface between resource DLLs and the
Cluster service. When the Cluster service must obtain data from a resource, Resource
Monitor receives the request and forwards it to the appropriate resource DLL. Conversely,
when a resource DLL must report its status or notify the Cluster service of an event,
Resource Monitor forwards the information from the resource to the Cluster service.
The Resource Monitor process (RESRCMON.EXE), is a child process of the Cluster

service process (CLUSSVC.EXE). Resource Monitor loads resource DLLs that monitor
cluster resources in its process space. Loading the resource DLLs in a process separate
from the Cluster service process helps to isolate faults. Multiple Resource Monitors can
be instantiated at the same time.
572
Each Resource Monitor functions as an LRPC server for the Cluster service process.
When the Cluster service receives a Cluster API call that requires talking to a resource
DLL, it uses the LRPC interface to invoke the Resource Monitor RPC. To receive
responses from Resource Monitor, the Cluster service creates one notification thread per
Resource Monitor process. This notification thread invokes an RPC that is located
permanently in Resource Monitor. The thread acquires notifications when they are
generated. The thread is released only when Resource Monitor fails or when the thread is
manually stopped by a shutdown command from the Cluster service.
Resource Monitor does not maintain a persistent state on its own. It retains a limited, in-
memory state of the resources, but all of its initial state information is supplied by the
Cluster service. Resource Monitor communicates with the resource DLLs through well-
defined entry points that the DLLs must present. Resource Monitor completes the
following operations on its own:
• It polls resource DLLs through the IsAlive and LooksAlive entry points,
alternately checking failure events signaled by resource DLLs.
• To monitor pending timeouts of resource DLLs, it spawns timer threads

that return ERROR_IO_PENDING from the DLL's Online or Offline entry
points.
• It detects crashes of the Cluster service and shuts down the resources.
Its other actions occur as a result of operations requested by the Cluster service through
the RPC interface. No hang detection is perfomed by the Cluster service. The Cluster
service does, however, monitor crashes, and it restarts a monitor if it detects a process
crash.
The Cluster service and Resource Monitor process share a memory-mapped section
backed by the paging file. The handle to the section is passed to Resource Monitor at
Resource Monitor startup. Resource Monitor then duplicates the handle and records the
entry point number and resource name into this section immediately before calling a
resource DLL entry point. If Resource Monitor crashes, the Cluster service reads the
shared section to detect the resource and the entry point that caused the crash.
• Backup/Restore Manager Backup/Restore Manager works with Failover

Manager and Database Manager to back up or restore the quorum log file and all
checkpoint files. The Cluster service uses the BackupClusterDatabase API for
database backup. First, the BackupClusterDatabase API contacts the Failover
Manager layer. The Failover Manager layer forwards the request to the node that
currently owns the quorum resource. That node then invokes Database Manager,
which makes a backup of the quorum log file and all checkpoint files.
The Cluster service also registers itself at startup as a backup writer with Volume Shadow
Copy service. When a backup client invokes the Volume Shadow Copy service to
perform a system state backup, it also invokes the Cluster service, through a series of
entry point calls, to perform the cluster database backup. The server code in the Cluster
573
service invokes the Failover Manager to perform the backup, and the rest of the
operation occurs via the BackupClusterDatabase API.
The Cluster service uses the RestoreClusterDatabase API to restore the cluster database
from a backup path. This API can only be invoked locally from one of the cluster nodes.
When the RestoreClusterDatabase API is invoked, it stops the Cluster service, restores
the cluster database from the backup, sets a registry value that contains the backup path,
and then re-starts the Cluster service. On startup, the Cluster service detects that a
restore is requested and restores the cluster database from the backup path to the
quorum resource.
Cluster Failover
Failover can occur automatically because of an unplanned hardware or software failure, or it
can occur as the result of manual initiation by an administrator. The algorithm and behavior in
both situations is almost identical. However, in a manually initiated failover, resources are
shut down in an orderly way; whereas in unplanned failovers, resources are shut down in a
sudden and disruptive way (for example, the power goes out, or a crucial hardware
component fails).
When an entire node in a cluster fails, its resource groups transfer to one or more available
nodes in the cluster. Automatic failover is similar to planned administrative reassignment of
resource ownership. However, it is more complicated, because the orderly steps of a planned
shutdown might be interrupted or might not have occurred at all. Therefore, extra steps are
required to evaluate the state of the cluster at the time of failure.
When your network experiences an automatic failover, it is important to determine what

groups were running on the failed node and which nodes should take ownership of the
various resource groups. All nodes in the cluster that are capable of hosting the resource
groups negotiate for ownership. This negotiation is based on node capabilities, current load,
application feedback, the node preference list, or the use of the AntiAffinityClassNames
property, which is discussed in the Cluster-Specific Configurations. When negotiation of the
resource group is completed, all nodes in the cluster update their databases and track which
node owns the resource group.
In clusters with more than two nodes, the node preference list for each resource group can
specify a preferred server, plus one or more prioritized alternatives. This enables cascading
failover, in which a resource group can survive multiple server failures, each time cascading,
or failing over to the next server on its node preference list.
An alternative to automatic failover, is commonly called N+I failover. This method establishes
the node preference lists for all cluster groups. The node preference list identifies the standby
cluster nodes, to which resources are moved at the first failover. The standby nodes are
servers in the cluster that are mostly idle or that have workloads that can be easily pre-
empted if a failed server's workload must be moved to the standby node.
574
Cascading failover assumes that every other server in the cluster has some excess capacity
and can absorb a portion of any other failed server's workload. N+I failover assumes, that the
+I standby servers are the primary recipients of excess capacity.
Cluster Failback
When a node comes back online, Failover Manager can decide to move one or more
resource groups back to the recovered node. This is referred to as failback. The properties of
a resource group must have a preferred owner defined to fail back to a recovered or restarted
node. Resource groups for which the recovered or restarted node is the preferred owner are
moved from the current owner to the recovered or restarted node.
Failback properties of a resource group can include the hours of the day during which failback
is allowed and a limit on the number of times failback is attempted. This enables the Cluster
service to prevent failback of resource groups during peak processing times or to nodes that
have not been correctly recovered or restarted.
Cluster Quorum
Each cluster has a special resource referred to as the quorum resource. A quorum resource
can be any resource that does the following:
• Provides a means for arbitration leading to membership and cluster state

decisions
• Provides physical storage to hold configuration information
A quorum log is a configuration database for the entire server cluster. The quorum log
contains cluster configuration information, such as the servers that are part of the cluster, the
resources that are installed in the cluster, and the state of those resources (for example,
online or offline).
The quorum is important in a cluster for the following two reasons:
• Consistency A cluster is made up of multiple physical servers acting as a

single virtual server. It is critical that each of the physical servers has a consistent
view of the cluster configuration. The quorum acts as the definitive repository for all
configuration information relating to the cluster. If the Cluster service is unable to
access and read the quorum, it cannot start.
• Tie-breaking The quorum is used as a tie-breaker to avoid split-cluster

scenarios. A split-cluster scenario occurs when all network communication links
between two or more cluster nodes fail. If this occurs, the cluster might be split into
two or more partitions that cannot communicate with each other. The quorum
ensures that cluster resources are brought online on one node only. It does this by
575
allowing the partition that owns the quorum to continue, while the other partitions are
evicted from the cluster.
Standard Quorum
As mentioned earlier in this section, the quorum is a configuration database for the Cluster
service that is stored in the quorum log file. A standard quorum uses a quorum log file,
located on a disk hosted in the shared storage array, which is accessible by all members of
the cluster.
Each member connects to the shared storage using SCSI or Fibre Channel. Storage is made
up of external hard disks (usually configured as RAID disks) or a SAN, in which logical slices
of the SAN are presented as physical disks.
Note:
It is important that the quorum uses a physical disk resource, rather than a disk
partition, because the entire physical disk resource is moved during failover.
Furthermore, it is possible to configure server clusters to use the local hard disk on a
server to store the quorum. This type of implementation, referred to as a lone wolf
cluster, is supported only for testing and development purposes. Lone wolf clusters
should not be used to cluster Exchange 2003 in a production environment because,
being singular, they are incapable of providing failover.
Majority Node Set Quorums

From a server cluster perspective, a majority node set (MNS) quorum is a single quorum
resource. The data is stored by default on the local disk of each node in the cluster. The MNS
resource makes sure that the cluster configuration data, stored on the MNS resource, is
consistent across different disks. The MNS implementation provided in Windows Server 2003
uses a directory on each node's local disk to store the quorum data. If the configuration of the
cluster changes, that change is reflected across each node's local disk. The change is
considered committed, or made persistent, only if the change is made to: (Number of
nodes/2) + 1.
The MNS quorum makes sure that most nodes have an up-to-date copy of the data. The
Cluster service starts up and brings resources online only if a majority of the nodes that are
configured as part of the cluster are up and are running the Cluster service. If the MNS
quorum determines that a majority does not exist, the cluster is considered not to have
quorum, and the Cluster service waits in a restart loop until more nodes try to join. When a
majority or quorum of nodes is available, the Cluster service starts and brings the resources
online. Because the up-to-date configuration is written to a majority of the nodes, regardless
of node failures, the cluster always guarantees that it has the most current configuration at
startup.
576
If a cluster failure occurs, or if the cluster somehow enters a split-cluster scenario, all
partitions that do not contain a majority of nodes are taken offline. This ensures that if there is
a partition running that contains a majority of the nodes, it can safely start any resources that
are not running on that partition, because it is the only partition in the cluster that is running
resources.
Because of the differences in the way the shared disk quorum clusters behave compared to
MNS quorum clusters, you must consider carefully when deciding which model to use. For
example, if you have only two nodes in your cluster, the MNS model is not recommended. In
this instance, failure of one node leads to failure of the entire cluster, because a majority of
nodes is impossible.
Majority node set (MNS) quorums are available in Windows Server 2003 Enterprise Edition
and Windows Server 2003 Datacenter Edition clusters. The only benefit that MNS clusters
provide for Exchange clusters is to eliminate the need for a dedicated disk in the shared
storage array on which to store the quorum resource.
Cluster Resources
The Cluster service manages all resource objects using Resource Monitors and resource
DLLs. The Resource Monitor interface provides a standard communication interface that
enables the Cluster service to initiate resource management commands and obtain resource
status data. The Resource Monitor obtains actual command functions and data through
resource DLLs. The cluster Service uses resource DLLs to bring resources online, manage
their interaction with other resources in the cluster, and monitor their health.
To enable resource management, a resource DLL uses a few simple resource interfaces and
properties. Resource Monitor loads a particular resource DLL in its address space, as
privileged code running under the SYSTEM account. The SYSTEM account (that is,
LocalSystem), is a security principal account that represents the operating system. The
Cluster service, which runs under a user security context, uses the SYSTEM account to
perform security functions within the operating system.
When resources depend on the availability of other resources to function, these

dependencies can be defined by the resource DLL. When a resource is dependent on other
resources, the Cluster service brings the dependent resource online only after it brings the
resources on which it depends online in the correct sequence.
Resources are taken offline in a similar manner. The Cluster service takes resources offline
only after any dependent resources are taken offline. This prevents introducing circular
dependencies when loading resources.
Each resource DLL can also define the type of computer and device connection required by
the resource. For example, a disk resource may require ownership only by a node that is
physically connected to the disk device. Local restart policies and desired actions during
failover events can also be defined in the resource DLL.
577
Cluster Administration
Clusters are managed using Cluster Administrator. Cluster Administrator is a graphical
administrator's tool that enables the Cluster.exe command line tool to perform maintenance,
monitoring, and failover administration. Server clusters also provide an automation interface.
This interface can be used to create custom scripting tools for administering cluster
resources, nodes, and the cluster itself. Applications and administration tools, such as Cluster
Administrator, can access this interface using RPCs, whether the tool is running on a node in
the cluster or on an external computer.
Cluster Formation and Operation

When the Cluster service is installed and running on a server, the server can participate in a
cluster. Cluster operations reduce single points of failure and enable high availability of
clustered resources. The following sections briefly describe node behavior during cluster
creation and operation.
Creating a Cluster
Server clusters include a cluster installation utility that is used to install the cluster software on
a server and create a new cluster. To create a new cluster, the utility is run on the computer
selected as the first member of the cluster. This first step defines the new cluster by
establishing a cluster name, and creating the cluster database and initial cluster membership
list.
The next step in creating a cluster is to add the common data storage devices that will be
available to all members of the cluster. This establishes the new cluster with a single node
and its own local data storage devices and cluster common resources (generally disk or data
storage and connection media resources).
The final step in creating a cluster is to run the installation utility on each additional computer
that will be a member of the cluster. As each new node is added to the cluster, it automatically
receives a copy of the existing cluster database from the original member of the cluster.
When a node joins or forms a cluster, the Cluster service updates the node's private copy of
the configuration database.
Forming a Cluster
A server can form a cluster if it is running the Cluster service and cannot locate other nodes in
the cluster. To form the cluster, a node must be able to acquire exclusive ownership of the
quorum resource.
When a cluster is formed, the first node in the cluster contains the cluster configuration
database. As each additional node joins the cluster, it receives and maintains its own local
578
copy of the cluster configuration database. The quorum resource stores the most current
version of the configuration database as recovery logs. The logs contain node-independent
cluster configuration and state data.
During cluster operations, the Cluster service uses the quorum recovery logs to do the
following:
• Guarantee that only one set of active nodes is allowed to form a cluster
• Enable a node to form a cluster only if it can gain control of the quorum resource
• Allow a node to join or remain in an existing cluster only if it can communicate

with the node that controls the quorum resource
When a cluster is formed, each node in the cluster can be in one of three distinct states.
These states are recorded by Event Processor (described below) and replicated by Event
Log Manager to other nodes in the cluster. The three Cluster service states are as follows:
• Offline The node is not an active member of the cluster. The node and its
Cluster service might or might not be running.
• Online The node is an active member of the cluster. It adheres to cluster

database updates, contributes input into the quorum algorithm, maintains cluster
network and storage heartbeats, and can own and run resource groups.
• Paused The node is an active member of the cluster. The node adheres to
cluster database updates, contributes input into the quorum algorithm, and maintains
network and storage heartbeats, but it cannot accept resource groups. It can support
only those resource groups that it currently owns. The paused state enables
maintenance to be performed. Online and paused states are treated as equivalent
states by the majority of the server cluster components.
Joining a Cluster
To join an existing cluster, a server must be running the Cluster service, and it must
successfully locate another node in the cluster. After finding another node in the cluster, the
joining server must be authenticated for membership in the cluster and must receive a
replicated copy of the cluster configuration database.
The process of joining an existing cluster begins when Windows Service Control Manager
starts the Cluster service on the node. During the startup process, the Cluster service
configures and mounts the node's local data devices. It does not attempt to bring the
common cluster data devices online as nodes, because the existing cluster might be using
the devices.
To locate other nodes, a discovery process is started. When the node discovers any member
of the cluster, it performs an authentication sequence. The first cluster member authenticates
the new node and returns a status of success if the new node is successfully authenticated. If
579
authentication is not successful, as when a joining node is not recognized as a cluster

member or has an invalid account password, the request to join the cluster is denied.
After successful authentication, the first node online in the cluster checks the copy of the
configuration database of the joining node. If it is out-of-date, the cluster node sends the
joining server an updated copy of the database. After receiving the replicated database, the
node joining the cluster can use it to find shared resources and bring them online as needed.
Leaving a Cluster
A node can leave a cluster when it shuts down or when the Cluster service is stopped.
However, a node can also be evicted from a cluster when the node fails to perform cluster
operations (such as failure to commit an update to the cluster configuration database).
When a node leaves a cluster, as in a planned shutdown, it sends a ClusterExit message to

all other members of the cluster, notifying them that it is leaving. The node does not wait for
any responses and immediately proceeds to shut down resources and close all cluster
connections. Because the remaining nodes receive this exit message, they do not perform
the regroup process to reestablish cluster membership that occurs when a node
unexpectedly fails or network communications stop.
Failure Detection
Failure detection and prevention are key benefits provided by server clusters. When a node
or application in a cluster fails, server clusters can respond by restarting the failed application
or distributing the work from the failed system to remaining nodes in the cluster. Server
cluster failure detection and prevention include bi-directional failover, application failover,
parallel recovery, and automatic failback.
When the Cluster service detects failures of individual resources or an entire node, it
dynamically moves and restarts application, data, and file resources on an available, healthy
server in the cluster. This allows resources such as database, file shares, and applications to
remain highly available to users and to client applications.
Server clusters are designed with two different failure detection mechanisms:
• Heartbeats for detecting node failures Periodically, each node exchanges

user datagram protocol-based messages with other nodes in the cluster over the
private cluster network. These messages are referred to as the heartbeat. The
heartbeat exchange enables each node to check the availability of other nodes and
their resources. If a server fails to respond to a heartbeat exchange, the surviving
servers initiate failover processes, including ownership arbitration for resources and
applications owned by the failed server. Arbitration is performed using a challenge
and defense protocol. The node that appears to have failed is given a time window to
demonstrate, in any one of several ways, that it is still running correctly and can
580
communicate with the surviving nodes. If the node is unable to respond, it is removed
from the cluster.
Failure to respond to a heartbeat message is caused by several events, such as

computer failure, network interface failure, network failure, or even periods of unusually
high activity. Typically, when all nodes are communicating, the Configuration Database
Manager sends global configuration database updates to each node. When a heartbeat
exchange failure occurs, Log Manager saves configuration database changes to the
quorum resource. This ensures that remaining nodes can access the most recent cluster
configuration and local node registry data during the recovery processes.
The failure detection algorithm is very conservative. If the cause of the heartbeat
response failure is temporary, it is best to avoid the potential disruption a failover might
cause. However, there is no way to know whether the node will respond in another
millisecond, or if it suffered a catastrophic failure. Therefore, a failover is initiated after a
timeout period.
• Resource Monitor and resource DLLs for detecting resource

failures Failover Manager and Resource Monitor work together to detect and
recover from resource failures. Resource Monitors keep track of resource status by
using the resource DLLs to periodically poll resources. Polling involves two steps, a
cursory LooksAlive query and a longer, more definitive, IsAlive query. When
Resource Monitor detects a resource failure, it notifies Failover Manager and
continues to monitor the resource.
Failover Manager maintains resources and resource group status. It also performs
recovery when a resource fails and invokes Resource Monitors in response to user
actions or failures.
After a resource failure is detected, Failover Manager performs recovery actions that
include restarting a resource and its dependent resources, or moving the entire resource
group to another node. The recovery action that is taken is determined by resource and
resource group properties, in addition to node availability.
During failover, the resource group is treated as the unit of failover. This ensures that
resource dependencies are correctly recovered. When a resource recovers from a failure,
Resource Monitor notifies Failover Manager. Failover Manager then performs automatic
failback of the resource group, based on the configuration of the resource group failback
properties.
Exchange Virtual Servers

Exchange Virtual Server is a clustered Exchange installation. When Exchange is installed on
a Windows Server 2003 cluster, it is configured as an Exchange Virtual Server that can be
passed between cluster nodes transparently to Exchange clients.
581
When you install Exchange on a cluster node, the Exchange Setup program copies the
program files to the local disk of the cluster node. In a cluster with two nodes, such as Node A
and Node B, Setup copies the Exchange program files to the hard disk of Node A. You then
run Setup a second time to install the Exchange program files on the local hard disk of the
second node.
After the Exchange program files are copied to the hard disks of each node, you then
configure a resource group for the Exchange resources. As mentioned earlier, a resource
group is defined as a logical container that holds resources for an instance of Exchange
Virtual Server. This Exchange Virtual Server instance has many of the same resources that
physical Exchange servers have, such as:
• A network name
• An IP address
• Storage (SCSI or Fibre Channel)
After you create a minimum of the above Exchange Virtual Server resources, you must create
a System Attendant resource. System Attendant creates the additional resources that
compose an Exchange Virtual Server. These resources can be taken offline, which mimics
the stopping of the service, or brought online, which mimics the starting of the service. You
can also change the current resource owner (the cluster node). For example, you can
configure Node B to own and run this resource instead of Node A.
The System Attendant resource is always created manually. Other Exchange service-related
resources are automatically created after you create the System Attendant resource. On
completion, these changes are written to the Microsoft Active Directory® directory service
and an object for this Exchange-based server is listed in the Servers container of your
administrative group.
Note:
Exchange Server 2003 introduced several security-related changes that harden the
security model compared to that of Exchange 2000 Server. For example, when you
create an Exchange Server 2003 virtual server in a cluster environment, IMAP4 and
the POP3 cluster resources are not created by default. If you want to use these
services on a cluster, you must start the appropriate service on the cluster node, and
then manually create the resource. For more information, see Microsoft Knowledge
Base article 824127, "HOW TO: Create an IMAP4 or a POP3 Cluster Resource on an
Exchange Server 2003 Virtual Server."
An Exchange Virtual Server is a collection of Exchange resources. Each resource has

properties, such as resource dependencies, possible owners, and retry values. Each
resource in an Exchange Virtual Server represents a different component of Exchange.
582
Exchange Components in a Cluster

Components and virtual servers that run inside a Windows Server 2003 cluster support
active/active or active/passive functionality, or both. The Exchange-specific resources
available for Windows Server 2003 clusters are listed in the following table.
Exchange Server 2003 Components in a Server Cluster
Component Functionality Notes
Microsoft Exchange System Active/Active Multiple virtual servers per

Attendant service node in clusters of 2 or
fewer nodes. Clusters with
more than 2 nodes only
support active/passive
System Attendant
resources.
Microsoft Exchange Active/Active Maximum of four storage

Information Store service groups per node.
Message Transfer Agent Active/Passive One instance per cluster;

always owned by first
Exchange Virtual Server
created in a cluster.
Routing Engine Active/Active
POP3 Active/Active Multiple virtual servers per

node. Must be manually
created by administrator.
IMAP4 Active/Active Multiple virtual servers per

node. Must be manually
created by administrator.
SMTP Active/Active Multiple virtual servers per

node.
HTTP Active/Active Multiple virtual servers per

node.
Microsoft Search Active/Active
NNTP Not Supported Internet Information Service

(IIS) Network News Transfer
Protocol (NNTP) component
still required for installation
of Exchange.
583
Component Functionality Notes
Exchange Connector for Not Supported

Novell GroupWise
Exchange Connector for Not Supported

Lotus Notes
Microsoft Exchange Event Not Supported
Active/Active Clusters
Exchange 2003 supports active/active clustering for two-node clusters. Clusters with more
than two nodes must use active/passive clustering. In an active/active Exchange cluster,
there are multiple Exchange Virtual Servers that can be moved, with certain restrictions,
between the different nodes that belong to the cluster and can simultaneously run on one
node.
In active/active clusters, applications and resources can exist in multiple instances in a

cluster. Therefore, both nodes can actively service clients. In Exchange 2003 active/active
clusters, the number of Exchange Virtual Servers in a cluster is equal to or greater than the
number of physical nodes in the cluster. Active/active Exchange clusters can be created only
in clusters comprised of two or fewer nodes. If you have more than two nodes in your cluster,
you must use the active/passive cluster model.
In most cases, each Exchange Virtual Server in the cluster runs on a separate node. If
hardware fails or a node is taken offline, the other node detects the change and takes actions
according to configured failover policies. Generally, this means that the remaining node
assumes ownership of the Exchange Virtual Server that was running on the first node. In a
two-node cluster (for example, Node A and Node B), when Node A is offline, Node B
assumes ownership of the Exchange Virtual Server. Node B then has ownership of both
shared disk systems, both IP addresses, both network names, and all other Exchange
resources in the cluster. When Node A is back online, failback action might or might not be
taken, depending on the configured failback policies.
Although active/active clusters are supported, you should use active/passive Exchange
clusters for the following reasons:
• Scalability In an active/active Exchange cluster, each physical node cannot

have more than 1,900 simultaneous MAPI connections, or consistently use more
than 40 percent of the overall available CPU time.
• VM Fragmentation Active/active clusters are more prone to virtual memory

fragmentation than active/passive clusters and non-clustered Exchange servers. This
is because in the active/active cluster model, multiple instances of Extensible Storage
Engine (ESE) run inside the same STORE.EXE process.
584
• Performance When failover occurs in an active/active Exchange cluster, the

remaining node owns more than one Exchange Virtual Server. This causes
performance degradation for users of both Exchange Virtual Servers until the offline
node resumes its workload.
For more information about clustering with Windows Server 2003 and Exchange 2003, see
Using Clustering with Exchange 2003: An Example.
Active/Passive Clusters
In an active/passive cluster, clients connect to an Exchange Virtual Server that is currently
owned by one node of the cluster (for example, Node A). The node has control over the
shared disk system that contains the Exchange databases. If Node A experiences a hardware
failure or otherwise goes offline, Node B detects this failure and takes ownership of Exchange
Virtual Server and all its associated resources.
In the active/passive cluster model, applications run as a single instance in a cluster. This
means that one node typically sits idle (passive) until a failover occurs. In the context of
Exchange 2003 clusters, active/passive clustering indicates that the number of Exchange
Virtual Servers in the cluster is fewer than the number of physical nodes in the cluster. An
example of the active/passive cluster model is shown in the following figure.
Four-node active/passive Exchange 2003 server cluster

585
Active/passive is the strongly preferred clustering model for Exchange 2003. Active/passive
cluster configurations are highly scaleable and have less administrative overhead than
active/active clusters for several reasons:
• Active/active clusters are limited to 1,900 simultaneous MAPI client connections

per node.
• Active/active clusters must be continuously monitored to make sure that the

STORE.EXE process does not exceed 40 percent of the overall available CPU time
on each node.
• Active/active clusters are more prone to virtual memory fragmentation because

multiple instances of ESE run in the same STORE.EXE process.
Active/passive Exchange clusters, regardless of their size, must include at least one passive
node. In addition, at any given time, each node must only run one Exchange Virtual Server.
Resource Dependencies
As shown in the figure below, Exchange-related resources are directly dependant on the
System Attendant resource. The System Attendant resource is in turn dependent on the
Physical Disk, and Network Name resources, and the Network Name resource is dependent
on the IP Address resource. In the case where an Exchange Virtual Server includes multiple
Physical Disk resources, the System Attendant resource must have a dependency on all of
them.
Microsoft Exchange System Attendant Service

The default dependencies shown in the following figure are created when Microsoft Exchange
System Attendant service is created. System Attendant is the fundamental resource that
controls the creation and deletion of all resources in Exchange Virtual Server.
586
Exchange resource dependencies in Exchange Virtual Server
These resources are created when you create the System Attendant resource. To delete the
server and its object from Active Directory, you remove Exchange Virtual Server using Cluster
Administrator. The IsAlive call to System Attendant checks Service Control Manager to obtain
the immediate state of System Attendant.
Microsoft Exchange Information Store Service

When the Microsoft Exchange Information Store service is brought online, the service
(STORE.exe) starts and begins to mount the storage groups. When all the storage groups
are mounted, and the store has processed the existing transaction logs, the resource is
considered to be online. The IsAlive call to the Microsoft Exchange Information Store service
sends an RPC call to the STORE.exe process. On the store process side, the check only
verifies that the virtual server name exists in the list of active virtual servers.
Message Transfer Agent

The message transfer agent (MTA) resource is an active/passive resource. There can be only
one MTA per cluster. The MTA is created in the first Exchange Virtual Server in a cluster and
cannot be moved to a different Exchange Virtual Server. For this reason, the first Exchange
Virtual Server that you create in a cluster is also the last Exchange Virtual Server that can be
removed from the cluster.
Although the MTA is an active/passive resource, it serves all virtual servers in the cluster
while it is online. The IsAlive call to the message transfer agent checks Service Control
Manager to obtain the immediate state of the MTA.
587
Protocols
The IsAlive call acts the same way for all protocols. EXRES.DLL opens a TCP port to the
protocol by using the bindings that are provided from the Internet Information Service (IIS)
metabase. It waits for a response in the form of a banner. If the start of the banner matches
the expected value, the resource is considered to be online. If the banner is not returned
before the time-out period, the Cluster service determines that the protocol virtual server is
unavailable, and the IsAlive call is unsuccessful.
None of the protocols may be set to reject all connections from all servers, or the protocol
virtual server will reject IsAlive calls from itself. Because of this, each protocol virtual server
must accept connections from its own IP address. For the HTTP protocol, EXRES.DLL sends
a WebDAV Track command to obtain a response.
When an Exchange Virtual Server is taken offline, all instances of the SMTP protocol virtual
server on the node are briefly stopped and restarted to make sure that the store driver is
correctly registered. This means that the SMTP resources of all Exchange Virtual Servers on
the node quickly go offline and restart. The SMTP resource does not restart automatically if
the do not restart option is selected in its properties.
Microsoft Search
The MSSearch resource provides content indexing for Exchange Virtual Server. The IsAlive
call to the MSSearch process returns a pointer to the data structure for the database that is
being indexed. If the pointer is valid, the resource is determined to be working correctly.
To re-create the MSSearch resource after it is deleted, you must delete and then re-create
the Microsoft Exchange Information Store service resource for that Exchange Virtual Server.
For more information, see Microsoft Knowledge Base article 830189, "Exchange Server 2003
computer cannot bring the Microsoft Search resource online."
Exchange Cluster Interaction

Exchange 2003 is cluster-aware and provides its own cluster resource DLL, named
EXRES.DLL, for communication and interaction with the Windows Cluster service. The
Windows Cluster service communicates through Resource Monitor to EXRES.DLL, and
EXRES.DLL then communicates with the Exchange components. EXRES.DLL translates the
cluster actions into actions for Exchange-related services. EXRES.DLL also monitors the
stopping of these resources and notifies the Cluster service if the operation is unsuccessful.
The following figure illustrates the relationship between EXRES.DLL and the Cluster service.
588
ExRes.dll interaction with Windows Cluster Service
In a cluster, the Cluster service is responsible for starting and stopping Exchange services
through EXRES.DLL. Because of this, an administrator should not stop a service from the
command-line, the Windows Services snap-in, a Resource Kit tool, or a third-party
application. When you stop a service outside of the Cluster, the IsAlive call to that service
fails, causing the Cluster service to attempt a restart of the stopped service. The IsAlive
function returns the last value that was pooled from the resource health-monitoring thread.
The LooksAlive function has the same implementation as IsAlive. The LooksAlive function is
not called, because the EXRES.DLL provides resource-failure event handles to the cluster
Resource Monitor that indicates when a resource fails. The health-monitoring thread checks
resources every ten seconds. This resource check cannot be configured. EXCLUADM.DLL
provides the interface associated with Exchange and cluster-specific wizards.
ExchangeOpen/ExchangeClose Functions
The ExchangeOpen and ExchangeClose functions are called whenever the Exchange
resources are moved to the current node. Inside the ExchangeOpen functions, memory is
initialized or allocated for the basic information of the resource. These functions also handle
the loading and unloading of DLL files that are used by the Resource DLL. This process is
controlled by reference counters.
589
ExchangeOnline and ExchangeOffline

Functions
The ExchangeOnline and ExchangeOffline functions create new OnlineWrapperThread and
OfflineWrapperThread worker threads and immediately return an ERROR_IO_PENDING to
the cluster Resource Monitor. When the wrapper thread returns a failure to Resource Monitor,
Resource Monitor tries to restart the resource two additional times. During these restart
attempts, the ExchangeOnline function determines if the previous online/offline thread is
returned. If the online/offline thread is not returned, the ExchangeOnline function restarts.
For the OfflineWrapperThread, if the ExchangeOffline thread does not return in the
PendingTimeOut limit for the Store, System Attendant, and MTA resources, Resource Monitor
ends the corresponding process.
To prevent situations in which RPCs hang, these two worker threads create the real
online/offline thread. The wrapper threads act as monitors for the online/offline thread and
use timers to monitor the operation of the online/offline thread. If the online/offline thread
does not return in the PendingTimeOut value that was set in Cluster Administrator, the
wrapper thread determines that the operation is unsuccessful, and sets the resource's state
as failed. It then returns an error. The only exceptions to this behavior are for upgrade
operations or for store resource online operations. In these two cases, the wrapper thread
waits for an upgrade to complete or for a store resource to go online without timing out.
The ExchangeOnlineThread and ExchangeOfflineThread service the following Exchange

resources:
• Micrsoft Exchange System Attendant service, Microsoft Exchange

Information Store service, and Routing Each of these resources starts the
service (if it is not already started), and then makes RPC calls to each of the
services, instructing them to start or stop the corresponding Exchange Virtual Server.
• Protocol Resources Protocol resources set the command bit in the IIS
metabase, and then start the service, if it has not already started. The corresponding
service picks up the command and starts or stops the virtual server. The only
exception to this is the SMTP virtual server. In this case, the whole SMTP service
must be stopped when a virtual server instance is taken offline. The IsAlive function
checks for other virtual servers running on the same physical computer, detects that
the underlying SMTP service is stopped, and then restarts the virtual server.
ExchangeIsAlive and ExchangeLooksAlive

The ExchangeOnline function returns an event handle to Resource Monitor, and Resource
Monitor then stops calling the ExchangeLooksAlive function. Instead, the Resource Monitor
calls the ExchangeIsAlive function at intervals set in the Cluster Administrator Looks Alive
polling interval. Whenever a resource is online, EXRES.DLL creates two threads to monitor
590
the status of that resource. The first thread, named ExchangeIsAliveMonitor, checks the
status of the resource every ten seconds by waking the second thread, named
ExchangeCheckIsAliveWrapper. ExchangeCheckIsAliveWrapper performs the actual IsAlive
checking. If the ExchangeCheckIsAliveWrapper thread does not return in the
PendingTimeOut limit, or if the IsAlive check is unsuccessful, the ExchangeIsAliveMonitor
thread signals a failure event for the particular resource to Resource Monitor. The
ExchangeIsAlive function returns the status of the last IsAlive check.
ExchangeTerminate
This function ends the existing ExchangeIsAliveMonitor thread. For the Exchange store,
System Attendant, and MTA resources, it also performs the corresponding offline procedure
to make sure that the database is dismounted. If the offline procedure does not complete
successfully in the PendingTimeOut limit, EXRES.DLL also terminates the corresponding
process.
Creating Resources
The user creates a resource first, and then creates a call to EXCLUADM.DLL, prompting for
information. EXCLUADM.DLL obtains the required information for the resource and passes it
to the Cluster service. Resource Monitor creates a call to the ExchangeResourceControl
function in EXRES.DLL. This call contains the information that was passed from
EXCLUADM.DLL and Clusctl_Resource_Set_Private_Properties as the control code.
ExchangeSetPrivateResProperties is used to handle this control code. It first saves the
information to the cluster database under the Parameters registry key for that resource, and
then makes a call to EXSETDATA.DLL to have EXSETDATA.DLL create objects in
Acitve Directory. In some cases, a problem might occur and some configuration information
might be modified in Exchange System Manager, without synchronizing the changes with the
cluster database.
Cluster-Specific Configurations
The following sections describe configuration changes that must be made to support
operations of certain components when running in an Exchange cluster. When Exchange is
installed in a clustered environment, you must perform some common Exchange tasks
differently than you would for an Exchange server that is installed in a non-clustered
environment.
591
Exchange MTA
By default, an Exchange 2003 server monitors the MTA service. In a cluster environment,
MTA runs only on one of the physical nodes (computers). As a result, the monitoring process
will report that any nodes not running the MTA service are in an error state. This, in turn, can
cause problems if Exchange 2003 is installed in a cluster with two or more Exchange Virtual
Servers.
To prevent the monitoring process from incorrectly reporting that Exchange Virtual Servers
that are not running the MTA service are in an error state, you should disable MTA monitoring
on the second Exchange Virtual Server (and if applicable, any other additional Exchange
Virtual Servers) of a cluster. For detailed steps, see How to Disable MTA Monitoring on an
Exchange Virtual Server.
Note:
You do not need to disable MTA monitoring on the first Exchange Virtual Server of a
cluster.
IIS SMTP Logging

IIS SMTP protocol virtual servers create and populate log files that are used to gather
statistical data on server usage. SMTP logging is not enabled by default, because it reduces
Exchange performance. When enabled, IIS creates log files on the system drive of the local
computer (such as C:\Windows\System32\Logfiles, where C is the drive letter for your system
drive).
To reliably configure IIS SMTP logging, you must specify a folder on a shared disk. For
detailed instructions, see How to Enable SMTP Logging and Log the Files to a Shared Disk.
AntiAffinityClassNames
One of the limitations of Windows 2000-based server clusters is that they have no
mechanism for a conditional failover. For example, you cannot configure an Exchange Virtual
Server to move to one node when one failure occurs and to a different node when another
failure occurs. Nor can you configure an Exchange Virtual Server to fail over to a second
node in the event that the first node is too busy. In Windows Server 2003 clusters, this
limitation is addressed with a new cluster group property named AntiAffinityClassNames. The
value for this property is any arbitrary string. However, this string is often program-specific.
For example, Exchange 2003 sets this value to Microsoft Exchange Virtual Server.
AntiAffinityClassNames are used to designate a node as a possible owner for a particular

resource group in a cluster containing three or more nodes. In a Windows Server 2003
cluster, if a resource failure occurs that affects the resource group, Failover Manager checks
the value for AntiAffinityClassNames. For example, when an Exchange Virtual Server
592
resource fails, the cluster failover manager determines if resource groups on any one of the
other nodes, designated as possible owners of the Exchange Virtual Server, have Microsoft
Exchange Virtual Server set as the value for the AntiAffinityClassNames property. Only
nodes that currently contain an Exchange Virtual Server have this value set. Therefore, a
node without this value is the best possible destination for the group with the failed resource.
The following scenarios demonstrate how the AntiAffinityClassNames property can be used:
• The property can be used in an N+1 Exchange server cluster. In this case,
Exchange should set up each group that supports a partition with the
AntiAffinityClassNames property set to an Exchange-specific value (the same value
for each group). If there is a failure, the failover manager can attempt to keep the
partitions apart by selecting nodes that do not contain groups with the same
AntiAffinityClassNames value of Exchange Virtual Server.
• The property can be used in a server consolidation in which there are multiple
programs that should be kept apart. In these cases, the groups that represent the
various programs should be manually modified with the same value in the
AntiAffinityClassNames property.
This property can only be configured using the CLUSTER.EXE command-line tool. An
example of the proper syntax for the example that is listed in the first preceding scenario is:
cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual

Server"
This command creates the following registry key:
Location HKLM\Cluster\Groups\<Guid>\
Value AntiAffinityClassNames
Type REG_MULTI_SZ
Value Data Microsoft Exchange Virtual Server
After this property is set, failover and failback policies are configured using the Best Possible
option in Cluster Administrator, instead of specifying specific nodes for a policy. For more
information, see Microsoft Knowledge Base article 299631, "Failover Behavior on Clusters of
Three or More Nodes."
MAPI Public Stores

Prior to Service Pack 1, Exchange 2003 clusters can only accommodate one public MAPI
information store, also referred to as a public folder database, per cluster. This design
prevents problems if the cluster fails over to another server in an active/active cluster.
Because Exchange 2003 must run in an active/passive configuration whenever there are
593
more than two nodes present in the cluster, you cannot encounter a scenario in which a
single Store.exe process must cope with multiple public MAPI information stores from the
same TLH. Therefore, with Exchange 2003 Service Pack 1, the existing public MAPI
information store limitation in the cluster is removed. Installations running SP1 or later are
restricted to one public MAPI information store per Exchange Virtual Server (the same
restriction that is imposed on stand-alone Exchange 2003 servers).
Eseutil
You must give special consideration when you run the Eseutil database integrity utility with
the /CC switch. This switch is used to perform a hard recovery of an Exchange information
store. Hard recovery is the process through which you apply transaction logs and database
patch files to a database that has been restored from online backup. For more information,
see Microsoft Knowledge Base article 266689, "XADM: The 'ESEUTIL /CC' Command Does
Not Work on Cluster Server."
Installing Updates
Before installing any updates on your Exchange cluster nodes, read the README file that is
included with the service pack, hotfix, or update. In most cases, the passive node of the
cluster is updated first. Exchange Virtual Servers are then moved to the passive node, and
then the other node is updated. You should never install any update on more than one node
at a time.
How to Disable MTA Monitoring on an

Exchange Virtual Server
By default, an Exchange 2003 server monitors the MTA service. In a cluster environment,
MTA runs only on one of the physical nodes (computers). To prevent the monitoring process
from incorrectly reporting that Exchange Virtual Servers that are not running the MTA service
are in an error state, disable MTA monitoring on the second Exchange Virtual Server (and if
applicable, any other additional Exchange Virtual Servers) of a cluster. You do not have to
disable MTA monitoring on the first Exchange Virtual Server of a cluster. This procedure
describes how to disable MTA monitoring on an Exchange Virtual Server.
Before You Begin

Before you start managing your Exchange cluster, you may want to review what constitutes
an Exchange Virtual Server and its associated Exchange resources. You may also want to
594
become more familiar with Cluster Administrator—the primary tool used to configure and
manage clusters.
Note:
Before performing the cluster administration tasks outlined in this chapter, you must
be familiar with the clustering concepts described in "Checklist: Preparation for
installing a cluster" in the Microsoft Windows Server™ 2003 Enterprise Edition Online
Help and in the Windows Server 2003 Technical Reference.
Also, make sure that you are familiar with "Using Server Clustering" in Planning an Exchange
Server 2003 Messaging System and with "Deploying Exchange 2003 in a Cluster" in the
Exchange Server 2003 Deployment Guide.
Procedure
To disable MTA monitoring on an Exchange Virtual Server
1. In Exchange System Manager, in the console tree, expand Servers, right-
click the appropriate Exchange Virtual Server, and then click Properties.
2. In the <Server Name> Properties dialog box, click the Monitoring tab.
3. On the Monitoring tab, select Default Microsoft Exchange Services from

the list of services, and then click Details.
4. In the Default Microsoft Exchange Services dialog box, select Microsoft

Exchange MTA Stacks, and then click Remove.
5. Click OK two times.
How to Enable SMTP Logging and Log the

Files to a Shared Disk
If you want to gather statistical data about server usage, you can enable logging of the SMTP
resource. However, be aware that enabling SMTP logging reduces Exchange performance.
Unless you are troubleshooting or need statistical data, disable logging, which is the default
setting. This procedure describes how to enable SMTP logging and log the files to a shared
disk.
595
Before You Begin

When enabled, Internet Information Services (IIS) creates SMTP log files on the system drive
of the local computer (for example, C:\Winnt\System32\Logfiles, where C is the location of
your Windows Server 2003 or Windows 2000 installation). To reliably configure SMTP logging
in a clustered environment, you must change the default location of the log files (that is, the
local computer) to a folder on a shared disk.
Procedure
To enable SMTP logging and log the files to a shared disk
1. In Exchange System Manager, in the console tree, expand Servers, and then
expand the server on which you want to enable IIS logging for SMTP.
2. In the console tree, expand Protocols, and then expand SMTP.
3. In the console tree, right-click Default SMTP Virtual Server, and then click
Properties.
4. In the Default SMTP Virtual Server Properties dialog box, on the General
tab, click Enable logging, and then click Properties.
5. In the Extended Logging Properties dialog box, on the General Properties

tab, in Log file directory, change the SMTP log file location to a folder on a
shared disk.
6. Click OK two times.
How to Create an HTTP Virtual Server in

When you create an Exchange Virtual Server, during the creation of the Exchange System
Attendant resource, Exchange creates an HTTP virtual server resource.
This topic explains how to use Exchange System Manager to create an HTTP virtual server.
Before You Begin

The following steps must be repeated for each Exchange Virtual Server in the cluster.
596
Procedure
To create an HTTP virtual server in Exchange System Manager
1. Open Exchange System Manager.
2. In the console tree, expand Servers, expand the server that you want to
configure as a back-end server, and then expand Protocols.
3. Right-click HTTP, point to New, and then click HTTP Virtual Server.
4. In Properties, in the Name box, type the name of your front-end server.
5. Next to the IP Address list, click Advanced.
6. In Advanced, under Identities, select the default entry, and then click
Modify.
7. In Identification, in the IP address list, select the IP address of this

Exchange Virtual Server (the back-end server). This IP address must match the
IP address resource value you previously configured for the back-end server.
The Identification dialog box
8. In the Host name box, type the host header of the front-end server. This is
the name by which the clients access the front-end server. The host header for
the Exchange Virtual Server must map to the host header on the front-end
server.
Note:
Client requests to the front-end server use a specific host, such as
http://mail.contoso.com. A virtual server on the front-end must have the
"mail.contoso.com" host header configured. The front-end server then
proxies the request to the back-end server, which must also have the host
header configured on a virtual server.
597
9. Verify that TCP port is set to 80, and then click OK.
10. In Advanced, if you want to add an additional identity, click Add, and
perform Steps 6 through 8 again.
Note:
Consider adding several identities to the virtual server that list all the ways
that a user might access the front-end server. For example, if a front-end
server is used both internally and externally, consider listing both a host
name and a fully qualified domain name, such as "mail" for internal access
and "mail.contoso.com" for external access.
11. In Advanced, click OK twice to create the new HTTP virtual server.
How to Create Virtual Directories for an

Exchange Virtual Server in a Windows
Server Cluster
When you create an Exchange Virtual Server, during the creation of the Exchange System
Attendant resource, Exchange creates an HTTP virtual server resource. This topic explains
how to create virtual directories for an Exchange Virtual Server in a Windows Server cluster.
Before you can create a virtual directory, you must create an HTTP virtual server in Exchange
System Manager. For detailed instructions, see How to Create an HTTP Virtual Server in
Exchange System Manager. After you create the HTTP virtual server, you must add virtual
directories to the back-end server(s) that match the virtual directories configured on the front-
end server. A typical Exchange installation contains virtual directories called Exchange and
Public. In Exchange System Manager, virtual directories of HTTP virtual servers appear as
child objects of the HTTP virtual server.
Before You Begin

For any virtual directories that point to mailboxes, ensure that the SMTP domain selected on
the virtual directory Properties matches the SMTP domain of users who will be using that
front-end server. If the correct domain is not selected, users of that domain will not be able to
use that virtual server to log on. The list of domains is compiled from the domains of the
SMTP addresses in the Exchange organization's recipient policies. If you have more than one
recipient policy for the same domain, you will see duplicates. In this case, it does not matter
which one you select.
598
Procedure
To create virtual directories for an Exchange Virtual Server in a Windows Server
cluster
1. Open Exchange System Manager
2. In the console tree, expand Servers, expand the server that you want to
configure as a back-end server, expand Protocols, and then expand HTTP.
3. Right-click <HTTP Virtual Server Name>, point to New, and then click
Virtual Directory.
4. In Properties, in the Name box, type Exchange.
5. Under Exchange Path, the Mailboxes for SMTP domain option is selected
by default. Keep this setting, because users use the Exchange virtual directory
to access their Exchange mailboxes. Click OK to create the first virtual directory.
6. In the console tree, right-click <HTTP Virtual Server Name> again, point to
New, and then click Virtual Directory.
7. In Properties, in the Name box, type Public.
8. Under Exchange Path, click Public folder, and then click Modify.
9. In Public Folder Selection, double-click Public Folders. After a few

seconds, Exchange resolves the public folder's server name and appends it to
the name of the Public Folders container.
The Public Folder Selection dialog box

599
10. Click OK to close the Public Folder Selection dialog box.
11. In Properties, click OK.
12. If there are additional virtual directories configured on your front-end server,
you must also create those virtual directories. To create additional virtual
directories, repeat Steps 5 through 10 for each virtual directory.

For more information about creating virtual directories, see "Configure the Server's Virtual
Directory" in Exchange 2003 Help.
How to Create an HTTP Virtual Server

Resource for an Exchange Virtual Server in
a Windows Server Cluster
For the Cluster service to manage each HTTP virtual server, you must create a new HTTP
server resource for each HTTP virtual server. This topic explains how to create an HTTP
virtual server resource for an Exchange Virtual Server in a Windows Server cluster.
600
Before You Begin

You must perform the following steps for each Exchange Virtual Server to which you have
added a new HTTP virtual server.
Procedure
To create an HTTP virtual server resource for an Exchange Virtual Server in a
Windows Server cluster
1. Open Cluster Administrator.
2. Right-click the Exchange Virtual Server, point to New, and then click
Resource.
3. The New Resource Wizard starts. In the Name box, type Exchange HTTP
Virtual Server - (<EVSName>), where EVSName is the name of the front-end
server.
4. In the Resource type list, click Microsoft Exchange HTTP Server

Instance. Verify that the Group list contains the name of your Exchange Virtual
Server, and then click Next.
5. In Possible Owners, under Possible owners, verify that all nodes are
displayed, and then click Next.
6. In Dependencies, add the Exchange System Attendant resource to the

Resource dependencies box, and then click Next.
7. In Virtual Server Instance, in the Server Instance list, select the newly
created HTTP virtual server for the resource, and then click Finish.
8. In Cluster Administrator, right-click the HTTP virtual server instances you just
created, and then click Bring Online.
Copyright
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on
the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.
601
This White Paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync,
ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN,
Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT, and Windows Server System are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.

Exchange 2003 Technical Reference

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exchange 2003 Technical Reference

Uploaded by

Copyright:

Available Formats

Microsoft Exchange Server 2003 Technical

Published: December 12, 2006

Author: Exchange Server Documentation Team

Comments? Send feedback to exchdocs@microsoft.com.

Technical Reference Guide for Exchange Server 2003.......................................... ................16

Introduction to the Exchange 2003 Technical Reference Guide.............................................16

Exchange Server 2003 Technical Overview................................................. ..........................19

Exchange Server 2003 as a Message Handling System............................................. ...........20

Directory Integration.......................................................................................... .....................23

The Message Transport.................................................................................................... ......27

The Exchange Message Store...................................................................... .........................30

User Agents in an Exchange Server 2003 Organization.................................................... .....32

Exchange Server 2003 Services Dependencies.................................................................. ...33

Understanding Windows Services Architecture................................................... ...................35

Operating System Services.................................................................................. ..................47

Internet Information Services........................................................................................... .......51

Additional Exchange Server 2003 Services..................................................................... .......65

How to Stop All Exchange Server 2003 Services on a Server........................................ ........69

Exchange Server 2003 and Active Directory.................................................. ........................69

Directory Integration and Exchange Server 2003..................................................... ..............71

Directory Service Proxy......................................................................................... .................93

SMTP Categorizer............................................................................................... .................101

Recipient Update Service and Exchange Server 2003............................................... ..........104

Metabase Update Service............................................................................. .......................106

Exchange System Manager Architecture........................................................................ ......107

Integration with Microsoft Management Console.......................................................... ........108

Managing Configuration Information in Active Directory....................................... ................127

Managing Exchange Store Resources........................................................... ......................138

How to Connect to a Specific Exchange Server in Exchange System Manager...................149

Integration with Windows Management Instrumentation................................ ......................149

Service Configuration in Exchange System Manager....................................................... ....153

Message Routing Architecture...................................................................................... ........155

Exchange Server 2003 Message Routing Topology............................................ .................156

Exchange Server 2003 Message Handling.......................................................................... .160

Exchange Server 2003 Message Routing..................................................... .......................167

Backward Compatibility with Exchange Server 5.5........................................................... ....212

SMTP Transport Architecture............................................................................................ ....215

SMTP Service Design.......................................................................................................... .216

The Advanced Queuing Engine.............................................................................. ..............240

SMTP Transport Components......................................................................... .....................250

SMTP Service Store Drivers........................................................................................ .........278

SMTP Protocol Extensions..................................................................................... ..............293

Protocol Logging, Event Logging, and Message Tracking......................................... ...........305

How to Enable Message Tracking in Exchange System Manager..................................... ...310

X.400 Transport Architecture...................................................................... ..........................311

Exchange MTA in Exchange Server 2003 Architecture........................................................ .313

How to Wipe the MTA Database................................................................................. ..........345

How to Replay DAT Files After an MTA Database Wipe....................................... ................346

MTA Transport Stacks and X.400 Connectors....................................................... ...............354

Connecting Routing Groups Using X.400 Connectors...................................................... ....389

Exchange MTA in a Mixed-Mode Organization........................................................... ..........397

Gateway Messaging Connectors Architecture......................................................... .............402

EDK Connector Architecture.......................................................................................... .......403

How to Open a Connector Mailbox Using Mdbvu32.exe................................ ......................427

Connector for Lotus Notes Architecture..................................................................... ...........428

Connector for Novell GroupWise Architecture................................................... ...................442

Calendar Connector Architecture....................................................................................... ...459

Protocol Virtual Servers in Exchange Server 2003.................................................... ...........480

IIS Integration.................................................................................................... ...................481

MAPI and RPC over HTTP....................................................................................... ............486

Internet Protocol Details................................................................................. ......................488

Exchange ActiveSync and Exchange 2003................................................... .......................502

Outlook Mobile Access and Exchange 2003........................................................................ .509