Microsoft Exchange Server 2003 Technical Reference Guide

Transcription

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
Technical Reference Guide for Exchange Server 2003.............................................................17
Introduction to the Exchange 2003 Technical Reference Guide ...............................................17
What Will You Learn from This Guide? ...................................................................................17
Who Should Read This Guide? ................................................................................................19
What Should You Read First? ..................................................................................................19
Exchange Server 2003 Technical Overview ...............................................................................20
Exchange Server 2003 as a Message Handling System...........................................................21
General Components of a Message Handling System...........................................................21
The Message Handling System in the Network Infrastructure...............................................22
Directory Integration......................................................................................................................24
Recipient Objects in the Directory............................................................................................24
Configuration Information in the Directory ...............................................................................25
Exchange Classes and Attributes in Active Directory.............................................................26
Directory Access Architecture ..................................................................................................27
The Message Transport ...............................................................................................................27
Message Routing Architecture .................................................................................................28
Message Routing with Routing Groups ...................................................................................28
The Exchange Message Store.....................................................................................................31
Exchange Server 2003 Database Technology........................................................................31
Stores and Storage Groups......................................................................................................31
User Agents in an Exchange Server 2003 Organization ...........................................................33
Exchange Server 2003 Services Dependencies ........................................................................34
Understanding Windows Services Architecture..........................................................................35
Responsibilities of Service Control Manager...........................................................................36
Exchange Services and the LocalSystem Account.................................................................41
Examining the Services Database ...........................................................................................43
Operating System Services..........................................................................................................48
Internet Information Services .......................................................................................................52
Core Exchange Server 2003 Services ........................................................................................57
Additional Exchange Server 2003 Services................................................................................66
How to Stop All Exchange Server 2003 Services on a Server..................................................69
Before You Begin ......................................................................................................................69
Procedure...................................................................................................................................70
Exchange Server 2003 and Active Directory ..............................................................................70
Directory Integration and Exchange Server 2003.......................................................................71
Exchange Classes and Attributes in Active Directory.............................................................72
Directory Service Access ..........................................................................................................74
LDAP Connection Load-Balancing and Failover.....................................................................76
DSAccess Topology Discovery ................................................................................................78
Initial Discovery and Ongoing Rediscovery.............................................................................79
Hard-Coding DSAccess Servers..............................................................................................82
DSAccess Profiles.....................................................................................................................83
Specifying the Configuration Domain Controller .....................................................................85
How DSAccess Assigns Server Roles.....................................................................................86
Directory Access Cache............................................................................................................89
Preloading DSAccess ...............................................................................................................92
Directory Service Proxy ................................................................................................................94
DSProxy Operations..................................................................................................................95
Exchange Server 2003 Referral Behavior before Service Pack 2.........................................95
Exchange Server 2003 Service Pack 2 Referral Behavior.....................................................97
SMTP Categorizer ......................................................................................................................102
Message Categorization and Active Directory ......................................................................103
Recipient Update Service and Exchange Server 2003 ............................................................105
Updating Recipient Objects ....................................................................................................105
Metabase Update Service ..........................................................................................................107
DS2MB Operations .................................................................................................................108
Exchange System Manager Architecture..................................................................................108
Integration with Microsoft Management Console .....................................................................109
Exchange Server 2003 Snap-ins and Snap-in Extensions...................................................115
Building Custom Exchange Management Consoles.............................................................127
Managing Configuration Information in Active Directory..........................................................128
Binding to a Domain Controller...............................................................................................129
The Exchange Organization in the Configuration Directory Partition ..................................131
Exchange System Manager and Permission Settings..........................................................133
Enabling the Security Tab for Objects in Exchange System Manager................................134
Permissions Inheritance and Exchange System Manager...................................................136
Managing Exchange Store Resources......................................................................................139
MAPI-Based Communication .................................................................................................140
Information Obtained Through the IExchangeManageStore Interface................................140
Exchange System Manager and MAPI-Based Clients .........................................................142
DAV-Based Communication ...................................................................................................142
DAV-Based Communication and HTTP Virtual Directories..................................................142
Exchange System Manager and the Exadmin Virtual Directory ..........................................144
Connecting to a Specific Exchange Server ...........................................................................146
Exchange System Manager and the Default Web Site ........................................................147
The Exadmin Virtual Directory and SSL Encryption .............................................................148
How to Display All Information Obtained for a Mailbox Store or Public Folder Store ............149
Procedure.................................................................................................................................149
How to Connect to a Specific Exchange Server in Exchange System Manager ...................150
Procedure.................................................................................................................................150
Integration with Windows Management Instrumentation .........................................................150
Service Configuration in Exchange System Manager..............................................................153
Message Routing Architecture...................................................................................................155
Exchange Server 2003 Message Routing Topology................................................................157
Exchange Server 2003 Message Handling...............................................................................160
Exchange Server 2003 Message Routing.................................................................................167
Message Routes and Link State Table..................................................................................168
Initializing the Link State Table...............................................................................................168
Routing Engine and Exchange Routing Engine Service ......................................................169
Examining the Link State Table..............................................................................................170
Exchange Routing Path Selection..........................................................................................186
Routing Path Selection Process.............................................................................................189
Dijkstra's Shortest-Path Algorithm..........................................................................................190
Message Transfer Load Balancing ........................................................................................193
Load Balancing between Routing Groups .............................................................................194
Load Balancing between Connectors and External Systems ..............................................195
Message Rerouting Based on Link State Information ..........................................................197
Message Rerouting .................................................................................................................197
Rerouting and Address Spaces..............................................................................................198
Connector Recovery................................................................................................................199
Rerouting and Activation Schedules ......................................................................................199
Link State Propagation ...............................................................................................................200
Link State Algorithm ................................................................................................................200
An LSA Example .....................................................................................................................203
Link State Changes and Link State Propagation ..................................................................208
Changing the Routing Group Master .....................................................................................209
Conflicts Between Routing Group Masters............................................................................210
Backward Compatibility with Exchange Server 5.5 ..................................................................211
Generating the GWART..........................................................................................................211
Routing Issues in Mixed Mode ...............................................................................................211
Topology Updates ...................................................................................................................212
Broken Link State Propagation...............................................................................................212
SMTP Transport Architecture.....................................................................................................214
SMTP Service Design.................................................................................................................215
Internet Information Services (IIS) Integration.......................................................................216
Asynchronous Thread Execution ...........................................................................................216
Handling Incoming SMTP Connections .................................................................................217
Limiting the Number of SMTP Threads .................................................................................219
Component Object Model-Based SMTP Extensions ............................................................220
Events in the SMTP Transport Subsystem............................................................................221
Event Dispatcher and Event Notifications .............................................................................222
Administrative Interfaces.........................................................................................................223
Configuration Settings and Event Bindings ...........................................................................224
Configuration Information in Active Directory........................................................................225
SMTP Configuration Settings in the Metabase .....................................................................229
SMTP Configuration Keys.......................................................................................................229
Direct Metabase Editing..........................................................................................................232
Local Domain Registrations....................................................................................................232
Event Sink Registrations.........................................................................................................232
Server Extension Objects .......................................................................................................235
How to Enable the Enable Direct Metabase Edit Feature in IIS Manager..............................236
Before You Begin ....................................................................................................................237
Procedure.................................................................................................................................237
The Advanced Queuing Engine .................................................................................................239
Events Triggered by the Advanced Queuing Engine............................................................239
Message Queues in the Advanced Queuing Engine ............................................................243
Limiting the Number of Messages in Message Queues.......................................................248
SMTP Transport Components ...................................................................................................249
Exchange Categorizer.............................................................................................................251
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..................................................................................................286
Inbound Message Transfer.....................................................................................................290
Transfer Retries.......................................................................................................................292
SMTP Protocol Extensions.........................................................................................................292
Protocol Event Categories ......................................................................................................297
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.......................................................................................................325
Relocating the MTA Database Directory ...............................................................................327
Secured and Unsecured Message Copies............................................................................329
MTA Database in a Server Cluster ........................................................................................330
Corrupted Messages in Gateway Queues.............................................................................330
Fixing MTA Database Corruption ...........................................................................................331
Wiping the MTA Database......................................................................................................331
Replaying DAT Files................................................................................................................332
Examining Exchange MTA Processing..................................................................................333
Checking the Exchange MTA Using System Monitor...........................................................333
Exchange MTA Event Logging...............................................................................................337
Text Event Logging .................................................................................................................340
Trace Level Logging................................................................................................................341
MTA Check Logging................................................................................................................342
Object IDs and Message IDs ..................................................................................................342
How to Wipe the MTA Database................................................................................................343
Before You Begin ....................................................................................................................343
Procedure.................................................................................................................................343
How to Replay DAT Files After an MTA Database Wipe .........................................................344
Before You Begin ....................................................................................................................345
Procedure.................................................................................................................................345
Reference.................................................................................................................................345
How to Replay DAT Files After an MTA Database Wipe via a Complete Replay..................345
Before You Begin ....................................................................................................................345
Procedure.................................................................................................................................346
How to Replay DAT Files After an MTA Database Wipe via a Remote Replay.....................348
Before You Begin ....................................................................................................................348
Procedure.................................................................................................................................349
How to Replay DAT Files After an MTA Database Wipe via an Incremental Replay ............350
Before You Begin ....................................................................................................................350
Procedure.................................................................................................................................350
MTA Transport Stacks and X.400 Connectors .........................................................................352
Message Transfer Service......................................................................................................353
Reliable Transfer Service........................................................................................................358
Association Control Service....................................................................................................360
Presentation and Session Services .......................................................................................361
MTA Transport Stacks ............................................................................................................363
MTA Communication Example...............................................................................................366
X.400 Connectors....................................................................................................................368
Configuring an X.400 Connector ............................................................................................368
Connect Request Information.................................................................................................370
Outgoing and Incoming OSI Address Information ................................................................371
X.400 Addresses .....................................................................................................................371
X.400 Address Spaces............................................................................................................372
Conformance Year and Body Parts .......................................................................................374
Message Loop Detection ........................................................................................................376
X.400 Connector Objects in Active Directory ........................................................................378
Running Multiple X.400 Connectors.......................................................................................383
Connecting Routing Groups Using X.400 Connectors.............................................................385
Load Balancing between Routing Groups .............................................................................386
Message Routing over Exchange MTAs ...............................................................................387
SMTP XAPI Gateway..............................................................................................................387
Exchange MTA Message Transfer.........................................................................................389
Link State Information and Message Rerouting....................................................................391
Exchanging Link State Information Between Routing Groups .............................................392
Exchange MTA in a Mixed-Mode Organization ........................................................................393
RPC-Based MTA Communication..........................................................................................394
RPC Performance Impact.......................................................................................................395
RPC Bindback Error ................................................................................................................396
Gateway Address Routing Table............................................................................................396
Message Loops Between Exchange Server 5.5 and Exchange Server 2003 ....................398
Gateway Messaging Connectors Architecture..........................................................................398
EDK Connector Architecture ......................................................................................................399
Connector Components ..........................................................................................................401
Message Transfer to and from Exchange Server 2003........................................................409
Outbound Message Transfer..................................................................................................410
Inbound Message Transfer.....................................................................................................411
MAPI Profiles for MAPI-Based Connectors...........................................................................411
Message Conversion...............................................................................................................413
Address Translation ................................................................................................................414
Proxy Addresses and One-Off Addresses.............................................................................415
Address Mapping Issues.........................................................................................................416
Directory Synchronization .......................................................................................................418
Directory Synchronization from a Non-Exchange Messaging System to an Exchange
Organization .........................................................................................................................419
Directory Synchronization from an Exchange Organization to a Non-Exchange Messaging
System ..................................................................................................................................421
How to Open a Connector Mailbox Using Mdbvu32.exe .........................................................422
Before You Begin ....................................................................................................................422
Procedure.................................................................................................................................423
Connector for Lotus Notes Architecture ....................................................................................424
Message Transfer....................................................................................................................430
E-Mail Message Type Conversion .........................................................................................433
E-Mail Message Property Mapping ........................................................................................434
Connector for Novell GroupWise Architecture..........................................................................437
Message Transfer....................................................................................................................445
E-mail Message Type Conversion .........................................................................................450
E-mail Message Property Conversion ...................................................................................450
Calendar Connector Architecture ..............................................................................................454
Free/Busy Information.............................................................................................................454
Publishing of Free/Busy Data .................................................................................................455
Free/Busy Messages...............................................................................................................455
Free/Busy Data Generation ....................................................................................................456
Free/Busy Publishing in Outlook ............................................................................................456
Free/Busy Publishing in Outlook Web Access and Outlook Mobile Access .......................458
Free/Busy Data Lookup ..........................................................................................................458
Free/Busy Publishing Agent (MadFB)....................................................................................459
Cleaning Free/Busy Data........................................................................................................460
Outlook Startup Switch............................................................................................................460
Cleaning Using Outlook Web Access ....................................................................................461
Calendar Connector Components..........................................................................................461
Free/Busy Lookups to and from Lotus Notes........................................................................466
Free/Busy Lookups from Exchange 2003 .............................................................................468
Free/Busy Lookups from Lotus Notes....................................................................................469
Free/Busy Lookups to and from Novell GroupWise..............................................................470
Free/Busy Lookups from Novell GroupWise .........................................................................473
How to Check Whether a Server Running Exchange Server Contains a Replica of the
Free/Busy System Folder for the Administrative Group .......................................................474
Before You Begin ....................................................................................................................474
Procedure.................................................................................................................................474
Protocol Virtual Servers in Exchange Server 2003 ..................................................................475
IIS Integration ..............................................................................................................................476
Examining the Interprocess Communication Between IIS and Microsoft Exchange
Information Store Service....................................................................................................477
Exchange Installable File System ..........................................................................................478
Inbound Messages ..................................................................................................................479
Outbound Messages ...............................................................................................................480
File System Semantics............................................................................................................480
ExIPC Binding Facility.............................................................................................................480
ExIPC Protocol Stubs..............................................................................................................481
MAPI and RPC over HTTP.........................................................................................................481
RPC over HTTP.......................................................................................................................481
RPC Virtual Directory ..............................................................................................................483
RPC over HTTP and the Microsoft Exchange Information Store Service...........................483
Internet Protocol Details .............................................................................................................483
HTTP ........................................................................................................................................484
WebDAV and XML ..................................................................................................................485
POP3 ........................................................................................................................................486
IMAP4.......................................................................................................................................489
NNTP........................................................................................................................................492
Configuration Settings in Active Directory .............................................................................493
Configuration Settings in the Metabase.................................................................................493
IIS Metabase Updates Through DS2MB ...............................................................................494
High Water Marks....................................................................................................................494
Front-End Server Architecture................................................................................................495
Considerations When Using Front-End Servers ...................................................................495
Exchange ActiveSync and Exchange 2003 ..............................................................................496
Exchange ActiveSync Protocol Architecture .........................................................................497
Sync Protocol Versions and Device Support.........................................................................499
Sync Protocol Commands ......................................................................................................499
Sync Command Format..........................................................................................................500
URI............................................................................................................................................500
HTTP Header...........................................................................................................................501
HTTP Body...............................................................................................................................501
Protocol-Independent Multicast Data on the Mobile Device ................................................501
Exchange ActiveSync Profile..................................................................................................502
Up-to-Date Notification............................................................................................................502
Aggregators .............................................................................................................................503
Outlook Mobile Access and Exchange 2003 ............................................................................503
Outlook Mobile Access Dependencies ..................................................................................504
Outlook Mobile Access and .NET...........................................................................................504
.NET Framework .....................................................................................................................504
ASP.NET..................................................................................................................................505
Session Management .............................................................................................................505
Modified URL Session ID ........................................................................................................506
ASP.NET Device Updates ......................................................................................................506
Outlook Mobile Access Architecture ......................................................................................506
Outlook Mobile Access and Microsoft Outlook Web Access Templates.............................507
Outlook Mobile Access Data Sources....................................................................................508
Outlook Mobile Access Directory Settings.............................................................................509
Outlook Mobile Access and DS2MB ......................................................................................510
Outlook Mobile Access and the Windows Registry...............................................................511
Outlook Mobile Access and Web.Config ...............................................................................512
Outlook Mobile Access Client Requests................................................................................514
Outlook Mobile Access Security Architecture........................................................................515
Exchange Information Store Service Architecture....................................................................515
Exchange Storage Architecture .................................................................................................516
Storage Groups .......................................................................................................................518
Storage Group Architecture ....................................................................................................518
Storage Group Attributes in Active Directory.........................................................................520
Storage Group Minimum Disk Space Requirements ............................................................522
Exchange Store Databases....................................................................................................523
MAPI Database File ................................................................................................................523
Streaming Database File ........................................................................................................524
Property Promotion .................................................................................................................524
Database Size Limit Configuration and Management..............................................................525
Registry Settings .....................................................................................................................526
Database Size Limit in GB......................................................................................................527
Database Size Buffer Warning in Percentage.......................................................................527
Database Size Check Start Time in Hours from Midnight ....................................................527
Behavior When the Configured Database Size Limit or Licensed Database Size Limit Are
Reached ...............................................................................................................................528
Licensed Database Size Limit ................................................................................................529
Disaster Recovery Planning Considerations.........................................................................529
Extensible Storage Engine Architecture....................................................................................530
Transactions ............................................................................................................................530
ACID Transactions ..................................................................................................................531
The Version Store....................................................................................................................531
Snapshot Isolation ...................................................................................................................532
ESE Database Structure.........................................................................................................532
Database Pages ......................................................................................................................532
ECC Checksum .......................................................................................................................533
Database Consistency and -1018 Errors...............................................................................534
Database Tree Balancing .......................................................................................................535
Split...........................................................................................................................................536
Merge .......................................................................................................................................537
Fan-Out ....................................................................................................................................537
Indexes.....................................................................................................................................537
Long-Values.............................................................................................................................538
Record Format.........................................................................................................................538
Column Data Types.................................................................................................................538
Fixed and Variable Columns...................................................................................................539
Tagged Columns .....................................................................................................................539
Responsibilities of the Information Store...................................................................................540
Interactivity with other Exchange Services............................................................................540
Space Management ................................................................................................................541
Database Defragmentation.....................................................................................................542
Buffer Management.................................................................................................................543
Dynamic Buffer Allocation.......................................................................................................543
The LRU-K Replacement Algorithm.......................................................................................543
Public Folder Replication............................................................................................................544
Public Folder Database Trees................................................................................................544
Replication Overview...............................................................................................................545
Packing and Unpacking ..........................................................................................................546
Change Numbers ....................................................................................................................546
Replication Message Types....................................................................................................546
Replication Process.................................................................................................................550
Hierarchy Replication ..............................................................................................................550
Content Replication .................................................................................................................551
Backfilling .................................................................................................................................551
Backfill Array............................................................................................................................552
Replication Status....................................................................................................................552
Replication Status Thread.......................................................................................................553
Replication Status Requests...................................................................................................553
Modifying the Replica List.......................................................................................................554
Adding a Replica .....................................................................................................................554
Deleting a Replica ...................................................................................................................554
Replication State Tables .........................................................................................................555
Default Replication Event Schedule.......................................................................................556
Default Replication Values......................................................................................................557
Exchange Server 2003 Cluster Architecture.............................................................................558
Windows Cluster Architecture ....................................................................................................559
Server Clusters........................................................................................................................560
Server Cluster Architecture.....................................................................................................561
Cluster Service Components..................................................................................................562
Cluster Failover........................................................................................................................567
Cluster Failback.......................................................................................................................567
Cluster Quorum .......................................................................................................................568
Standard Quorum ....................................................................................................................568
Majority Node Set Quorums ...................................................................................................569
Cluster Resources...................................................................................................................570
Cluster Administration .............................................................................................................570
Cluster Formation and Operation...........................................................................................571
Creating a Cluster....................................................................................................................571
Forming a Cluster ....................................................................................................................571
Joining a Cluster......................................................................................................................572
Leaving a Cluster.....................................................................................................................573
Failure Detection .....................................................................................................................573
Exchange Virtual Servers...........................................................................................................574
Exchange Components in a Cluster.......................................................................................575
Active/Active Clusters .............................................................................................................577
Active/Passive Clusters...........................................................................................................578
Resource Dependencies.........................................................................................................579
Microsoft Exchange System Attendant Service ....................................................................579
Microsoft Exchange Information Store Service .....................................................................580
Message Transfer Agent.........................................................................................................580
Protocols ..................................................................................................................................580
Microsoft Search......................................................................................................................581
Exchange Cluster Interaction .....................................................................................................581
ExchangeOpen/ExchangeClose Functions...........................................................................582
ExchangeOnline and ExchangeOffline Functions.................................................................582
ExchangeIsAlive and ExchangeLooksAlive...........................................................................583
ExchangeTerminate ................................................................................................................583
Creating Resources.................................................................................................................583
Cluster-Specific Configurations..................................................................................................584
Exchange MTA ........................................................................................................................584
IIS SMTP Logging ...................................................................................................................584
AntiAffinityClassNames...........................................................................................................585
MAPI Public Stores .................................................................................................................586
Eseutil.......................................................................................................................................586
Installing Updates....................................................................................................................586
How to Disable MTA Monitoring on an Exchange Virtual Server............................................587
Before You Begin ....................................................................................................................587
Procedure.................................................................................................................................587
How to Enable SMTP Logging and Log the Files to a Shared Disk........................................588
Before You Begin ....................................................................................................................588
Procedure.................................................................................................................................588
How to Create an HTTP Virtual Server in Exchange System Manager..................................589
Before You Begin ....................................................................................................................589
Procedure.................................................................................................................................589
How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster
..................................................................................................................................................590
Before You Begin ....................................................................................................................591
Procedure.................................................................................................................................591
How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a
Windows Server Cluster .........................................................................................................592
Before You Begin ....................................................................................................................593
Procedure.................................................................................................................................593
Copyright .....................................................................................................................................593
17
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
18
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?
19

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.
20

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 nonExchange 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.
21

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
22
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.
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
23
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 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.
24

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.
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
25
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 mailenabled 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 mailenabled 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
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
26
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
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
27
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.
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
28
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.
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:
29

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.

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.
30
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 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.
31

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
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
32
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.
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.
33
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.
34
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:
35

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.
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
36
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.
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:
37
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:
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
38
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 demandstart 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"
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.
39
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
on the local computer. This account is only available to system processes and
does not have a password.
2. Logs on the service account
40
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
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.
41
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.
Exchange Services and the LocalSystem
Account
Exchange Server 2003 services run under the LocalSystem account. This has the following
security implications:
42

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:

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.
43
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.
Description
REG_SZ
Describes the service. The
description is simply a
comment that explains the
purpose of the service.
44
Value
Type
Description
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.
45
Value
Type
Description
ErrorControl
REG_DWORD
Specifies error severity and
the action taken if this service
fails to start. This parameter
determines one of the
following:
FailureActions
REG_BINARY

The startup program logs
the error but continues
the startup operation.

the error and displays a
message but continues
the startup operation.

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 error, if possible. If
configuration is started,
the system startup is
cancelled. Otherwise, the
system is restarted with
configuration.
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).
46
Value
Type
Description
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.
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_DISABL
ED.
47
Value
Type
Description
Tag
REG_DWORD
Determines the service
startup order within a loadordering 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 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
48
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.

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.
49
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
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,
50
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.
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.
51

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 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.
52
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
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.
53
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, 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.
54
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
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
55
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.

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
56
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.
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 inprocess 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.
57

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.
58
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.
59
Internal System Attendant components and their responsibilities
Component
Responsibility
Comments
DSAccess Component
Locating domain controllers
in the network and providing
other Exchange services with
Active Directory information
System Attendant must find
domain controllers and global
catalogs in the network, so
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.
60
Component
Responsibility
Comments
DSProxy Component
Proxying legacy MAPI clients
to Active Directory
System Attendant's DSProxy
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
information for Outlook Web
Access users
System Attendant is involved
when publishing free/busy
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.
61
Component
Responsibility
Comments
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
The Directory Service to
metabase update service
(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,
see Exchange Server 2003
Replicating settings from
Active Directory to the IIS
metabase
62
Component
Responsibility
Comments
Offline Address Book
Generator
Generating offline address
books
The offline address book
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
and generating proxy
addresses
The Recipient Update
Service (Abv_dg.dll) is the
System 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, see Exchange
Server 2003 and Active
Directory.
63
Component
Responsibility
Comments
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
Component

Verifies computer account
configuration
The computer account of an
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 corresponding registry key is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS.
64
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
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
65
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

Exchange Installable File System The Exchange installable file system is a kernelmode 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 email 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 Information Store service depends on ExIFS. The registry key for ExIFS is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS. For more information
66
about ExIFS and the architecture of the Exchange store, see Exchange Information Store
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.

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.
67
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 nonExchange messaging systems. In a mixed environment with servers running Exchange
Server 5.5 in the local routing group, the MTA is also used to transfer messages between
Exchange Server 2003 and Exchange Server 5.5. This occurs because Exchange
Server 5.5 MTAs communicate with each other in the local site directly through RPCs.
Exchange Server 2003 must rely on this communication method for backward
compatibility.
The executable file of the Microsoft Exchange MTA Stacks service is EMSMTA.exe,
which is located in the \Program Files\Exchsrvr\bin directory. This service depends on
System Attendant and maintains its own specific message queues outside the Exchange
store in the \Program Files\Exchsrvr\Mtadata directory. The registry key is
HKEY_Local_Machine\System\CurrentControlSet\Services\MSExchangeMTA.
68
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
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.
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.
69
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.
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:
70

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
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.
71

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
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.
72

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
\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 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.
73
File Name
Description
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.
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.
74
File Name
Description
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, ReplicationSignature, Unmerged-Attributes, and ADCGlobal-Names attributes to the schema to
update a pre-Exchange 2000 Service Pack 1
schema with the information required for
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.
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)
75
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.
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 hardcoded in the registry, the list of working domain controllers is re-evaluated and regenerated every 15 minutes using the topology discovery process and suitability tests.
76

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 regenerated 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
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.
77
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
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
78
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.
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
79
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.

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
80
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.
Location
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.

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.
81
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.
Location
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 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.
82
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.
Directory Access tab in Exchange System Manager
83
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
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
subkey. The following registry keys are required to statically configure domain controllers
and global catalog servers for use by DSAccess.
lt
Location
MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Value
IsGC
Type
REG_DWORD
Value Data
0x0
Location
of DC>
Value
HostName
Type
REG_SZ
Value Data
<name of DC>
84
Location
of DC>
Value
DSType
Type
REG_SZ
Value Data
0
Location
of DC>
Value
PortNumber
Type
REG_DWORD
Value Data
0x00000185 (389)
Location
of GC>
Value
IsGC
Type
REG_DWORD
Value Data
0x1
Location
of GC>
Value
HostName
Type
REG_SZ
Value Data
<name of GC>
Location
of GC>
Value
DSType
Type
REG_SZ
Value Data
0
85
Location
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:

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>
Location
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
86
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
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
87
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
Topology for Site B
Server
Config domain controllers
Domain controllers 2, 3, and 4
Global catalog 2 or 3
Domain controllers 2, 3, and 4
Global catalogs 2 and 3
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.
88
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.
Topology for Domain 1 and Site A
Server
Domain controllers 1, 2, 3, and 4
Global catalogs 1, 2, or 3
Domain controllers 1, 2, 3, and 4
Global catalogs 1, 2, and 3
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
Server
Domain controllers 1, 2, 3, 4
Global catalogs 1, 2, or 3
89
Server
Domain controllers 1, 2, 3, and 4,
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
Server
Domain controller 5
Global catalog 4
Working domain controller
Domain controller 5
Global catalog 4
Global catalog 4
Once again the servers are listed and used in the order in which they are discovered and
determined to be suitable.
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
90
Process
Description
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
WebDAV
Message transfer agent (MTA)
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.
91
Caution:
valuable data.
Location
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
Location
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.
Location
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
Location
Value
MaxEntriesUser
92
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)
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
93
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.

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.
94
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.
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.
95
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.
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.
96
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.
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:
97

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"

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
98

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
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.
99
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.
Server
Active Directory site
In-Use by DSAccess?
Total points by
constraint value
UserDomain GC1
UserDomain GC2
Client Active
Directory site
No
Client Active
Directory site
No
16+8+4=28
(1, 2, 3)
16+8+4=28
(1, 2, 3)
100
Server
In-Use by DSAccess?
Total points by
constraint value
UserDomain GC3
B
No
B
No
Exchange Domain
GC1
Exchange Active
Directory site
Yes
Exchange Domain
GC2
Exchange Active
Directory site
Yes
Exchange Domain
GC3
A
No
Exchange Domain
GC4
A
No
Exchange Domain
GC5
B
No
Exchange Domain
GC6
B
No
UserDomain GC4
16+8+4=28
(1, 2, 3)
16+8+4=28
(1, 2, 3)
16+8+2+1=27
(1, 2, 4, 5)
16+8+2+1=27
(1, 2, 4, 5)
16+8=24
(1, 2)
16+8=24
(1, 2)
16+8=24
(1, 2)
16+8=24
(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.
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
101
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 homedomain 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 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.
102
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 peruser 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.
103
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.
104
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.
105

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 email 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
106
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
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,
107
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 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,
108
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 preconfigured 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 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.
109

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:
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 registry key define the
threading model for the COM classes, the ProgID, the version number of the COM class,
and more.

HKEY_CLASSES_ROOT\CLSID

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
110
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.
111
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 snapin to a console. For
example,
Namestring=Exchan
ge System defines
the display name for
the Exchange
System snap-in.
{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-10BA11d2-9F2800C04FA37610}
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.
112
Parent Key
Parameter
Type
Comments
{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.
113
Parent Key
Parameter
Type
Comments
{CLSID}\ StandAlone
N/A
N/A
An existing
key
indicates that the
snap-in is a standalone snap-in. You
can add stand-alone
snap-ins to an MMC
console in the
Add/Remove Snapin dialog box. You
can also add standalone snap-ins to
subnodes of other
snap-ins, using the
stand-alone snap-in
in the same way as
an extension snap-in.
StandAlone
Extension snap-ins
do not have a
StandAlone key.
Therefore, the snapin 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
for a stand-alone
snap-in in the
Add/Remove Snap-
114
Parent Key
Parameter
Type
Comments
{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.

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
KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes
115
version 3 (POP3) container object (GUID {F54E0C6b-11FF-11d2-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 DLL
Description
Exchange Message
Tracking Center
Not applicable
Exadmin.dll
Provides access to
the message-tracking
center. This is a
stand-alone snap-in.
116
Snap-in
Snap-in Extension
Description
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.
117
Snap-in
Exchange Servers
Snap-in Extension
Description
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.
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.
118
Snap-in
Snap-in Extension
Description
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
Information Store
Exadmin.dll
Enables the
management of
storage groups,
mailbox stores, and
public folder stores.
119
Snap-in
Snap-in Extension
Description
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
Viewer
Exadmin.dll
Provides access to
the queue viewer in
Exchange System
Manager, which
provides
management
interfaces for SMTP,
MTA, X.400, and
other connector
queues.
120
Snap-in
Snap-in Extension
Description
Exchange System
Not applicable
Exadmin.dll
The core MMC snapin 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
Lists
Exadmin.dll
Enables
management of
address lists,
including global
address lists and
offline address
books.
Exchange Address
Templates
Exadmin.dll
Enables
management of
address templates.
Exchange Calendar
Connector
Exadmin.dll
Enables
management of
Calendar Connector
instances. Calendar
Connector enables
the synchronization
of free/busy
information between
Exchange users and
Lotus Notes or Novell
GroupWise users.
121
Snap-in
Snap-in Extension
Description
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.
122
Snap-in
Snap-in Extension
Description
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
GroupWise
Connector
Exadmin.dll
Enables
management of
Connector for Novell
GroupWise.
123
Snap-in
Snap-in Extension
Description
Exchange
Information Store
Exadmin.dll
Enables
management of
storage groups,
mailbox stores, and
public folder stores.
Exchange Mailbox
Recovery Center
Exadmin.dll
Provides access to
Mailbox Recovery
Center, which you
can use to recover
individual mailboxes
from a backup.
Exchange Message
Tracking Center
Exadmin.dll
Provides access to
and use of Message
Tracking Center.
Exchange Monitoring
Exadmin.dll
Provides access to
the monitoring and
status features for
managing
connectivity between
routing groups.
124
Snap-in
Snap-in Extension
Description
Exchange MSMail
Exadmin.dll
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
Connector
Exadmin.dll
Provides access to
the Connector for
Lotus Notes
configuration
settings.
125
Snap-in
Snap-in Extension
Description
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
Viewer
Exadmin.dll
Provides access to
the queue viewer in
Exchange System
Manager, which
provides
management
interfaces for SMTP,
MTA, X.400, and
other connector
queues.
Exchange Recipient
Policies
Exadmin.dll
Enables
management of
recipient policies,
which Recipient
Update Service uses
to assign recipient
information, such as
e-mail addresses, to
user accounts.
126
Snap-in
Snap-in Extension
Description
Exchange Schedule+
Free/Busy Connector
Exadmin.dll
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.
127
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.
128
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
129
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.
130
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-SiteName,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.
131
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:
132

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 System Policies
Container. Then, to create either a Mailbox store policy, Public store policy, or
133
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 permissions are required for mailbox
administrators who must mailbox-enable or mail-enable user accounts, but who are not
responsible for Exchange server management.
134
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 Settings Configuration Settings
Exchange Full
Administrator
Yes
Yes
Yes
Exchange
Administrator
No
Yes
Yes
Exchange View Only
Administrator
No
No
Yes
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
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
135
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\Ex
change\ExAdmin
Value Name
ShowSecurityPage
Data Type
REG_DWORD
Value
1
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.
136
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
ANONYMOUS LOGON

Create Named Properties None
in the Information Store

Create Public Folder

Execute

List Contents

List Object

Read

Read Permissions

Read Properties

Read Properties

List Object
Authenticated users
Denied
None
137
Account
Permitted
Denied
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 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

View Information Store
Status

Receive As

Send As
138
Account
Permitted
Enterprise Admins

Everyone
Exchange Domain Servers
Full Control
Denied

Receive As

Send As

Create Named Properties None


Execute

List Contents

List Objects

Read

Read Permissions

Read Properties

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.
139
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
140
and client 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
141
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.
142
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:
143

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.
144
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.
145
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.
146
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 Exchange System Manager.
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.
147
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.
148
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
149
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).
2. Point to View.
150
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
environment. All WMI interfaces are based on Component Object Model (COM). Therefore,
the communication between Exchange System Manager and Winmgmt is based on RPCs.
151
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.
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
152
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
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
153
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
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
154
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.
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
155
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:
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
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.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services
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
156
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 Exchange
organization in order to understand the fundamentals of message routing in

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.
157
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
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
158
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
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
159
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 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
160
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.
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
Transfer Protocol
Comments
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
Transfer Protocol
Comments
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 presubmission 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 mailenabled 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 postcategorization 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 queuing engine
165
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.
166
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
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).
The next hop is to a server outside the
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).
167
Hop Type
Comments
The next hop is to a server that is currently
unreachable
This indicates that a destination path exists,
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
unreachable
This indicates that no final destination path
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 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
168
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 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
169
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
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
170
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))).
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-9B8F4403F20CAD0D ( 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
171
{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
d38082e7c9ecd74dbff32bada89
The GUID that is registered
in the objectGUID attribute of
the Exchange organization
object in Active Directory.
32642
MD5 Digest
d037d6eaf2fa7cd10934aca4333
90623
Routing Group objectGUID
489416bfa3a4ff459b8f4403f20
cad0d
An MD5 digest or hash 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.
the routing group object to
which the routing information
belongs. This GUID follows
next in the link state table.
172
Field
Value
Comments
Routing Group Master
objectGUID
1650c1fe32aef740be236e1089e
the server that acts as the
routing group master in this
routing group.
0da6a
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
Field
Value
Comments
Version Info
8 0 2
The values 8 0 2 are the
major, minor, and user
versions of the link state
information. The routing
engine uses this version
information to classify
updates to the link state
information, as follows:
c2da71f9b39ec748aaf44119a2b
dcb36

Major
updates Represent
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 Represent
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 Represent
changes that occur when
services are started or
stopped on an Exchange
server or when a server
loses its connectivity to
the routing group master.
Adding a new server to a
routing group also
represents a user update.
The remaining data is the
GUID of this version
information.
174
Field
Value
Comments
Routing Group Addresses
{26}*.489416BF-A3A4-FF45-
Maps SMTP, X.400, X.500,
and address information to
individual routing group
GUIDs. The routing engine
uses this information to
generate an internal server
cache, which is used to
identify the routing group of
each server in the routing
topology. The server cache is
an internal table of the
routing engine.
9B8F-4403F20CAD0D
{4c}c=DE;a=
;p=TailspinToys;o=Exchange;
cn=489416BF-A3A4-FF45-9B8F4403F20CAD0D;*
{55}/o=TailspinToys/ou=Firs
t administrative
Group/*/489416BF-A3A4-FF459B8F-4403F20CAD0D
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.4
89416BF-A3A4-FF45-9B8F4403F20CAD0D.
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
Field
Value
Comments
Routing Group Members
(
Contains a list of all servers
that belong to the routing
group and identifies their
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.
1650c1fe32aef740be236e1089e
0da6a YES 1 1b20
{10}0701000000000101 )
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:
1650c1fe32aef740be236
e1089e0da6a

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:
{10}0701000000000101
The user data indicates the
state of the server. If the
value begins with 0701, the
server is available and
operating. If the value begins
with 0702, the server is in a
176
Field
Value
Comments
Connectors in Routing Group
(
Starting at the next open
parenthesis, each connector
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.
aa582d35e9621c4ca8ae57aa33d
953a1 ( CONFIG ))
The connector configuration
information in the link state
table has the following fields:
Connector objectGUID
aa582d35e9621c4ca8ae57aa33d
953a1
The GUID that uniquely
identifies the connector in the
177
Field
Value
Comments
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
Field
Value
Comments
Source Bridgehead Address
{}
This field can have one of
three values:

No value If no source
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}_76290a25817c0643a1
a6999e669b1d5f_S
The local bridgehead
servers are then listed
later in the BH field in the
connector information.

A bridgehead
address X.400
connectors and MAPIbased connectors cannot
have more than one local
bridgehead server. For
these connectors, the
local bridgehead server is
specified in the Source
Bridgehead Address
field, such as:
{8}SERVER01. To provide
availability information,
179
Field
Value
Comments
Destination Bridgehead
Address
{23}_aa582d35e9621c4ca8ae57
As with the Source
Bridgehead Address field,
this field can have one of
three values:
aa33d953a1_D

No value X.400
connectors and MAPIbased 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
address SMTP
connectors cannot have
multiple destination hosts
when they connect
routing groups to each
other. The connector
configuration requires
you to specify a smart
host in the remote routing
group, which is then
indicated as the
destination bridgehead,
such as: {8}SERVER02.
180
Field
Value
Comments
Legacy Distinguished Name
{63}/o=TailspinToys/ou=Firs
This is the distinguished
name of the connector in
legacy Exchange 5.5
directory format. The value
corresponds to the
legacyExchangeDN attribute
of the connector object in
Active Directory.
t administrative
Group/cn=Configuration/cn=C
onnections/cn=RGC RG A <->
RG B
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
Field
Value
Comments
Restrictions
0 0 0 ffffffff ffffffff 0 1
The Restrictions field
identifies the scope of the
connector, message size
restrictions, and other
constraints, as follows:
0 () 0 () 0 () 0 ()

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,
normal, low, system, and
non-system) that is
allowed through this
connector.

The next eight bytes
specify message size
restrictions, if any. If no
message size restrictions
apply to this connector,
the value is ffffffff.
182
Field
Value
Comments
Address Spaces
ARROWS ( {2}RG
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.
{20}83bd0e29fad06d4eb8b00fa
ab3265cd5 1
{4}X400
{23}c=DE;a=
;p=TailspinToys;o=Exchange;
1 )
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 space The
address space specifies
the address pattern that
the routing engine
compares to the recipient
addresses to identify the
destination of the
message. The routing
engine uses address
spaces differently
183
Field
Value
Comments
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_AVAIL The
available.


VS_NOT_STAR
TED A virtual SMTP
server is stopped or
is not started.


CONN_NOT_AV
AIL The connection
is unavailable on the
bridgehead server.
For example, the
source bridgehead
server cannot
establish a
connection to a
destination
bridgehead server.

Virtual Server
FQDN The FQDN of the
virtual server that acts as
a bridgehead server for
this connector.
184
Field
Value
Comments
Destination Bridgeheads
TARGBH (
As with the BH () list, the
TARGBH () list contains the
destination bridgehead
servers for a connector. This
list is particularly important
for routing group connectors,
which can have more than
one remote bridgehead
server.
766a192b43bfc3459ee85608d65
a98a9 CONN_AVAIL
{19}server01.TailspinToys.c
om )
In the example, the following
information identifies the
remote bridgehead server:

Bridgehead Server
objectGUID 766a192b43
bfc3459ee85608d65a98a9

Bridgehead Server
Status CONN_AVAIL

Virtual Server
FQDN {19}server01.Tai
lspinToys.com
185
Field
Value
Comments
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
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
connector, in
addition to DNSrouted SMTP
connectors and
MAPI-based
connectors, are
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 Server 2003.
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 connector restrictions to exclude all
those connectors that must not be used to transfer the message.
190
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.
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.
192
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.
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.
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.
193
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.
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
194
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.
Possible configurations between routing groups
Possible configuration
Comments
A single routing group connector with multiple With these types of connectors, the routing
source or multiple destination bridgehead
engine returns the connector GUID in the
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 loadbalancing 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.
195
Possible configuration
Comments
Multiple connectors with the same address
space (or connected routing group), same
weight (cost), and each with a single source
and destination bridgehead server
In this type of configuration, true load
balancing is not achieved. Load balancing is
performed only to the extent of selecting 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
space (or connected routing group), different
weights (cost), and each with a single source
and destination bridgehead server
If you want to configure connectors to fail
over automatically, you can create two
separate connectors on different bridgehead
servers, each with a different 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.
Load Balancing between Connectors and
External Systems
Depending on the scenario, there are a few ways to achieve load balancing across SMTP
connectors.
196

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
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
197
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.
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.
198
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.
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.
199
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
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
200
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.
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
201
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
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.
202
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 XLINK2STATE command.
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
203
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.
204
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.
205
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.
206
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 through
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 through
incorporates the information into the link state table and notifies all servers in the routing
207
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.
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.
208
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\CurrentControlSe
t\Services\RESvc\Parameters\
Value
StateChangeDelay
Type
REG_DWORD
209
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.
Location

Value
SuppressStateChanges
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.
210
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.
211
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.
212

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.
Location
Value
ReloadOsInterval
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
213
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.
214

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.

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
215
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).
216
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
217
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 nonblocking 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 that a thread from this
218
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.
Location
t\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.
219
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\CurrentControlSe
t\Services\SMTPSVC\Queuing
Value
MaxPercentPoolThreads
Type
REG_DWORD
Value Data
The default is
Description
Limits the percentage of ATQ threads that the
SMTP service can use. The recommended
setting is:
0x5A (90%)
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.
Location
Value
AdditionalPoolThreadsPerProc
Type
REG_DWORD
Value Data
The default is
0x5A (90%)
220
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
AdditionalPoolThreadsPerProcvalue
is greater than 200, you must
increase the value of the
PoolThreadLimit parameter under
HKEY_LOCAL_MACHINE\
System\CurrentControlSet\Service
s\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.
221
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.
222
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.
223
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
224
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.
225
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.
226
Description
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.
msExchSmtpMaxOutgoingConnectionsPerDo Specifies the maximum number of outbound
main
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.
227
Description
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
server must generate a delivery status
notification to inform the sender that a local
message did not reach its destination.
msExchSmtpRemoteQueueExpirationTimeou Specifies the time at which this SMTP virtual
t
server must expire an undelivered outbound
message.
msExchSmtpRemoteQueueDelayNotification
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.
msExchSmtpInboundCommandSupportOptio
ns
Controls which SMTP commands are
supported on inbound connections. By
changing this value, you can disable features
like 8BITMIME, BDAT, CHUNKING, and
PIPELINING.
msExchSmtpRelayForAuth
Determines whether the message relaying
requires authentication.
228
Description
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.
msExchBridgeheadedLocalConnectorsDNBL
Specifies a list of connectors in the SMTP
virtual server's routing group for which this
SMTP virtual server is the local bridgehead.
msExchBridgeheadedRemoteConnectorsDN
BL
Specifies a list of connectors in remote
routing groups for which this SMTP virtual
server is a remote bridgehead.
Note:
The metabase update service replicates all these configuration settings into the IIS
metabase.
229
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 inmemory 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.
The following figure illustrates the hierarchy of configuration entries for SMTP virtual servers,
according to the Location property of each IIsSmtp metabase entry.
230
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"
FullyQualifiedDomainName="server01.TailspinToys.com"
...
231
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 ...
>
<Custom
... custom property defintion...
232
/>
</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-bfdd96b9c605364c._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.
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
233
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-9E0300C04FA322BA, 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.
Event binding information
Property Description
ID
A GUID that uniquely identifies the binding.
This information is required.
DisplayName
An optional user-friendly name for the
binding.
234
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.
235
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
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
236
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-9E0200C04FA322BA}. 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.
237
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.
238
' 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
239
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.
240
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
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
241
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 as an
242
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.

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
243
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.
244
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 precategorization 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.
245
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.
Location
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.
246
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.
247
System queues in the advanced queuing engine
Queue
Description
Messages With an Unreachable Destination
This queue contains messages that cannot
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.
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.
248
Queue
Description
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:
Failed Message Retry

284204, "Delivery status notifications in
Exchange Server and in Small Business
Server"

256321, "Enhanced Status Codes for
Delivery - RFC 1893"
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.
249
Location
HKEY_LOCAL_MACHINE\Software\Microsoft\Exch
ange\Mailmsg
Value
MaxMessageObjects
Type
REG_DWORD
Value Data
0x000186a0
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-ofmemory 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.
250
Location
HKey_Local_Machine\Software\Microsoft\Exch
ange\TransportAVAPI
Value
Enabled
Type
REG_DWORD
Value Data
0x1
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
251
detailed information on the routing architecture of Exchange Server 2003, see Message

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 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
252
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 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.
253
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 than requiring multiple round trip LDAP
254
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.
Comments
For more information about NDR codes, see
Microsoft Knowledge Base article 284204,
"Delivery status notifications in Exchange
Server and in Small Business Server."
255

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 nonExchange 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.
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.
256
Details of non-delivery reports with code 5.1.1
Numerical 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 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
257
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

Numerical 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.
Comments
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 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
Numerical code
5.4.6
258
Possible cause
A categorizer forward loop is detected. A
targetAddress attribute is set on a mailboxenabled 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.
Comments


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 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
259
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 perrecipient 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 prerouting 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.
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
260
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.
261
Delivery status notification redirection and deletion criteria
Criteria
Action
Distribution group has an owner, and delivery
reports are configured to be sent to this
owner
Redirect non-delivery reports to notify the
configured owner of the group when an 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 to
message originator
Send delivery status notification to the 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 ExchangeAdvanced tab, is not selected for the group.
By default, this check box is not selected.
262
Criteria
Action
Distribution group is configured to suppress
delivery reports for group members to avoid
disclosing membership information
Suppress all out-of-office notifications, auto
replies, and all types of delivery status
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
263
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 SMTPbased 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.
264
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.
265
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.
266
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 nonMAPI clients from accessing attachments. Non-Microsoft tools, such as EPOC
WMDecode for Windows, might be able to extract attachments from Winmail.dat
files.
267

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\Exch
ange\StoreDriver\Exchange\nn\EnableTnef
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
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.
268
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.
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
269
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.
Location
t\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).
Location
Value
LdapRequestTimeLimit
Type
REG_DWORD
Value Data
0x258
270
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).
Location
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.
Location
Value
CatRetryMinutes
Type
REG_DWORD
Value Data
0x3C
271
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.
Location
Value
MaxLdapConnections
Type
REG_DWORD
Value Data
0x8
272
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
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
273
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.
Location
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.
Location
Value
MaxPendingSearches
Type
REG_DWORD
Value Data
0x3C
274
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:
275
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
276
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 recategorize 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 recategorize 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:
Caution:
277
own risk.
Location
t\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 recategorization (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.
278
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:
279

\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 "xreceiver" 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.
280
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.
281
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 nonExchange 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.
282
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
283
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.
284
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 system. This namespace
provides access to all private and public databases. The format is
file://./backofficestorage/DomainName, such as file://./backofficestorage/fabrikam.com.
285
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-b0dd96b9c605364\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
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.
286
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 sharedmemory 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
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.
287
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.
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.
288
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.
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 inmemory 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.
289
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.
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.
290
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.
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
291
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.
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
292
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.
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
AUTH=LOGIN
Signals that the local SMTP virtual server
supports the SMTP authentication service
extension. The additional information after
the AUTH key word identifies the supported
authentication mechanisms.
293
Comments
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.
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).
294
Comments
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).
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.
295
Comments
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.
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.
296
Comments
X-EXPS GSSAPI NTLM LOGIN, XEXPS=LOGIN
X-EXPS is a command that is proprietary to
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:
X-LINK2STATE

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.
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:
297

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.
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.
298
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.
299
Protocol extensions for the XEXCH50 command
Event sink
Protocol event
Comments
Exchange SMTP Protocol
XEXCH50 Before Data Sink
OnBeforeData
Notifies the XEXCH50 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.
XEXCH50 Inbound EHLO
Sink
OnInboundCommand
Notifies the XEXCH50 sink
that an EHLO command was
received.
XEXCH50 Inbound
XEXCH50 Sink
OnInboundCommand
Implements the XEXCH50
command to start an
XEXCH50 conversation.
XEXCH50 Inbound MAIL
Sink
OnInboundCommand
Implements the MAIL
command in an XEXCH50
conversation.
XEXCH50 Inbound RCPT
Sink
OnInboundCommand
Enables the local SMTP
virtual server to receive
recipient information in an
incoming XEXCH50
communication.
XEXCH50 Per Recipient
Event Sink
OnPerRecipient
virtual server to send
recipient information in an
outgoing XEXCH50
communication.
300
Event sink
Protocol event
Comments
XEXCH50 Ehlo Response
Sink
OnServerResponse
virtual server to receive a
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
OnServerResponse
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.
301

Event sink
Protocol event
Comments
XEXCH50 RCPT Response
Sink
OnServerResponse
virtual server to receive
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.co
m.
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 XLINK2STATE event sinks are implemented in Xlsasink.dll in the \Program
Files\Exchsrvr\bin directory.
302
Protocol extensions for the X-LINK2STATE command
Event sink
Protocol event
Comments
EHLO Inbound Command
Handler Sink for XLSA
OnInboundCommand
Notifies the X-LINK2STATE
event sinks that an incoming
EHLO command was
received.
X-LSA Inbound Command
Handler Sink
OnInboundCommand
Notifies the X-LINK2STATE
event sinks that an incoming
X-LINK2STATE command
was received.
X-LSA Sink
OnMessageStart,
OnSessionEnd
Signals the start (MAIL
command) and end (QUIT
command) of an outbound XLINK2STATE
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
Sink
OnServerResponse
Responds to an incoming XLINK2STATE 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
Sink for X-LSA
OnServerResponse
Responds to an incoming
EHLO command by listing
the X-LINK2STATE
command in the server
response.
303

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.
X-EXPS protocol security extensions

Event sink
Protocol event
Comments
Security EXPS-EOD Sink
OnInboundCommand
Signals the end of data
transfer ( _EOD).
Security EXPS-Aux Sink
OnInboundCommand
Signals an incoming AUTH
command.
Security EHLO Sink
OnInboundCommand,
OnServerResponse
Signals an incoming EHLO
command and responds to
EHLO by listing the X-EXPS
command in the server
response.
Security Mail Sink
OnInboundCommand,
OnServerResponse,
OnMessageStart
Indicates the start of data
transfer. This event sink is
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.
Security EXPS Sink
OnInboundCommand,
OnServerResponse,
OnSessionStart
Indicates the start of an XEXPS session. This event
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.
304
The spam control event sinks are implemented in Turflist.dll in the \Program
Spam control SMTP extensions
Event sink
Protocol event
Comments
RCPT Inbound Command
Handler Sink
OnInboundCommand
Signals an inbound RCPT
command with a recipient
address that should be
checked.
MAIL Inbound Command
Handler Sink for TURF
OnInboundCommand
Signals an inbound MAIL
command with a sender
address that should be
checked.
EOD Inbound Command
Handler Sink
OnInboundCommand
Signals an inbound _EOD
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, XEXPS, 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.
305
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.
306
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 email 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
307
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.
308
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:
309
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\Diagnos
tics.
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
310
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.
311
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.
312
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.
313
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\MSExchangeMTA.
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.
314

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
MTA communication through the Exchange store
315
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

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 nonExchange 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 more
information about communication between Exchange Server 2003 and Exchange 5.5,
see Exchange MTA in a Mixed-Mode Organization.
316
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.
317
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.
318
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\Current
ControlSet\Services\MSExchangeMTA\Diagn
ostics.
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.
msExchHomeRoutingGroupDNBL
A back link to the routing group of which this
MTA is a member.
319
Directory Attribute
Purpose
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
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
the Exchange MTA waits before ending a
connection after all associations over this
connection are ended.
320
Directory Attribute
Purpose
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
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 nonurgent message.
transferTimeoutNormal
a non-delivery report (NDR) for a normal
message.
transferTimeoutUrgent
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.
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.
321
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.
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.
322
Location
t\Services\
MSExchangeMTA\Parameters
Value
Transfer threads
Type
REG_DWORD
Value Data
0x1
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 fanout. 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
323
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
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.
Location
t\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.
324
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 (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.
325
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).
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
326
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.
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
327
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.
Location
t\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
Exchange MTA are located. It is best to place the database and run directory on
different disks.
328
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.
Location
t\Services\
Value
DB data buffers per object
Type
REG_DWORD
Value Data
0x3
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.
329
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
gateways are blocked by multiple corrupted messages, this might indicate a serious problem
(for example, a hard disk controller malfunction).
Location
t\Services
\MSExchangeIS\<server_name>\Private<database_guid >
Value
Gateway In Threads Gateway Out Threads
Type
REG_DWORD
Value Data
0x1
330
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
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.
331
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.

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.
332
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.
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.
333
Performance counter
Description
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.
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.
334
Performance counter
Description
Admin Interface Receive Bytes/sec
The rate at which bytes are received over an
admin connection.
Admin Interface Transmit Bytes/sec
an admin connection.
LAN Transmit Bytes/sec
a LAN to MTAs.
LAN Receive Bytes/sec
LAN from MTAs.
RAS Receive Bytes/sec
RAS connection. RAS-based X.400
connectors are not available in Exchange
Server 2003.
RAS Transmit Bytes/sec
a RAS connection. RAS-based X.400
Server 2003.
TCP/IP Receive Bytes/sec
TCP/IP connection.
TCP/IP Transmit Bytes/sec
a TCP/IP connection.
TP4 Receive Bytes/sec
TP4 connection. TP4-based X.400
Server 2003.
TP4 Transmit Bytes/sec
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
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
335
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.
MSExchangeMTA connections performance counters
Performance counter
Description
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.
336
Performance counter
Description
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
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.
337
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.
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.
338
Category
Description
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.
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.
339
Category
Description
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 fullyencoded 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
340
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\Servi
ces\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
341
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-4AFD85AF-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,
342
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
343
ensure that the Microsoft Exchange MTA Stacks service is stopped.
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 readonly 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)
344

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
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
345
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
346
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.

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.
347
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.
348
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.
349
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.
3. If no messages are residing in the MTA work queue, stop the Microsoft Exchange
350
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.

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 a remote
replay, see How to Replay DAT Files After an MTA Database Wipe via a Remote Replay.
351
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 LANMTAs 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
352
MTA 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 demultiplexing 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.
353
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.
Supported message formats in Exchange Server 2003
Format
Content Type
MDBEF

Microsoft 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.
Object Identifier
2A864886F7140501
354
Format
Content Type
Public Folder MDBEF

Microsoft-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.

Defined in X.400 of the
1984 conformance year.

Defines the format of an
interpersonal message
(IPM).

Defined in X.400 of the
1988 conformance year.

Extends the format of an
interpersonal message
(IPM), as defined in
X.400-84.

Military 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 DMScapable clients, and
STANAG 4406 v1.7 and
v3 clients.
P2
P22
P772
Object Identifier
2A864886F7140502
56010A00
56010A01
2B1A00A236000401
355
Format
Content Type
P42

Secure military 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.

Also referred to as
"MSP3."

Common 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."
CSP
Object Identifier
60864801650201022A
608648016502010203
356
Format
Content Type
TNEF

Transport Neutral
Encoding Format
(TNEF).

Microsoft-defined and
registered content type.

Also referred to 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.
Object Identifier
2A864886F7140502
The following figure illustrates how the P1 and P2 protocols map to the architecture of
Envelope and message protocols
357
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.
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
358
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-TURNPLEASE 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-PABORT 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 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:
359
own risk.
Location
t\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.
Association Control Service
The Association Control Service Element (ACSE) is a component of every connectionoriented 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 AASSOCIATE 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.
360

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
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).
361
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-MINORSYNCHRONIZE 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 PACTIVITY-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.
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:
Location
t\Services\
Value
Kernel threads
Type
REG_DWORD
Value Data
0x1
362
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 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.
363
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 Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com"
-p subtree -r "(objectClass= rFC1006Stack)"
The following table describes the important attributes of the TCP/IP transport stack.
364
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.
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
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)"
365
The following table describes the important attributes of the X.25 transport stack.
Important attributes of the X.25 transport stack object
Attribute
Description
objectClass
x25Stack.
nAddress
Specifies the local X.121 address.
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.
tSelector
sSelector
pSelector
supportingStackBL
Lists the distinguished names of X.400
connectors that use this transport stack.
x400SelectorSyntax
tSelector, sSelector, and pSelector attributes.
The OSI address information can be a hex
value or a decimal value.
name
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.
366
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.
Location
t\Services\
Value
Transport threads
367
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.
368
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 addition, you can
369
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 perconnector 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.
370
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;
371
Label
Abbreviation
Attribute Type
Example
A
ADMD
ADMD name
A=MCI;
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
OU2=USA;
OU3
Org.Unit.3
OU3=SEA;
OU4
Org.Unit.4
OU4=DOWNTOWN;
DDA
DDA
Domain Defined
Attribute
(DDA:type=value
attribute)
DDA:SMTP=Ted@tai
lspintoys.com
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
372
connector with other address types, for example, by specifying SMTP address information, as
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-
373
822=Ted@tailspintoys.com. Exchange Server 2003 uses SMTP DDAs instead of RFC822
DDA and does not support MIXER.
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
374
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
375
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
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
376
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
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.
377
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
378
"(objectClass=x400Link)"
The following table describes the important attributes of X.400 connector objects.
Important attributes of X.400 connector objects
Attribute
Description
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
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.
379
Attribute
Description
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.
name
object, as displayed in Exchange System
Manager.
numOfOpenRetries
the Exchange MTA tries to open a connection
before it sends a non-delivery report (NDR).
380
Attribute
Description
numOfTransferRetries
the Exchange MTA tries to transfer a
message across an open connection.
objectClass
x400Link. The following object classes are
derived from this class:

rFC1006X400Link TCP/IP X.400
connectors

x25X400Link X.25 X.400 connectors
openRetryInterval
system waits after an error, before attempting
to reopen a connection.
pRMD
Specifies the PRMD portion of a manually
pSelector
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.
381
Attribute
Description
sessionDisconnectTimer
the Exchange MTA waits before
disconnecting a connection after all
associations over this connection are
cancelled.
sSelector
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
system waits after a message transfer fails
before re-sending a message across an open
connection.
transferTimeoutNonUrgent
an a non-delivery report (NDR) for a nonurgent message.
transferTimeoutNormal
a non-delivery report (NDR) for a normal
message.
transferTimeoutUrgent
a non-delivery report (NDR) for an urgent
message.
translationTableUsed
Specifies the translation table that the MTA
uses to encode the message text.
382
Attribute
Description
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.
tSelector
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.
383
Location
t\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.
Location
t\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
384
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.
385
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.
386
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)".
387
The following table describes the important attributes of the SMTP XAPI gateway object.
Important SMTP XAPI gateway attributes
Attribute
Description
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
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.
canPreserveDNs
Indicates whether the connector object can
handle distinguished names in recipient
information.
388
Exchange MTA Message Transfer
The following figure illustrates how the SMTP service and the Exchange MTA interact with
each other.
389
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
390
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
391
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.
392
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),
393
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.
Location
t\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.
Location
t\Services\
Value
Max RPC Calls Outstanding
Type
REG_DWORD
Value Data
0x32
394
Location
t\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.
395
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
396
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
Attribute
Description
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.
397
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.400based 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 nonExchange 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.
398

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 nonExchange 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 performed in the SMTP
transport subsystem. For detailed information about Exchange Server 2003 message
handling, see Message Routing Architecture.
399
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. MAPIbased connectors use MAPI to retrieve messages from Exchange. On the nonExchange 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.

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
400
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 nondelivery 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.
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:
401

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 MAPIbased 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.

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
402
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.
403
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
404
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\AddressTypes. 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).
405
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
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 typespecific 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.
406
Important general attributes of msExchConnector objects
Attributes
Description
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
connector object in Active Directory.
homeMDB
Identifies the private store that holds the
connector mailbox.
homeMTA
Identifies the Exchange MTA that is
responsible for message routing to the MAPIbased connector.
legacyExchangeDN
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.
407
Attributes
Description
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 MAPIbased connectors in Active Directory
by objects of a class that inherits
from the mailGateway class. The
mailGateway object, in turn, is a subclass 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.

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
408
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.
409
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.
410
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. MAPIbased connectors use the MAPILogonEx function to create the required profile dynamically
and without the need for a MAPI client on the server. For detailed information how to create
411
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-518\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.
412
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.
413

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.
414
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 nondelivery 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
address in the message envelope of the outbound message. For inbound messages, the
translation is performed in the opposite direction.
415
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.
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
416
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.
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.
417
Message Class
Description
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 nonExchange messaging system. If the nonExchange 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.
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.
418
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 NonExchange 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 MAPIbased 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.
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
419
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.
Directory synchronization from a non-Exchange messaging system to Active Directory
420
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.
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 nonExchange 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.
421
Directory synchronization from Active Directory to a non-Exchange messaging system
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:
422
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-518\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 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 MTSIN.
13. Close Mdbvu32.exe and remove your account from the Exchange Domain Servers
group.
423
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.
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).
424
Component
Description
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" -vLMENOTES 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 component obtains
messages from the READYOUT folder in
the connector mailbox, converts them
from MAPI to Lotus Notes format, and
writes them to the mail.box database on
the Domino server.

Lsmexout.exe This component obtains
outbound messages from the MTS-OUT
queue, checks Active Directory to replace
target recipient information with
corresponding Lotus Notes addresses,
425
Component
Description
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 permissions to drop mail
messages and to perform database
maintenance operations.

Names.nsf This is the default Lotus
Domino directory file that Connector for
Lotus Notes uses for directory
synchronization. It is possible to specify
different or additional address books for
Lotus Domino domains. The connector
needs Editor permissions with Delete
rights to perform directory
synchronization.
426
Component
Description
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
"XFOR: Customizing Directory
Synchronization Between Exchange and
Notes."
427
Component
Description
Registry settings
In the Registry, settings for Connector for
Lotus Notes are stored in the following
location:
HKEY_LOCAL_MACHINE\SYSTEM\Current
ControlSet\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.
428
Component
Description
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 Specifies
whether mail-enabled contacts are
propagated to Lotus Notes through
directory synchronization.


msExchServer1AlwaysCreateAs
Specifies how X.500 objects are
synchronized.

msExchDeliveryOrder Specifies 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

msExchPartnerLanguage Specifies
the language (code page) of the
connected Lotus Notes and Domino
server.

msExchDirsyncSchedule Specifies
the times at which directory
synchronization is performed
automatically.

msExchDirsyncStyle Specifies
whether full or incremental directory
synchronization is performed.

msExchNotesNotesServer Specifies
the name of the Lotus Notes and Domino
server (in Notes format) that the
connector uses as the non-Exchange
bridgehead server.


msExchNotesForeignDomain Spe
cifies the name of the Lotus Notes nonExchange domain that represents the
429
Component
Description
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.
430
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.
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
431
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 Server 2003
Lotus Domino feature
feature
Lotus Domino to
to Lotus Domino
E-mail messages
E-mail messages
Yes
Yes
E-mail delivered
receipt
E-mail delivered
receipt
Yes
Yes
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
object
Embedded OLE
object
Yes
Yes
Embedded file
attachment
Embedded file
attachment
Yes
Yes
Message expiry date
Message expiry date
No
No
No feature
Reply By
No
No
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
432
Lotus Domino feature
feature
Lotus Domino to
to Lotus Domino
Meeting tentatively
accepted
Meeting accepted
Appears as accepted
Appears as accepted
Meeting request read
Yes
Yes
Meeting request
delivery
Meeting request
delivery
Yes
Yes
Meeting updates
Meeting updates
Appear as new
meeting requests
containing the word
"Updated" in the
subject line
Appear as new
meeting requests
containing the word
"Updated" in the
subject line
Meeting cancellation
Yes
Yes
Task requests
Tasks
Task requests appear Task requests appear
as e-mail messages
as e-mail messages
or tasks
All day meeting
requests
No feature
No
Appear as meetings
with midnight as the
start and end time
No feature
Phone messages
Appear as e-mail
messages
No
Other messages
Other messages
Default to e-mail
messages
Default to e-mail
messages
Note:
Connector for Lotus Notes does not support signed or encrypted messages.
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
433
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.
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.
434
Lotus Notes
Microsoft Outlook
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
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>).
435
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:
EndOfBuffer
436
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.
Note:
Microsoft does not officially support Novell GroupWise6.0 or later. However, because
the underlying technologies remain the same as in previous versions, Microsoft
437
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
Component
Description
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).
438
Component
Description
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 Active Directory.

Lsdxa.exe This is the directory
exchange manager that controls both
Dxagwise.dll and Dxamex.dll.

Lsmexin.exe This component obtains
converted messages from the READYIN
folder in the connector mailbox, verifies
439
Component
Description
Exchange Router for Novell GroupWise
service
Connector for Novell GroupWise uses a
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.
440
Component
Description
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 keywordbased 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\CurrentC
ontrolSet\Services\LMEGWISE\Parameters.
You must set this registry parameter
to a value of 0x1. Exchange 2003
then creates the \Archive directory in
the
\Programfiles\Exchsrvr\Conndata\Gw
router directory when you restart the
Exchange Router for Novell
GroupWise service. The \Archive
directory contains the following
subdirectories: \Dirsync, \Freebusy,
\Gw2mex, \Gw2mexa, \Mex2gw,
\Mex2gwa, and \Togwise.

\Badfiles This directory is for
441
Component
Description
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:
Registry settings

\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 nonGroupWise systems

\ATT_OUT Holds outgoing message
bodies and attachments to nonGroupWise 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
In the Registry, Connector for Novell
GroupWise settings are stored in the
following location:
HKEY_LOCAL_MACHINE\SYSTEM\Curren
tControlSet\Services\LME-GWISE.
442
Component
Description
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.
443
Component
Description
The msExchConnector object of Connector
for Novell GroupWise in the configuration
directory partition of Active Directory stores
most of the connector configuration settings.
The following attributes are specific to the
msExchGroupWiseConnector object class
that is derived from the msExchConnector
and mailGateway object classes:

exportCustomRecipients Specifies
whether mail-enabled contacts are
propagated to Novell GroupWise through


msExchServer1AlwaysCreateAs
Specifies how X.500 objects are
synchronized.

msExchDeliveryOrder Specifies 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

msExchPartnerLanguage Specifies
the language (code page) of the
connected Novell GroupWise post office.

msExchDirsyncSchedule Specifies
the times at which directory
synchronization is performed
automatically.

msExchDirsyncStyle Specifies
whether full or incremental directory
synchronization is performed.


msExchGWiseAPIGatewayPath S
pecifies the path to the Novell GroupWise
API Gateway directory.

msExchGWiseUserId Specifies the
name of the account that Connector for
Novell GroupWise uses to access the
Novell GroupWise API Gateway
directory.
444
Component
Description
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
Name>/Connectors.
Message Transfer
The following figure illustrates the process for sending messages from Exchange
Server 2003 to Novell GroupWise.
445
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 Exchange
Server 2003.
446
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:
447
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
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
GroupWise feature
feature
GroupWise to
to GroupWise
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
Meeting declined
Meeting declined
Yes
Yes
448
GroupWise feature
feature
GroupWise to
to GroupWise
Meeting tentatively
accepted
Meeting accepted
Appears as accepted
Appears as accepted
Yes
Yes
Meeting request
delivery
Meeting request
delivery
Yes
Yes
Meeting updates
Meeting updates
Appear as new
meeting requests
containing the word
"Updated" in the
subject line
Appear as new
meeting requests
containing the word
"Updated" in the
subject line
Meeting reminder
times
Meeting reminder
times
No
No
No
Yes
Task requests
Tasks
Task requests appear Tasks appear as
as e-mail messages
e-mail messages
All day meeting
requests
Meeting requests
Yes
Appear as meeting
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
messages
No
Other messages
Other messages
Default to e-mail
messages
Default to e-mail
messages
Note:
Connector for Novell GroupWise does not support signed or encrypted messages.
449
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
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.
450
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.
451
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
452
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-
7. The Exchange Router for Novell GroupWise service retrieves the .api file and places it in
the \Program Files\Exchsrvr\Conndata\Gwrouter\Dirsync directory.
453
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
Check Whether a Server Running Exchange Server Contains a Replica of the Free/Busy
System Folder for the Administrative Group.
454
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)
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).
455
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, timezone-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
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
456
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 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.
457
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
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
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
458
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 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).
459

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.
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.
460
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.
461
Calendar Connector components
Component
Description
462
Component
Description
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 Connector
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 Connector 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 nonExchange 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
free/busy items for new recipient
objects immediately. Use the
Schedule tab in
Calendar Connector to configure
the schedule.

Mapical.dll Calendar Connector loads
Mapical.dll to communicate with the
Exchange store. Mapical.dll populates
the free/busy records of non-Exchange
463
Component
Description
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 nonExchange 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
Registry settings
In the Registry, settings for the Connector for
Lotus Notes are stored in the following
location:
HKEY_LOCAL_MACHINE\SYSTEM\Curren
tControlSet\Services\MSExchangeCalCon.
464
Component
Description
The msExchConnector object of
Calendar Connector, in the configuration
directory partition of Active Directory, stores
most of the connector configuration settings.
The following attributes are 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 Sp
ecifies 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 nonExchange 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 S
pecifies the time frame within which
Calendar Connector considers the
free/busy records for non-Exchange
users to be most recent. Within the
msExchCalConRefreshInterval,
Calendar Connector returns existing data
to the Outlook client without sending a
free/busy request to the non-Exchange
messaging system.

msExchCalConProviders Specifies
465
Component
Description
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
Name>/Connectors.
Free/Busy Lookups to and from Lotus Notes
The following figure illustrates how Calendar Connector integrates with a Lotus Notes
messaging environment.
466
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.
467
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.
468
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.
469
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 specified under
470
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.
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).
471
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;
End-Time= 19/12/03 8:00; ,
;
Send-Options= None;
472
-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.
Note:
GroupWise users must have a visibility setting of System or higher to receive
calendar information from Exchange.
473
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..
474
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.
475

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
WebDAV WebDAV is an extension to HTTP that provides a Web interface to the
Microsoft Exchange Information Store service.
476
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.
477
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.
478
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.
479
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.
480
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.
481
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

ncacn_http

rpc_server
specifies an RPC object universal unique identifier (UUID).
selects the protocol sequence specification for RPC over HTTP.
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 by
RPC Proxy computer, rather than by the client. Because the client does not connect
482
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.
specifies the TCP/IP port that the RPC server process listens to for RPCs.

endpoint

HttpProxy

RPCProxy
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.
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.
483
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.
484
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.
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
485
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.
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.
486
Command
Description
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.
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.
487
Command
Description
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.
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
488
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.
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).
489
Command
Description
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.
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.
490
Command
Description
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."
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.
491
Command
Description
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.
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:
492

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.
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
493
as KeyType. Additionally, the Relative Distinguished Name of the object in the directory is
mapped directly to the key name in the metabase.
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.
494
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
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 frontend 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 frontend 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 frontend server:
495

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. 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:
496

Massync.dll
OMA Sync ISAPI extension DLL

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.
497
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.
498
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
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).
499
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.
500
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 email 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.
501
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.
502
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.
503

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
504
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
505
Outlook Mobile Access uses ASP.NET default, in-process session state handling, and the
modified URL method of session management.
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.
506
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.
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.
507
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:
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.
508
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
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-SMTPaddress
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.
509
Directory Setting
Description
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. 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.
510
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
HKLM\SYSTEM\CurrentControlSet\Services. The registry keys are described in the following
table.
Important Outlook Mobile Access registry values
Key
Value
Description
MasSync\Parameters\Exchan /Exchange or other string that Specifies what virtual
geVDir
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\Use
RegionalCharset
1 or anything
If this key is set to '1', then
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 email. The regional charset
used is determined based on
the client language the user
specifies.
511
Key
Value
Description
MSExchangeWEB\OWA\UseI 1 or anything
SO8859_15
When set to '1', the character
set iso-8859-15 is used
wherever the iso-8859-1
would have been used.
MSExchangeWEB\OWA\Use
GB18030
When set to '1', the character
set GB18030 is used
wherever the GB2312 would
have been used.
1 or anything
MSExchangeOMA\Performan N/A
ce
Used to publish Outlook
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
key="CredentialsTimeout"
value="60"></add>
Defines the number of
minutes Outlook Mobile
Access keeps Kerberos
tickets for DAV and Outlook
Web Access template access
cached.
<add
Defines the maximum
key="DefaultConnectionLimit" number of simultaneous
value="500"></add>
connections Outlook Mobile
Access can open to an
individual back-end server.
512
<system.web>
<browserCAPs>
<add
key="MaxServicePointIdleTi
me" value="60000"></add>
Tells Outlook Mobile Access
how many milliseconds to
wait for replies from the backend server before timing out.
<add
key="UnsupportedMessage"
value="http://<server>/OMAD
evices"></add>
When this message is
defined, additional text shows
up on the unsupported
warning and unsupported
error pages. By default this
key is null.
<sessionState
mode="InProc"
cookieless="true"
timeout="20" />
Specifies the session state
configuration that is used by
Outlook Mobile Access.
<mobileControls
SessionStateHistorySize="8"
>
Specifies how many 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
requestEncoding="utf-8"
responseEncoding="utf-8" />
Defines the default
characters set Outlook
Mobile Access uses to send
HTTP responses and
interpret incoming requests
without a character set
specified.
The timeout value indicated
for how many minutes the
session state is kept in
memory after the last request
arrives for the session.
supportsBackNavWithExpires Determines whether Outlook
Header
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.
513
preferredResponseCharset
Sets Response.Charset to
this value for all requests.
preferredResponseCodePag
e
Sets
Response.ContentEncoding
to the specified integer. Set
at the same time as
Response.Charset.
preferredRequestCodePage
Sets
Request.ContentEncoding to
the specified integer. Should
be set at the same time as
Response.Charset.
supportsOpenwaveUniversal
LocalSrc
Tells Outlook Mobile Access
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.
514
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).
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.
515

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. 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
516
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.
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
517
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
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
518
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.

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.
519
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.

<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:
520

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
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 faulttolerant 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
521
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.

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.
522

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
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-todate. 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.
523
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
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.
524
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
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.
525
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.
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:
526
Data type
Name
Value (in GB)
Default (in GB)
REG_DWORD
Database Size Limit
in GB
Standard: 1-75
Standard: 18
Enterprise: 1-8000
Enterprise: 8,000
Unlimited
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
Buffer Warning in
Percentage
1 - 100
10
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.
527
Data type
Name
Values
Default
Description
REG_DWORD
Database Size
Check Start
Time in Hours
from Midnight
1 - 24
5
Determines the
hour the first
database size
check will occur
after a database
is mounted.
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
528
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 version
Licensed limit
Default configuration limit
Standard Edition before SP2
16 GB
Not applicable
Standard Edition with SP2
75 GB
18 GB
Enterprise Edition before SP2 8,000 GB (unlimited)
Not applicable
Enterprise Edition with SP2
8,000 GB
8,000 GB (unlimited)
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:
529

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 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.
530

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 inmemory 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
531
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.

ibMicFree This value indicates the page offset for the next available byte at the top of
the page.
532
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:

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.
533
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.
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.
534
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
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
535
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
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.
536
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 longvalue 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.
537
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
Long
Unsigned Long
LongLong
Currency
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.
538
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.
539
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 Service
Replicates Exchange information in the
organization.
Microsoft Exchange System Attendant
service
Monitors Exchange and provides essential
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).
540
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 defragmentation and remain
fragmented until an offline defragmentation is performed.
541


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.
DBA uses a patented formula to determine how the buffer cache size should grow or shrink
over time.
542
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
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
543
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 nonIPM_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 nonIPM_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.
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
544
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 email 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.
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
545
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
messages (0x2)
A hierarchy replication
message is a replication
message between replicas of
a special folder with the ID 11 (FID 1-1).
Replicates hierarchy changes
from one public folder store
to all other public folder
stores in the same top level
hierarchy.
Content replication messages Content replication messages Replicates content changes
(0x4)
replicate content updates
from one replica to all other
between replicas of individual content replicas of that folder.
folders. A public folder store
only sends a content
replication to another public
folder store that holds a
replica of the folder.
546
Message Type
Description
When Used
Backfill request messages
(0x8)
Backfilling is the process by
which public folder stores that
miss replication updates can
request a re-send of missing
data. There are two parts to
the backfill process: backfill
request and backfill
response. When a public
folder store determines that it
is not 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 request messages
request missing data (in
CNSets) from another public
folder store (both hierarchy
and content). Backfill request
messages are sent only to
other content replicas of the
folder (all top level hierarchy
members, if this is for the
hierarchy).
Backfill response messages
Backfill responses are
(0x80000002 or 0x80000004) structurally identical to their
regular counterparts, but are
sent in response to a backfill
request and are addressed
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.
Backfill response messages
send missing data to a public
folder store that requested
missed updates (CNSets).
547
Message Type
Description
When Used
Status messages (0x10)
A status message is sent in
response to a status request.
It contains the complete
CNSet of owned changes on
this server. This set does not
necessarily represent all the
changes that actually
occurred, because all
changes might not have
replicated to this specific
public folder store.
Sends the current CNSets of
a folder to another replica of
that folder. Used for hierarchy
(replicas of folder 1-1) and
content (specific content
replicas).
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.
548
Message Type
Description
When Used
Status request messages
(0x20)
Sends the folder's current
CNSet to all other replicas. It
simultaneously requests that
some subset of those
replicas return their own
CNSet. This response comes
as a status message. The
requested server does not
respond if the requesting
server's CNSet is not a strict
subset of the requested
server's set.
The Exchange store sends a
status request message in
the following situations:

An existing replica of a
public folder might have
missed replication
messages or might have
been restored from an
outdated backup. A
status request message
is 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 folder was
removed from a public
folder store. A removed
public folder also
generates a status
request because the
content of the hierarchy
folder (FID 1-1) was
changed.
549
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
550
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.
551
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-todate 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).
552

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.

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.
553

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.
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.)
554
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.
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.
555
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 Exchange
System Manager.
Replication Send Folder Tree
5 minutes
This is how often the public
folder store checks to see
whether a hierarchy
replication message needs to
be sent.
Replication Send Status
Timeout
24 hours
folder store checks to see
whether a status message for
a folder should be sent.
Replication Timeout
5 minutes
folder store checks to see if
any backfill entries have
timed out.
Replication New Replica
Backfill Request Delay
15 minutes
This is the time delay used
before sending a backfill
request for a new folder
replica when the data is
available on the same site.
556
Replication Event
Default Timeout
Comments
Replication Short Backfill
Request Delay
6 hours
request when the data is
Replication Long Backfill
Request Delay
12 hours
request when the data is not
Request Timeout
12 hours
This is the timeout value
used when retrying to send a
backfill request when the
data is available on the same
site.
Request Timeout
24 hours
used when retrying to send a
backfill request when the
data is not available on the
same site
Request Timeout Retry
24 hours
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.
Request Timeout Retry
48 hours
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.
Default Replication Values
The following table illustrates some of the other default values used in public folder
replication.
557
Default replication values
Description
Value
Comments
Replication Folder Count
Limit
20
Maximum number of folders
to pack in a hierarchy
replication message.
Replication Deleted Folder
Count Limit
500
Maximum number of folder
deletes to pack in a hierarchy
replication message.
Replication Message Count
Limit
100
Maximum number of
messages to pack in a
content replication message.
Replication Message Size
Limit
300 KB
Maximum replication
message size. This value can
be adjusted using Exchange
System Manager. 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
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.
558
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.
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
559
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).
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
560
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
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.
561
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 applicationspecific 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

Microsoft Exchange Server 2003 Technical Reference Guide

Transcription

Similar documents

RM People Directory Quick Start - RM

NY MTA Presentation.pptx

Go to www.jiminypeak.com and click on Employee Login

HOW IT WORKS:

CCNP Flyer

OSS Identity Management

AIRMAN`S INFORMATiON MANUAL

Switch Kit - SeaComm Federal Credit Union

March 2014 Motor Pool Messenger - Military Transport Association

softail - Fuelpak