Microsoft Exchange Server 2003 Technical Reference Guide

Microsoft Corporation Published: December 12, 2006 Author: Exchange Server Documentation Team

Abstract
This guide is for Exchange Server experts who require detailed information about the architecture and interaction among core components of Microsoft Exchange Server 2003. Comments? Send feedback to exchdocs@microsoft.com.

Contents
Microsoft Exchange Server 2003 Technical Reference Guide..................................................1 Contents................................................................................................................................... 3 Technical Reference Guide for Exchange Server 2003..........................................................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...........................................................................26 Exchange Classes and Attributes in Active Directory..........................................................27 Directory Access Architecture.............................................................................................. 27 The Message Transport.......................................................................................................... 28 Message Routing Architecture............................................................................................ 28 Message Routing with Routing Groups...............................................................................29 The Exchange Message Store...............................................................................................31 Exchange Server 2003 Database Technology....................................................................31 Stores and Storage Groups.................................................................................................32 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...........................................................154 Message Routing Architecture..............................................................................................156 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..............................................................................167 Initializing the Link State Table..........................................................................................167 Routing Engine and Exchange Routing Engine Service....................................................168 Examining the Link State Table......................................................................................... 169 Exchange Routing Path Selection.....................................................................................186 Routing Path Selection Process........................................................................................189 Dijkstra's Shortest-Path Algorithm.....................................................................................190 Message Transfer Load Balancing....................................................................................193 Load Balancing between Routing Groups.........................................................................194 Load Balancing between Connectors and External Systems............................................196 Message Rerouting Based on Link State Information.......................................................197 Message Rerouting........................................................................................................... 197 Rerouting and Address Spaces.........................................................................................199 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................................................................................................... 233 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.......................................................................................................... 262

Content Conversion........................................................................................................... 264 IMAIL................................................................................................................................. 265 TNEF................................................................................................................................. 265 Public Folder Message Handling.......................................................................................267 Categorizer Performance Tuning......................................................................................268 Global Catalog Load Balancing......................................................................................... 271 LDAP Search Batches....................................................................................................... 272 Message Re-Categorization.............................................................................................. 274 Alternate Data Streams in the \Queue Directory...............................................................274 Forcing Re-Categorization................................................................................................276 SMTP Service Store Drivers.................................................................................................277 NTFS Store Driver............................................................................................................. 278 Relocating the \Mailroot Directory.....................................................................................280 Exchange Store Driver...................................................................................................... 281 Exchange Store Driver Architecture..................................................................................282 Exchange Installable File System.....................................................................................284 Outbound Message Transfer.............................................................................................286 Inbound Message Transfer................................................................................................289 Transfer Retries................................................................................................................. 291 SMTP Protocol Extensions................................................................................................... 291 Protocol Event Categories................................................................................................. 296 Exchange-Specific SMTP Protocol Extensions.................................................................298 For More Information......................................................................................................... 303 Protocol Logging, Event Logging, and Message Tracking....................................................303 Protocol Logging............................................................................................................... 304 Event Logging................................................................................................................... 305 Field Engineering Logging................................................................................................. 305 Message Tracking............................................................................................................. 305 How to Enable Diagnostics Logging for the SMTP Service in Exchange System Manager..306 Before You Begin.............................................................................................................. 306 Procedure.......................................................................................................................... 307 How to Set the Diagnostics Logging Level for MSExchangeTransport Categories to Field Engineering....................................................................................................................... 307 Before You Begin.............................................................................................................. 307 Procedure.......................................................................................................................... 308 For More Information......................................................................................................... 308 How to Enable Message Tracking in Exchange System Manager........................................308 Before You Begin.............................................................................................................. 308 Procedure.......................................................................................................................... 309

Reference.......................................................................................................................... 309 X.400 Transport Architecture................................................................................................ 309 Exchange MTA in Exchange Server 2003 Architecture.........................................................311 Exchange MTA Communication Partners..........................................................................311 Exchange MTA Configuration Settings in Active Directory................................................315 Internal Exchange MTA Architecture.................................................................................320 Exchange MTA Database.................................................................................................. 324 Relocating the MTA Database Directory............................................................................326 Secured and Unsecured Message Copies........................................................................328 MTA Database in a Server Cluster....................................................................................329 Corrupted Messages in Gateway Queues.........................................................................329 Fixing MTA Database Corruption.......................................................................................330 Wiping the MTA Database.................................................................................................330 Replaying DAT Files.......................................................................................................... 331 Examining Exchange MTA Processing..............................................................................332 Checking the Exchange MTA Using System Monitor........................................................332 Exchange MTA Event Logging.......................................................................................... 336 Text Event Logging............................................................................................................ 339 Trace Level Logging.......................................................................................................... 340 MTA Check Logging.......................................................................................................... 341 Object IDs and Message IDs............................................................................................. 341 How to Wipe the MTA Database........................................................................................... 342 Before You Begin.............................................................................................................. 342 Procedure.......................................................................................................................... 342 For More Information......................................................................................................... 343 How to Replay DAT Files After an MTA Database Wipe.......................................................343 Before You Begin.............................................................................................................. 344 Procedure.......................................................................................................................... 344 Reference.......................................................................................................................... 344 How to Replay DAT Files After an MTA Database Wipe via a Complete Replay..................344 Before You Begin.............................................................................................................. 344 Procedure.......................................................................................................................... 345 For More Information......................................................................................................... 346 How to Replay DAT Files After an MTA Database Wipe via a Remote Replay.....................347 Before You Begin.............................................................................................................. 347 Procedure.......................................................................................................................... 348 For More Information......................................................................................................... 348 How to Replay DAT Files After an MTA Database Wipe via an Incremental Replay.............349 Before You Begin.............................................................................................................. 349

Procedure.......................................................................................................................... 349 For More Information......................................................................................................... 350 MTA Transport Stacks and X.400 Connectors......................................................................351 Message Transfer Service................................................................................................. 352 Reliable Transfer Service.................................................................................................. 357 Association Control Service.............................................................................................. 359 Presentation and Session Services...................................................................................360 MTA Transport Stacks....................................................................................................... 362 MTA Communication Example.......................................................................................... 365 X.400 Connectors............................................................................................................. 367 Configuring an X.400 Connector.......................................................................................367 Connect Request Information............................................................................................ 369 Outgoing and Incoming OSI Address Information.............................................................370 X.400 Addresses............................................................................................................... 370 X.400 Address Spaces...................................................................................................... 371 Conformance Year and Body Parts...................................................................................373 Message Loop Detection................................................................................................... 375 X.400 Connector Objects in Active Directory.....................................................................377 Running Multiple X.400 Connectors..................................................................................382 Connecting Routing Groups Using X.400 Connectors..........................................................384 Load Balancing between Routing Groups.........................................................................385 Message Routing over Exchange MTAs...........................................................................386 SMTP XAPI Gateway........................................................................................................ 386 Exchange MTA Message Transfer.....................................................................................388 Link State Information and Message Rerouting................................................................390 Exchanging Link State Information Between Routing Groups...........................................391 Exchange MTA in a Mixed-Mode Organization.....................................................................392 RPC-Based MTA Communication.....................................................................................393 RPC Performance Impact.................................................................................................394 RPC Bindback Error.......................................................................................................... 395 Gateway Address Routing Table.......................................................................................395 Message Loops Between Exchange Server 5.5 and Exchange Server 2003...................397 Gateway Messaging Connectors Architecture......................................................................397 EDK Connector Architecture.................................................................................................398 Connector Components.................................................................................................... 400 Message Transfer to and from Exchange Server 2003.....................................................408 Outbound Message Transfer.............................................................................................409 Inbound Message Transfer................................................................................................410 MAPI Profiles for MAPI-Based Connectors.......................................................................410 Message Conversion......................................................................................................... 412

Address Translation........................................................................................................... 413 Proxy Addresses and One-Off Addresses.........................................................................414 Address Mapping Issues................................................................................................... 415 Message Conversion......................................................................................................... 416 Directory Synchronization.................................................................................................418 Directory Synchronization from a Non-Exchange Messaging System to an Exchange Organization.................................................................................................................. 418 Directory Synchronization from an Exchange Organization to a Non-Exchange Messaging System........................................................................................................................... 420 How to Open a Connector Mailbox Using Mdbvu32.exe......................................................422 Before You Begin.............................................................................................................. 422 Procedure.......................................................................................................................... 422 Connector for Lotus Notes Architecture................................................................................423 Message Transfer............................................................................................................. 430 Message Conversion......................................................................................................... 431 E-Mail Message Type Conversion.....................................................................................433 E-Mail Message Property Mapping...................................................................................434 Directory Synchronization.................................................................................................435 Connector for Novell GroupWise Architecture......................................................................437 Message Transfer............................................................................................................. 445 Message Conversion......................................................................................................... 448 E-mail Message Type Conversion.....................................................................................450 E-mail Message Property Conversion...............................................................................450 Directory Synchronization.................................................................................................452 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............................................................................................................................... 490 NNTP................................................................................................................................ 493 Configuration Settings in Active Directory.........................................................................494 Configuration Settings in the Metabase.............................................................................494 IIS Metabase Updates Through DS2MB...........................................................................495 High Water Marks.............................................................................................................. 495 Front-End Server Architecture........................................................................................... 495 Considerations When Using Front-End Servers................................................................496 Exchange ActiveSync and Exchange 2003..........................................................................497 Exchange ActiveSync Protocol Architecture......................................................................498 Sync Protocol Versions and Device Support.....................................................................500 Sync Protocol Commands.................................................................................................500 Sync Command Format.................................................................................................... 501 URI.................................................................................................................................... 501 HTTP Header.................................................................................................................... 502 HTTP Body........................................................................................................................ 502

Protocol-Independent Multicast Data on the Mobile Device..............................................502 Exchange ActiveSync Profile............................................................................................503 Up-to-Date Notification...................................................................................................... 503 Aggregators....................................................................................................................... 504 Outlook Mobile Access and Exchange 2003.........................................................................504 Outlook Mobile Access Dependencies..............................................................................505 Outlook Mobile Access and .NET......................................................................................505 .NET Framework............................................................................................................... 505 ASP.NET........................................................................................................................... 506 Session Management........................................................................................................ 506 Modified URL Session ID.................................................................................................. 507 ASP.NET Device Updates................................................................................................. 507 Outlook Mobile Access Architecture..................................................................................507 Outlook Mobile Access and Microsoft Outlook Web Access Templates............................508 Outlook Mobile Access Data Sources...............................................................................508 Outlook Mobile Access Directory Settings.........................................................................509 Outlook Mobile Access and DS2MB..................................................................................511 Outlook Mobile Access and the Windows Registry............................................................511 Outlook Mobile Access and Web.Config...........................................................................513 Outlook Mobile Access Client Requests............................................................................515 Outlook Mobile Access Security Architecture....................................................................515 Exchange Information Store Service Architecture................................................................516 Exchange Storage Architecture............................................................................................ 517 Storage Groups................................................................................................................. 518 Storage Group Architecture............................................................................................... 519 Storage Group Attributes in Active Directory.....................................................................521 Storage Group Minimum Disk Space Requirements.........................................................523 Exchange Store Databases...............................................................................................523 MAPI Database File.......................................................................................................... 524 Streaming Database File................................................................................................... 524 Property Promotion........................................................................................................... 525 Database Size Limit Configuration and Management...........................................................526 Registry Settings............................................................................................................... 526 Database Size Limit in GB................................................................................................527 Database Size Buffer Warning in Percentage...................................................................528 Database Size Check Start Time in Hours from Midnight..................................................528 Behavior When the Configured Database Size Limit or Licensed Database Size Limit Are Reached........................................................................................................................ 529 Licensed Database Size Limit...........................................................................................529 Disaster Recovery Planning Considerations.....................................................................530

Extensible Storage Engine Architecture...............................................................................530 Transactions...................................................................................................................... 531 ACID Transactions............................................................................................................ 531 The Version Store............................................................................................................. 532 Snapshot Isolation............................................................................................................. 532 ESE Database Structure................................................................................................... 533 Database Pages................................................................................................................ 533 ECC Checksum................................................................................................................. 534 Database Consistency and -1018 Errors...........................................................................534 Database Tree Balancing.................................................................................................. 536 Split................................................................................................................................... 537 Merge................................................................................................................................ 537 Fan-Out............................................................................................................................. 537 Indexes.............................................................................................................................. 537 Long-Values...................................................................................................................... 538 Record Format.................................................................................................................. 538 Column Data Types........................................................................................................... 538 Fixed and Variable Columns............................................................................................. 540 Tagged Columns............................................................................................................... 540 Responsibilities of the Information Store..............................................................................540 Interactivity with other Exchange Services........................................................................540 Space Management.......................................................................................................... 542 Database Defragmentation...............................................................................................542 Buffer Management........................................................................................................... 543 Dynamic Buffer Allocation................................................................................................. 543 The LRU-K Replacement Algorithm..................................................................................544 Public Folder Replication...................................................................................................... 544 Public Folder Database Trees...........................................................................................545 Replication Overview......................................................................................................... 545 Packing and Unpacking..................................................................................................... 546 Change Numbers.............................................................................................................. 546 Replication Message Types..............................................................................................547 Replication Process........................................................................................................... 551 Hierarchy Replication........................................................................................................ 551 Content Replication........................................................................................................... 552 Backfilling.......................................................................................................................... 552 Backfill Array..................................................................................................................... 553 Replication Status............................................................................................................. 553 Replication Status Thread................................................................................................. 554 Replication Status Requests.............................................................................................554 Modifying the Replica List.................................................................................................555 Adding a Replica............................................................................................................... 555

Deleting a Replica............................................................................................................. 555 Replication State Tables.................................................................................................... 556 Default Replication Event Schedule..................................................................................557 Default Replication Values................................................................................................558 Exchange Server 2003 Cluster Architecture.........................................................................559 Windows Cluster Architecture............................................................................................... 560 Server Clusters................................................................................................................. 561 Server Cluster Architecture............................................................................................... 562 Cluster Service Components............................................................................................. 563 Cluster Failover................................................................................................................. 568 Cluster Failback................................................................................................................ 568 Cluster Quorum................................................................................................................. 569 Standard Quorum.............................................................................................................. 569 Majority Node Set Quorums.............................................................................................. 570 Cluster Resources............................................................................................................. 571 Cluster Administration....................................................................................................... 571 Cluster Formation and Operation......................................................................................572 Creating a Cluster............................................................................................................. 572 Forming a Cluster.............................................................................................................. 572 Joining a Cluster............................................................................................................... 573 Leaving a Cluster.............................................................................................................. 574 Failure Detection............................................................................................................... 574 Exchange Virtual Servers..................................................................................................... 575 Exchange Components in a Cluster..................................................................................576 Active/Active Clusters........................................................................................................ 578 Active/Passive Clusters..................................................................................................... 579 Resource Dependencies................................................................................................... 580 Microsoft Exchange System Attendant Service.................................................................580 Microsoft Exchange Information Store Service.................................................................581 Message Transfer Agent................................................................................................... 581 Protocols........................................................................................................................... 581 Microsoft Search............................................................................................................... 582 Exchange Cluster Interaction................................................................................................582 ExchangeOpen/ExchangeClose Functions.......................................................................583 ExchangeOnline and ExchangeOffline Functions.............................................................583 ExchangeIsAlive and ExchangeLooksAlive.......................................................................584 ExchangeTerminate........................................................................................................... 584 Creating Resources........................................................................................................... 584 Cluster-Specific Configurations............................................................................................585 Exchange MTA.................................................................................................................. 585

IIS SMTP Logging............................................................................................................. 585 AntiAffinityClassNames..................................................................................................... 586 MAPI Public Stores........................................................................................................... 587 Eseutil............................................................................................................................... 587 Installing Updates.............................................................................................................. 587 How to Disable MTA Monitoring on an Exchange Virtual Server..........................................588 Before You Begin.............................................................................................................. 588 Procedure.......................................................................................................................... 588 How to Enable SMTP Logging and Log the Files to a Shared Disk......................................589 Before You Begin.............................................................................................................. 589 Procedure.......................................................................................................................... 589 How to Create an HTTP Virtual Server in Exchange System Manager................................590 Before You Begin.............................................................................................................. 590 Procedure.......................................................................................................................... 590 How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster .......................................................................................................................................... 592 Before You Begin.............................................................................................................. 592 Procedure.......................................................................................................................... 592 For More Information......................................................................................................... 593 How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster.................................................................................................... 594 Before You Begin.............................................................................................................. 594 Procedure.......................................................................................................................... 594 Copyright.............................................................................................................................. 595

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

25

user account is an Active Directory object that has a unique security identifier (SID) assigned to it. This identifier enables the user to access resources in the Active Directory domain. When a user account is mailbox-enabled, it has a mailbox on a server running Exchange Server, which enables the user to send and receive e-mail messages using a supported client, such as Microsoft Office Outlook. Mail-enabled user accounts A mail-enabled user has an e-mail address but does not have a mailbox on a server running Exchange Server. A mail-enabled user account has a SID and can access resources in the Active Directory domain, but the e-mail address that is used to mail-enable the user account refers to a mailbox in a nonExchange 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.

26

Configuration Information in the Directory

Exchange Server 2003 stores most of the configuration information for the Exchange organization in Active Directory. Active Directory contains detailed information on server objects, containers for administrative and routing groups, and all of the Exchange connectors. This information specifies how each server running Exchange Server is configured, the number of storage groups and stores on each server, and the Internet Information Services (IIS) server configuration. Exchange configuration information is stored in the configuration directory partition in Active Directory. Some of the information that is stored in the configuration partition is show in the following figure. Because Active Directory replicates the configuration partition between all domains in the forest, the Exchange organization is also replicated throughout the forest. However, the configuration partition cannot be replicated outside the forest. This means that an Exchange organization cannot span multiple forests. However, it is possible to implement multi-forest topologies in an Exchange organization. For more information about Exchange multi-forest topologies, see the Exchange Server 2003 Deployment Guide. Viewing Exchange information in Active Directory by using adsiedit.msc

27

Exchange Classes and Attributes in Active Directory

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

Directory Access Architecture

The connection between Exchange Server 2003 and Active Directory is critical for reliable server operation. Exchange Server 2003 uses the following two primary components to locate and communicate to Active Directory domain controllers: DSAccess This component controls how other Exchange components access Active Directory. DSAccess reads the Active Directory topology, detects domain controllers and global catalog servers, and maintains a list of valid directory servers that are suitable for use by Exchange components. In addition, DSAccess contains a memory cache, which reduces the load on Active Directory by reducing the number of LDAP requests that individual components must send to Active Directory servers. For example, in order to route messages, the transport process uses DSAccess to obtain information about the connector arrangement. The SMTP transport engine also uses DSAccess to resolve recipient information. This enables messages to be routed to the servers on which the mailboxes reside. DSProxy This component provides an address book service for MAPI clients running Outlook 2002 Service Release 1 (SR-1) and earlier versions. Exchange versions 5.5 and earlier implemented a directory service so that clients could view the global address list by querying the server running Exchange Server. In Exchange 2000 Server and Exchange Server 2003, DSProxy emulates this address book service. Note: Directory Service Proxy (DSProxy) refers Microsoft Outlook 2003 directly to a global catalog server. Unlike earlier versions of Outlook, Outlook 2003 does not require a directory proxy component on the server running Exchange Server itself. For detailed information about DSAccess and DSProxy, see Exchange Server 2003 and Active Directory.

28

The Message Transport

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

Message Routing Architecture

In an Exchange Server 2003 organization, all messages are routed using SMTP. The SMTP protocol is also supported by all Internet messaging servers. If a server running Exchange Server sends a message to another messaging server that only supports the X.400 messaging protocol, the SMTP component in Exchange Server 2003 is responsible for routing the message. To accomplish this functionality, the SMTP component includes several subcomponents. The following components are involved in every message transfer on a server running Exchange Server 2003: SMTP service The SMTP service handles the SMTP communication between remote SMTP hosts and clients. This service implements the SMTP protocol commands that Exchange Server 2003 supports. Store driver The store driver allows the SMTP service to communicate with the Exchange store to save messages that are passing through the SMTP service. The store driver also handles the delivery of messages for local recipients. Advanced queuing engine The advanced queuing engine provides queue management and logic for message delivery, routing, and relaying. Categorizer The categorizer provides categorization services for inbound and outbound messages. This component is also responsible for distribution list expansion using the LDAP and Active Directory. Routing engine The routing engine provides the routing logic necessary to pass outbound messages to the correct messaging connector or SMTP virtual server. Queue manager The queue manager controls link queues. Link queues are used to store messages that are waiting for transfer to the next remote destination. For detailed information on message routing architecture and the relationships between these components, see Message Routing Architecture.

29

Message Routing with Routing Groups

Exchange Server 2003 uses routing groups to manage message delivery within an Exchange organization. A routing group is a collection of servers running Exchange Server that are connected by permanent network links. Message delivery within a single routing group has the following characteristics: All message delivery is point to point Within a single routing group, messages are always delivered from the sender's server running Exchange Server directly to the recipient's server running Exchange Server. Messages are never routed among multiple servers. All message delivery between Exchange Server 2003 servers uses SMTP Exchange Server 2003 servers will always use SMTP to deliver messages to other Exchange Server 2003 servers in the same routing group. Messages are delivered as soon as the messages are received Message delivery within a single routing group cannot be scheduled. If one of the servers running Exchange Server in a routing group is offline, the other servers running Exchange Server in the routing group will queue all messages to be sent to that offline server. Message delivery is automatically configured between Exchange Server 2003 servers in the same routing group There is no way for an administrator to modify the message flow within a single routing group. Message delivery within a single routing group is illustrated in the following figure. Message routing in single routing group

Exchange Server 2003 supports the use of multiple routing groups. Message delivery between routing groups has the following characteristics: Routing group connectors must be configured between the routing groups.

All messages sent between routing groups flow through bridgehead servers in each routing group.

30

Message delivery between routing groups can be configured. Configuration options include scheduling message delivery, limiting message size, and restricting users or groups from sending messages across the connector. The following figure illustrates message routing between multiple routing groups. Message routing between multiple routing groups

Exchange Server 2003 supports the following three routing group connectors: Routing group connector The routing group connector is the recommended connector for connecting routing groups that are in the same Exchange organization. This connector uses SMTP to transfer messages to other servers running Exchange Server 2003. The routing group connector can only be used to connect routing groups. SMTP connector The SMTP connector establishes a messaging route between two routing groups or between a routing group and a non-Exchange SMTP host. Although the routing group connector and the SMTP connector use SMTP as the transport protocol, the SMTP connector provides additional functionality in that it can be used to connect an Exchange organization with any SMTP server. X.400 connector The X.400 connector establishes an X.400 messaging route between two routing groups or between a routing group and an X.400 system. Like 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.

31

Exchange Server 2003 supports the following optional connectors that you can use to connect the organization to non-Exchange messaging systems: Exchange Connector for Lotus Notes Exchange Connector for Lotus Notes is used for message routing and directory synchronization between an Exchange organization and a Lotus Notes messaging system. Exchange Connector for Novell GroupWise Exchange Connector for Novell GroupWise is used for message routing and directory synchronization between an Exchange organization and a Novell GroupWise messaging system. Exchange Calendar Connector Exchange Calendar Connector is used for exchanging free/busy information between an Exchange organization and a Lotus Notes or Novell GroupWise messaging system.

The Exchange Message Store

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

Exchange Server 2003 Database Technology

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

32

Stores and Storage Groups

You can split the Exchange store into multiple storage groups and stores. A storage group is a group of databases that share a single transaction log. A store is a single database than contains the mailbox or public folder contents. In Exchange Server 2003, you can configure up to four storage groups on each server running Exchange Server. Each storage group can contain up to five stores. Exchange Server 2003 also includes an additional, dedicated Recovery Storage Group. The Recovery Storage Group can be used to restore mailboxes or stores while the other stores remain online. For more information about storage groups and the Recovery Storage Group, see Exchange Information Store Service Architecture. The following figure shows one possible storage group and store configuration on a server running Exchange Server. Stores and storage groups on a server running Exchange Server

The primary reason for deploying multiple storage groups and stores is to reduce the size of each individual database while still supporting many users on one server. Having multiple smaller stores enhances Exchange Server backup and recovery. Because all of the stores in a storage group share a transaction log, each storage group should be backed up as a whole. If your backup infrastructure supports multiple backup streams, you can back up multiple storage groups at the same time. If you must restore data on the server running Exchange Server, you restore each store individually. When you restore each store, you can mount it and make it available to users. 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

33

Recovery Storage Group, you can restore individual mailboxes without disconnecting unaffected users from the server.

User Agents in an Exchange Server 2003 Organization

User agents are messaging clients that the recipients use to access their mailboxes on the server running Exchange Server. Exchange Server 2003 supports several different client access protocols. The following table lists the supported messaging protocols. Supported messaging protocols in an Exchange Server 2003 organization Protocol MAPI Description 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." Exchange uses HTTP to provide access to the message store through Outlook Web Access, Exchange ActiveSync, and Outlook Mobile Access. 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.

HTTP

POP3

34

Protocol IMAP4

Description 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 is used for accessing newsgroups. You can configure Exchange to publish portions of the public folder hierarchy and make them available to NNTP clients.

NNTP

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 clienta 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 (autostart 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. 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

39

represents the standard configuration of System Attendant (command line: sc qc MSExchangeSA):

SERVICE_NAME: MSExchangeSA TYPE : 10 WIN32_OWN_PROCESS

ERROR_CONTROL BINARY_PATH_NAME LOAD_ORDER_GROUP TAG DISPLAY_NAME

: 1

NORMAL

: "C:\Program Files\Exchsrvr\bin\mad.exe" : : 0 : 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 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

40

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.

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

41

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: 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

42

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
DependOnGroup

Type REG_MULTI_SZ

Description 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. 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. Describes the service. The description is simply a comment that explains the purpose of the service.

DependOnService

REG_MULTI_SZ

Description

REG_SZ

44

Value
DiagnosticsMessageFile

Type REG_SZ

Description 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. 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.

DisplayName

REG_SZ

45

Value
ErrorControl

Type REG_DWORD

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

46

Value
FailureActions

Type REG_BINARY

Description 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). 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. 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.

Group

REG_SZ

ImagePath

REG_EXPAND_SZ

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.

47

Value
Start

Type REG_DWORD

Description Specifies when to start the service. SCM can start a service automatically during system startup, or when a process requests the service start. This value can also specify that a service cannot be started and that attempts to start the service should result in the error code ERROR_SERVICE_DISABLE D. Determines the service startup order within a loadordering group. Tags are only evaluated for driver services. 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 Exchangespecific file system driver.

Tag

REG_DWORD

Type

REG_DWORD

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

48

registry key. This enables the Windows configuration manager to enumerate the services as logical devices during system boot. Parameters This key contains registry parameters for service-specific configuration information. The Parameters key can contain further subkeys. Performance This key provides counters for performance monitoring. The REG_SZ parameter Library specifies the DLL that contains the performance counters. Further keys exist for the performance counters. For example, the REG_SZ parameter PerfIniFile refers to the .ini file that defines the individual performance counters. Security This key holds a REG_BINARY parameter called Security that contains a service security descriptor that specifies which accounts can control the service. For example, an administrator may have permissions to start and stop a service, while a regular user does not. Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Operating System Services

Exchange Server 2003 relies heavily on the operating system for network communication, security, directory services, and so forth. For example, Exchange Server 2003 requires TCP/IP and depends on the TCP/IP protocol stack and related components. These components are implemented in kernel drivers deeply integrated into the Windows I/O subsystem. Exchange Server 2003 uses standard Microsoft Win32 programming interfaces to interact with the kernel. In addition to the Windows kernel, Exchange Server 2003 has the following Windows services dependencies: Event Log This service enables event log messages issued by Exchange services and other Windows-based programs and components to be viewed in Event Viewer. This service cannot be stopped. NTLM Security Support Provider This service provides security for programs that use remote procedure calls (RPCs) and transports other than named pipes to log on to the network using the NTLM authentication protocol. 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).

49

RPCs and lightweight remote procedure calls (LRPCs) are important inter-process communication mechanisms. LRPCs are local versions of RPCs. LRPCs are used between the Exchange store and those server components that depend on MAPI and related APIs for communication, such as messaging connectors to non-Exchange messaging systems. Regular RPCs, however, are used when clients must communicate with server services over the network. Typical RPC clients are MAPI clients, such as Microsoft Outlook and Exchange System Manager, but internal components of System Attendant, such as DSProxy, are also RPC clients. To accept directory requests from MAPI clients and pass them to an address book provider, DSProxy must use RPCs to communicate with Active Directory through the name service provider interface (NSPI). For more information about DSProxy, see Exchange Server 2003 and Active Directory. It is important to understand that RPCs are an application-layer communication mechanism, which means that RPCs use other network communication mechanisms, such as NetBIOS, named pipes, or Windows Sockets, to establish the communication path. To create a connection, the RPC endpoint mapper is required, because the client must first determine the endpoint that should be used. RPC server services use dynamic connection endpoints, by default. In a TCP/IP network, the client connects to the RPC endpoint mapper through TCP port 135, queries for the current TCP port of the desired service (for example, the Name Service Provider Interface (NSPI) port of Active Directory), obtains this TCP port from the endpoint mapper, and then uses this TCP port to establish the RPC connection to the actual RPC server. The following figure illustrates the role of the RPC endpoint mapper. Establishing an RPC connection to Active Directory

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

50

registry parameters. However, the client must contact the RPC endpoint mapper whether the port assignment is dynamic or static. Server This service enables file and printer sharing and named pipe access to the server through the server message block (SMB) protocol. For example, if you access message tracking log files using the message tracking center in Exchange System Manager, you communicate with the server service because message tracking logs are shared for network access through \\<server name>\<server name>.Log, such as \\Server01\Server01.log. The SMB protocol is also required for remote Windows administration. The SCM key for the server service is lanmanserver. Underneath this registry key, you can find an important subkey called Shares. This key contains parameters for all shares on the server. One share that is particularly important for System Attendant is Address, which provides access to the proxy address generation DLLs that the Recipient Update Service uses to assign mailbox-enabled and mail-enabled recipient objects, X.400, SMTP, Lotus Notes, Microsoft Mail, Novell GroupWise, and Lotus cc:Mail addresses according to the settings in recipient policies. Address generation DLLs are accessed over the network, because gateway connectors (and their address generation DLLs) do not necessarily exist on the local server running Exchange Server. Recipient Update Service is part of System Attendant, so the server service must be started before System Attendant can start. Workstation This service is the counterpart to the server service. It enables the computer to connect to other computers on the network based on the SMB protocol. This service must be started before System Attendant will start. Security Accounts Manager The Security Accounts Manager (SAM) service stores security information for local user accounts and is required for local accounts to log on to the server. Because all Exchange services must log on to the local computer using the LocalSystem account, Exchange Server 2003 cannot function if this component is unavailable. Windows Management Instrumentation This service provides a standard interface and object model for accessing management information about the computer hardware and software. System Attendant is the component in Exchange Server 2003 that is responsible for server monitoring and status. Exchange Server 2003 adds additional Windows Management Instrumentation (WMI) providers to the WMI service, so that you can access Exchange status information through WMI. The WMI service is required for the Microsoft Exchange Management service to start. 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

51

Server 2003, because event sinks wrapped in a COM+ component application that run out-of-process on the server will not function properly. COM+ System Application This service manages the configuration and tracking of COM+-based components. If the service is stopped, most COM+-based components in Exchange Server 2003 will not function properly. Error Reporting Service This is an optional service that enables automatic reporting of errors. Servers running Exchange Server can use this service to automatically send fatal service error information to Microsoft. HTTP SSL This service implements the secure HTTP (HTTPS) for the HTTP service, using Secure Socket Layer (SSL). If you want to use HTTPS to secure Outlook Web Access or RPC over HTTP connections, you must enable this service. IPSec Services This service enables Internet Protocol security (IPSec), which provides end-to-end security between clients and servers on TCP/IP networks. This service must be enabled if you want to use IPSec to secure network traffic between a server running Exchange Server and other computers on the network, such as a frontend 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 softwarebased 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

52

you run Exchange System Manager on a management workstation. If this service is stopped, the registry can only be modified on the local server. System Event Notification This service monitors system events and notifies subscribers to COM+ Event System of these events. If this service is stopped, COM+ Event System subscribers do not receive Exchange system event notifications. The following table lists the system events provided by Exchange Server 2003. System events in Exchange Server 2003 Event OnTimer OnMDBStartUp OnMDBShutDown Description Called at a specified interval. Called when a store is started. 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.

53

The following figure illustrates how SMTP, NNTP, IMAP4, POP3, Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync are integrated into the architecture of IIS 6.0. Exchange Server 2003 components in the IIS 6.0 architecture

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

54

The registry key for the IIS Admin service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin.

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

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

The POP3 service runs in the context of the Inetinfo.exe process and depends on the IIS Admin service so that it can be controlled in IIS. The POP3 service is implemented in Pop3svc.dll, which 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.

55

NNTP Service The NNTP service enables an Exchange Server 2003 server to host NNTP newsgroups (such as discussion groups) based on public folders. Because this feature complies fully with the NNTP protocol, users can use any newsreader client to participate in newsgroup discussions. If the NNTP service runs on a server running Exchange Server 2003, the NNTP service can also be used to replicate newsgroups with other NNTP hosts through newsfeeds. The NNTP service is included with Windows Server 2003 and is extended by Exchange Server 2003. The registry key for the NNTP service is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NNTPSvc.

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

The IMAP4 service runs in the context of the Inetinfo.exe process and depends on the IIS Admin service. The IMAP4 service is implemented in IMAP4svc.dll, which resides by default in the \Program Files\Exchsrvr\Bin directory. The IMAP4 service is disabled by default. Note: Because no other Exchange services depend on the IMAP4 service, the IMAP4 service is not required to be running if users do not use IMAP4 clients to access their mailboxes. 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

56

Server 2003 extends this service with ISAPI components for Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. The registry key for the World Wide Web service is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc.

Unlike all other IIS services, the Web service does not run in the context of the Inetinfo.exe process. If you check the ImagePath parameter under the W3Svc registry key, you see that the Web service runs in the context of the Svchost.exe process, which is a generic host process for services that are implemented in DLLs. The Web service is implemented in Iisw3adm.dll. The Web service runs in an Svchost.exe service group called IISSvcs. Svchost.exe uses service groups to run separate services together in a single instance of Svchost.exe. Multiple instances of Svchost.exe can run on a server and each Svchost.exe session can contain a separate group of services. Svchost groups are listed in the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost.

Each entry under this key is a REG_MULTI_SZ parameter that represents a separate Svchost group. Each value contains the service names that run together in a service group. If you check the value of the IISSvcs entry, you see that the Web service is the only service in the IISSvcs group. World Wide Web Worker Process All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a World Wide Web worker process. The worker process executable is called w3wp.exe. Each worker process provides complete isolation from system components and other Web applications, and receives requests directly from the HTTP.sys kernelmode 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

57

also leverage other operating system services that are available at the process level (for example, CPU throttling). Note: Applications can be assigned to another application pool in the IIS Manager snap-in while the server is running. IIS supports up to 20,000 application pools per server. HTTP.sys This is the kernel-mode component for HTTP listening, routing, queuing, and caching. HTTP.sys is a single point of contact for all incoming HTTP requests. It provides high-performance connectivity for HTTP server applications. The driver sits on top of TCP/IP and registers itself for all Windows sockets (IP/port combinations) on which incoming connection requests are received. HTTP.sys is also responsible for overall connection management, bandwidth throttling, and Web server logging. HTTP.sys maintains a queue for each application pool so that the individual HTTP requests are routed to the correct user-mode worker processes serving an application pool. If a user-mode worker process quits unexpectedly, HTTP.sys continues to accept and queue requests, provided the Web service is still running. HTTP.sys continues to accept requests and queues them on the appropriate queue until there are no queues available, there is no space left on the queues, or the Web service has been shut down. Once the Web service notices the failed worker process, it starts a new worker process, if there are outstanding requests waiting to be serviced for the worker process's application pool. Thus, while there might be a temporary disruption in user-mode request processing, the user does not experience the failure because requests continue to be accepted and queued.

Core Exchange Server 2003 Services

The following figure illustrates the core components of Exchange Server 2003, together with their service dependencies. Core components are System Attendant, the Exchange Information Store service, the IIS Admin service, the SMTP service, and the Exchange installable file system (ExIFS). All of these services must be running on every Exchange Server 2003 server to guarantee a fully functioning messaging system.

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 DSAccess Component Responsibility Locating domain controllers in the network and providing other Exchange services with Active Directory information Comments 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 DSProxy Component

Responsibility Proxying legacy MAPI clients to Active Directory

Comments 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. 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.

Free/Busy Component

Maintaining free/busy information for Outlook Web Access users

61

Component

Responsibility

Comments The mailbox manager component enforces message retention policies and mailbox quotas that you can use to manage mailbox store sizes. 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 and Active Directory.

Mailbox Manager Component Managing mailboxes

Metabase update service

Replicating settings from Active Directory to the IIS metabase

62

Component Offline Address Book Generator

Responsibility Generating offline address books

Comments 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. 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.

Recipient Update Service

Applying recipient policies and generating proxy addresses

63

Component Server Monitor Component

Responsibility Monitoring server resources

Comments 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 Service Architecture. Exchange Installable File System The Exchange installable file system is a kernel-mode driver, implemented in ExIfs.sys, which IIS protocol engines and Web applications can use to read and write items from and to messaging databases. To gain access to the databases, the ExIFS file system driver must communicate with the Exchange store. This is accomplished through a store extension (ExWin32.Dll) and a user-mode wrapper (Ifsproxy.dll). The Exchange store, on the other hand, uses ESE to access .stm and .edb files, which are files that reside on a drive formatted with the NTFS file system. The following figure illustrates this architecture. The ExIFS architecture

As mentioned in Exchange Server 2003 Technical Overview, a mailbox store or public folder store is made up of a streaming database (.stm) and a MAPI database (.edb). The IIS components use ExIFS to work with streaming databases, while MAPI clients, such as Outlook, work with MAPI-based databases (.edb). A streaming database holds Internet messages in their native format, such as MIME, while an .edb database stores e-mail messages in MAPI format. The Exchange store must keep both the streaming databases and the corresponding MAPI-based databases synchronized. To accomplish this, the Exchange store must communicate with ExIFS, in addition to ESE. For example, when allocating free space in a database, ExIFS requests space from ESE. ESE must track which pages in the streaming database are reserved and committed. Thus, the Exchange 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 Service Architecture. Note: ExIFS is the only kernel-mode component in Exchange Server 2003.

Additional Exchange Server 2003 Services

In addition to IIS protocol engines and Exchange Server 2003 core services, the following Exchange services provide additional functionality: Calendar Connector The Calendar Connector service enables the sharing of free/busy information between Exchange Server 2003 users and Lotus Notes or Novell GroupWise users. This service depends on the event log, Exchange Information Store service, and Microsoft Exchange Connectivity Controller. For more information about the architecture of Calendar Connector, see Gateway Messaging Connectors Architecture. The executable file is Calcon.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCalCon. Connectivity Controller The Connectivity Controller service provides support services for Connector for Lotus Notes, Connector for Novell GroupWise, and Calendar Connector. This service depends on the Event Log service and System Attendant. For additional information about the architecture of Connectivity Controller, see Gateway Messaging Connectors Architecture. The executable file is Lscntrl.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCOCO. Connector for Lotus Notes The Connector for Lotus Notes service enables the transfer of messages and directory synchronization between Exchange Server 2003 and Lotus Notes. This service depends on Event Log, Connectivity Controller, and the Exchange Information Store service. For more information about the architecture of Connector for Lotus Notes, see Gateway Messaging Connectors Architecture. The executable file is Dispatch.exe, which is started with LME-NOTES command-line parameters to launch Lotus Notes-specific connector processes. Dispatch.exe resides in the \Program Files\Exchsrvr\Bin directory. The registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-NOTES. 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 non-Exchange messaging systems. In a mixed environment with servers running Exchange Server 5.5 in the local routing group, the MTA is also used to transfer messages between Exchange Server 2003 and Exchange Server 5.5. This occurs because Exchange Server 5.5 MTAs communicate with each other in the local site directly through RPCs. Exchange Server 2003 must rely on this communication method for backward compatibility. The executable file of the Microsoft Exchange MTA Stacks service is EMSMTA.exe, which is located in the \Program Files\Exchsrvr\bin directory. This service depends on System Attendant and maintains its own specific message queues outside the Exchange store in the \Program Files\Exchsrvr\Mtadata directory. The registry key is HKEY_Local_Machine\System\CurrentControlSet\Services\MSExchangeMTA.

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 Messaging Connectors Architecture. The Router for Novell GroupWise service depends on System Attendant. The executable file is GWRouter.exe, which resides in the \Program Files\Exchsrvr\Bin directory. The registry key is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeGWRtr. Routing Engine The Routing Engine service provides topology and routing information to servers running Exchange Server 2003. The advanced queuing engine within the SMTP transport subsystem uses this service to provide next-hop information when routing messages within the Exchange organization. If this service is stopped, optimal routing of messages is not available. For additional information on the Routing Engine service and its role in message delivery, see SMTP Transport Architecture. The Routing Engine service depends on IIS Admin and runs within the Inetinfo.exe process. This service is implemented in a file called RESvc.dll, which resides in the \Program Files\Exchsrvr\Bin directory. The registry key is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc.

Site Replication Service Site Replication Service (SRS) provides directory integration between Exchange Server 5.5 and Exchange Server 2003. SRS runs on Exchange Server 2003 and serves as a modified Exchange Server 5.5 directory. Exchange server 5.5 responds to SRS as another Exchange Server 5.5 directory replication partner. SRS is automatically enabled on the first server that joins an Exchange Server 5.5 site. When you remove the last server running Exchange Server 5.5 from the network, you can disable SRS. 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 mailenabled 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. Exchange Server 2003 installation files with Active Directory schema extensions File Name Schema0.ldf Description 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 Schema1.ldf

Description Includes schema extensions for Active Directory Connector, which you can use to integrate an Exchange Server 5.5 organization with Active Directory. Includes schema extensions for Internet access protocols, directory synchronization, and Exchange store configuration objects. Includes schema extensions for system monitoring, Connector for Lotus Notes configuration objects, offline address book settings, and settings that belong to X.400 connectors. Includes schema extensions for routing groups, bridgehead servers, protocol containers, messaging databases, address list services, and Microsoft Exchange MTA configuration objects. Includes schema extensions for protocol containers, routing group connectors, and parameters that pertain to Extensible Storage Engine (ESE). Includes schema extensions for protocol virtual servers, administrative groups, messaging connectors, and the Exchange store. Includes schema extensions for messaging databases and mailbox manager. Includes schema extensions for mailbox manager, system monitoring, public folders, and SMTP transport configuration objects.

Schema2.ldf

Schema3.ldf

Schema4.ldf

Schema5.ldf

Schema6.ldf

Schema7.ldf Schema8.ldf

74

File Name Schema9.ldf

Description Includes schema extensions for Calendar Connector, Connector for Novell GroupWise, dynamic distribution lists, messaging folders, and Outlook Mobile Access. Note: Schema1.ldf through Schema8.ldf are identical for Exchange 2000 Server and Exchange Server 2003. Schema9.ldf contains the schema extensions that are new in Exchange Server 2003.

Exschema.ldf

Adds the Object-GUID, Replication-Signature, Unmerged-Attributes, and ADC-GlobalNames attributes to the schema to update a pre-Exchange 2000 Service Pack 1 schema with the information required for Exchange Server 2003.

Note: You can use .ldf files in conjunction with low-level Active Directory tools, such as Ldifde.exe, to repair a damaged Active Directory schema. Troubleshooting the Active Directory schema, however, is beyond the scope of this book. Note that schema changes might reset the global catalog, in which case all recipient objects must be replicated again to the global catalog. This can cause significant increases in data traffic in large organizations.

Directory Service Access

Exchange 2003 services access information that is stored in Active Directory and write information to Active Directory. If this communication occurred directly between each service and Active Directory, Exchange 2003 could overwhelm an Active Directory domain controller with communication requests. A central component is required to streamline communication with Active Directory. This component is the DSAccess module. 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 Type Description

TopoCreateTimeoutSecs REG_DWORD

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

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAc cess

Value Type Value Data Description

LdapKeepAliveSecs REG_DWORD 0x0

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

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAc cess

Value Type Value Data Description

DisableNetLogonCheck REG_DWORD 0x0

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 Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of DC> IsGC REG_DWORD 0x0

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of DC> HostName REG_SZ <name of DC>

84

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of DC> DSType REG_SZ 0

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of DC> PortNumber REG_DWORD 0x00000185 (389)

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of GC> IsGC REG_DWORD 0x1

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of GC> HostName REG_SZ <name of GC>

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of GC> DSType REG_SZ 0

85

Location Value Type Value Data

MSExchangeDSAccess\Profiles\Default\<Name of GC> PortNumber REG_DWORD 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 Value Type Value Data

MSExchangeDSAccess\Instance0 ConfigDCHostName REG_SZ <Name of config DC>

Location Value Type Value Data

MSExchangeDSAccess\Instance0 ConfigDCPortNumber REG_DWORD 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 Config domain controller Working domain controllers Working global catalogs Server Domain controller 1 or global catalog 1 Domain controller 1 and global catalog 1 Global catalog 1

DSAccess running on Exchange Server 2003 servers in Site B will detect the topology shown in the following table. Topology for Site B Domain Controller Type Config domain controllers Server Domain controllers 2, 3, and 4 Global catalog 2 or 3 Working domain controllers Domain controllers 2, 3, and 4 Global catalogs 2 and 3 Working global catalogs Global catalogs 2 and 3

In each case, the order of the listed servers is important. The servers are listed and used in the order in which they are discovered by DSAccess and determined to be suitable.

Example 2 Complex Domain Topology

The following figure depicts a more complex topology, which includes two domains and two sites, with Site A spanning both domains.

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 Domain Controller Type Config domain controller Server Domain controllers 1, 2, 3, and 4 Global catalogs 1, 2, or 3 Working domain controllers Domain controllers 1, 2, 3, and 4 Global catalogs 1, 2, and 3 Working global catalogs Global catalogs 1, 3, and 2

DSAccess running on Exchange Server 2003 servers in Domain 2 and Site A will detect the topology shown in the following table Topology for Domain 2 and Site A Domain Controller Type Config domain controller Server Domain controllers 1, 2, 3, 4 Global catalogs 1, 2, or 3

89

Domain Controller Type Working domain controllers

Server Domain controllers 1, 2, 3, and 4, Global catalogs 1, 2, and 3

Working global catalogs

Global catalogs 2, 1, and 3

DSAccess running on Exchange Server 2003 servers in Domain 2 and Site B will detect the topology as shown in the following table. Topology for Domain 2 and Site B Domain Controller Type Config domain controller Server Domain controller 5 Global catalog 4 Working domain controller Domain controller 5 Global catalog 4 Working global catalogs Global catalog 4

Once again the servers are listed and used in the order in which they are discovered and determined to be suitable.

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 Mad.exe Store.exe EMSMTA.exe Description Microsoft Exchange System Attendant service Microsoft Exchange Information Store service Microsoft Exchange MTA Stacks service

90

Process ExMgmt.exe RESvc.exe Inetinfo.exe or W3WP.exe Winmgmt.exe

Description Exchange Management service Exchange Routing Engine service IIS and worker processes 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 Metabase update service (DS2MB) Exchange Routing Engine (RESVC) SMTP categorizer (SMTP CAT) Directory Service Proxy (DSProxy) Exchange store WebDAV Message transfer agent (MTA) Uses DSAccess for Directory changes tracked by update sequence number (USN) User and configuration lookups List of global catalog servers in the topology List of global catalog servers in the topology User and configuration lookups User and configuration lookups User and configuration lookups

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: 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. Location Value Type Value Data Description

MSExchangeDSAccess\Instance0 CacheTTLConfig REG_DWORD 0x384 (900 seconds)

Used to specify the time-to-live (TTL) for configuration data in the cache

Location Value Type Value Data Description

MSExchangeDSAccess\Instance0 MaxEntriesConfig REG_DWORD 0 (no limit)

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 Type Value Data Description

MSExchangeDSAccess\Instance0 CacheTTLUser REG_DWORD 0x12c (300 seconds)

Used to specify the time-to-live (TTL) for user data in the cache

Location Value

MSExchangeDSAccess\Instance0 MaxEntriesUser

92

Type Value Data Description

REG_DWORD 0 (no limit)

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: 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. The following registry values can be used to preload the DSAccess cache. Location Value Type Value Data Description

MSExchangeDSAccess PreloadBaseDNs REG_MULTI_SZ BaseDN value (for example, DC=contoso,DC=com)

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 Value Type

MSExchangeDSAccess\ PreloadFilters REG_MULTI_SZ

93

Value Data Description

A filter string, for example, legacyExchangeDN=%

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 servers Active Directory site (when all in-site global catalogs are unavailable).

96

In addition to honoring site membership, DSProxy prefers to use global catalog servers that are members of the same domain as the Exchange server. If there are none available, DSProxy uses the other global catalog servers in the Active Directory site. This behavior presents issues in multiple-domain environments where DomainPrep has been run against the domains. Specifically, if an Outlook client is referred to a global catalog server that does not reside in the same domain as the mailbox-enabled user, that user will access data that is in a read-only format. This means that updates to certain objects could fail. The updates could be updates to the mailbox-enabled user such as delegate access or distribution group membership.

Pre-SP2 Scenario
The forest contains three domains, each of which has been prepared for Exchange Server. All users and distribution groups reside in the domain, UserDomain. A global catalog server from UserDomain and ThirdDomain are members of the Exchange servers 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 servers 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

97

this discussion, assume that DSProxy refers the client to a ThirdDomain global catalog server. In this scenario, the Outlook clients can use that global catalog server successfully for all directory requests except the following: Updating membership of distribution groups that reside in UserDomain.

Assigning delegate permissions against the mailboxes of these distribution groups, which reside in UserDomain. Publishing certificates to the global address list (GAL) using the Publish to GAL option in Outlook. If DSProxy referred the Outlook client to the UserDomain GC1, the Outlook client could perform the requests listed above. For more information about pre-SP2 behavior and its potential issues, see the following Microsoft Knowledge Base articles. 256976, "XCLN: How MAPI Clients Access Active Directory"

872897, "How to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 sp1" 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 owners 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:

98

Constraint 1 A global catalog that is available (RPC ping) 16 points Constraint 2 A global catalog that supports the client's protocol 8 points Constraint 3 A global catalog that belongs to the user's domain 4 points

Constraint 4 A global catalog that is in the same Active Directory site as the Exchange server 2 points Constraint 5 A global catalog that is one of the global catalogs that the Exchange server is currently using 1 point DSProxy distributes the global catalog servers that have the most points first, and sequentially allocates resources if there is a tie. Constraint 1 is computed every five minutes and is configurable through changing the LdapKeepAliveSecs registry key. Constraints 2 and 3 are "dynamic" because they must be computed every time that a client demands a referral. Constraints 4 and 5 are "static" because they are computed one time for each global catalog and then stored. Constraint 5 is also known as the incarnation list. When DSAccess initializes, it builds an incarnation list of 10 in-site global catalog servers that it can use. If all in-site global catalog 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 UserDomain GC1 Active Directory site Client Active Directory site Client Active Directory site In-Use by DSAccess? No Total points by constraint value 16+8+4=28 (1, 2, 3) No 16+8+4=28 (1, 2, 3)

UserDomain GC2

100

Server UserDomain GC3

Active Directory site Active Directory site B Active Directory site B Exchange Active Directory site Exchange Active Directory site Active Directory site A Active Directory site A Active Directory site B Active Directory site B

In-Use by DSAccess? No

Total points by constraint value 16+8+4=28 (1, 2, 3)

UserDomain GC4

No

16+8+4=28 (1, 2, 3)

Exchange Domain GC1 Exchange Domain GC2 Exchange Domain GC3 Exchange Domain GC4 Exchange Domain GC5 Exchange Domain GC6

Yes

16+8+2+1=27 (1, 2, 4, 5)

Yes

16+8+2+1=27 (1, 2, 4, 5)

No

16+8=24 (1, 2)

No

16+8=24 (1, 2)

No

16+8=24 (1, 2)

No

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 servers 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 servers 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 servers Active Directory site or in any of the Exchange servers 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 recipients 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 e-mail message.

Recipient Update Service and Exchange Server 2003

Exchange Server 2003 communicates with directory servers to update recipient objects (such as mailbox-enabled user accounts and mail-enabled groups) with e-mail addresses, according to the recipient policies defined for the organization. To do this, Exchange Server 2003 uses Recipient Update Service, a component of System Attendant. Recipient Update Service creates and maintains Exchange Server 2003-specific attribute values in Active Directory. If you create a mailbox for a user, Recipient Update Service automatically generates the user's SMTP address and any other proxy addresses that you defined for your recipients. Exchange Server 2003 installs two instances of Recipient Update Service: Enterprise configuration Recipient Update Service There is only one instance of this Recipient Update Service in the organization, because the Enterprise Recipient Update Service is used to update the configuration directory partition, and there is only a single configuration directory partition shared by the entire forest. Domain Recipient Update Service You must have a Recipient Update Service for each domain that contains mailbox-enabled users. For each particular domain in a forest, Recipient Update Service associates one Exchange Server 2003 computer (on which Recipient Update Service runs) with one domain controller (on which the directory objects are updated). Only one Recipient Update Service can be associated with any directory server at any given time.

Updating Recipient Objects

The method that Recipient Update Service uses to perform a search is determined by the actions that an Exchange administrator takes in Exchange System Manager. For example, in Exchange System Manager, you can right-click a Recipient Update Service configuration object and select the Rebuild command to recalculate address list memberships and the

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: HKEY_CLASSES_ROOT\CLSID Each snap-in is assigned a GUID that identifies the snapin 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.

110

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

Parameter
NameString

Type
REG_SZ

Comments 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.

111

Parent Key
{CLSID}

Parameter
About

Type
REG_SZ

Comments 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
{CLSID}

Parameter
NameStringIndirect

Type
REG_SZ

Comments 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
{CLSID}\ StandAlone

Parameter
N/A

Type
N/A

Comments 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 stand-alone snap-ins to subnodes of other snap-ins, using the stand-alone snap-in in the same way as an extension snap-in.
StandAlone

Extension snap-ins do not have a StandAlone key. Therefore, the snap-in cannot be added to an MMC console without first adding a stand-alone snap-in that provides the nodes that the extension snap-in is designed to extend. For example, the Exchange Information Store extension snapin 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

114

Parent Key
{CLSID}\ NodeTypes

Parameter
{CLSID}

Type
N/A

Comments 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 Snapin dialog box.

KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes All extensible node types have their own subkey (that is, the GUID of the node type) registered under the MMC\NodeTypes key. Each GUID key contains an Extensions subkey. The Extensions key contains additional subkeys that represent the actual types of extensions that this node type can have. Each extension type subkey contains values that represent the CLSIDs of the snap-ins that extend that node type. For example, the Exchange Post Office Protocol

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 Exchange Message Tracking Center Snap-in Extension Not applicable In-process server DLL Exadmin.dll Description Provides access to the message-tracking center. This is a stand-alone snap-in.

116

Snap-in Exchange Protocols

Snap-in Extension Not applicable

In-process server DLL Exadmin.dll

Description 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. Enables management of the Internet Mail Access Protocol version 4 (IMAP4) and IMAP4 virtual servers. Enables management of the Network News Transfer Protocol (NNTP) and NNTP virtual servers. Enables management of POP3 protocol and POP3 virtual servers.

Exchange IMAP4

Imapmgr.dll

Exchange NNTP

Nntpmgr.dll

Exchange POP3

Pop3mgr.dll

117

Snap-in

Snap-in Extension Exchange SMTP

In-process server DLL Exps.dll

Description Enables management of Simple Mail Transfer Protocol (SMTP) and SMTP virtual servers. Enables management of the local message transfer agent (MTA) and X.400 protocol settings. 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.

Exchange X.400

Exadmin.dll

Exchange Servers

Not applicable

Exadmin.dll

118

Snap-in

Snap-in Extension Exchange DXA

In-process server DLL Exadmin.dll

Description 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 Exchange Monitoring

In-process server DLL Exadmin.dll

Description Enables you to examine the state of Exchange servers and messaging connectors between routing groups. 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. Provides access to the queue viewer in Exchange System Manager, which provides management interfaces for SMTP, MTA, X.400, and other connector queues.

Exchange Protocols

Exadmin.dll

Exchange Queue Viewer

Exadmin.dll

120

Snap-in Exchange System

Snap-in Extension Not applicable

In-process server DLL Exadmin.dll

Description 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. Enables management of address lists, including global address lists and offline address books. Enables management of address templates. 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.

Exchange Address Lists

Exadmin.dll

Exchange Address Templates Exchange Calendar Connector

Exadmin.dll Exadmin.dll

121

Snap-in

Snap-in Extension Exchange cc:Mail

In-process server DLL Exadmin.dll

Description 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 Exchange DXA

In-process server DLL Exadmin.dll

Description 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. Enables management of Connector for Novell GroupWise.

Exchange GroupWise Connector

Exadmin.dll

123

Snap-in

Snap-in Extension Exchange Information Store

In-process server DLL Exadmin.dll

Description Enables management of storage groups, mailbox stores, and public folder stores. Provides access to Mailbox Recovery Center, which you can use to recover individual mailboxes from a backup. Provides access to and use of Message Tracking Center. Provides access to the monitoring and status features for managing connectivity between routing groups.

Exchange Mailbox Recovery Center

Exadmin.dll

Exchange Message Tracking Center Exchange Monitoring

Exadmin.dll

Exadmin.dll

124

Snap-in

Snap-in Extension Exchange MSMail

In-process server DLL Exadmin.dll

Description Enables checking the configuration settings of Connector for Microsoft Mail running on Exchange 2000 servers. Note: Configuring Exchange 20 00 Server resources using Exchange Server 2003 System Manager is not supported. Make sure you use Exchange 20 00 System Manager to configure Connector for Microsoft Mail.

Exchange Notes Connector

Exadmin.dll

Provides access to the Connector for Lotus Notes configuration settings.

125

Snap-in

Snap-in Extension Exchange Protocols

In-process server DLL Exadmin.dll

Description 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. Provides access to the queue viewer in Exchange System Manager, which provides management interfaces for SMTP, MTA, X.400, and other connector queues. Enables management of recipient policies, which Recipient Update Service uses to assign recipient information, such as e-mail addresses, to user accounts.

Exchange Queue Viewer

Exadmin.dll

Exchange Recipient Policies

Exadmin.dll

126

Snap-in

Snap-in Extension Exchange Schedule+ Free/Busy Connector

In-process server DLL Exadmin.dll

Description Enables checking the 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 standalone 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 and Active Directory. 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 Settings Yes No No Manage Exchange Configuration Settings Yes Yes No View Exchange Configuration Settings Yes Yes Yes

Exchange Full Administrator Exchange Administrator Exchange View Only Administrator

Enabling the Security Tab for Objects in Exchange System Manager

Administration Delegation Wizard is used to grant roles to individual Exchange administrators or groups at the organization or administrative group level. However, Administration Delegation Wizard does not display all security settings and sometimes might even display an incomplete administrator list. This is because Administration Delegation Wizard tracks administrators to whom it grants Exchange administrator roles, in an attribute of the Exchange organization object in Active Directory. This attribute is named msExchAdmins. However, Administration Delegation Wizard does not track administrators with permissions inherited from higher-level containers in the configuration directory partition. For example, by default, Enterprise Administrators have full permissions across the entire configuration directory partition. This is because the full permissions setting is inherited from the root Configuration container to all child containers. However, Administration Delegation Wizard does not list these administrators as Exchange Full Administrators, because they are not listed in the msExchAdmins attribute. Permissions inheritance is explained in "Permissions Inheritance and Exchange System Manager" later in this topic. Moreover, if you assign a security group the Exchange Full Administrator role at the organization level, later you cannot use Administration Delegation Wizard to downgrade members of that group to the Exchange View Only Administrator role for a specific administrative group. This is because Administration Delegation Wizard does not deny permissions granted through security settings inherited from parent containers. If you use Administration Delegation Wizard to assign individual members the Exchange View Only 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

135

from the organization level. To examine actual security settings, you must enable the Security tab for the organization and administrative group objects in Exchange System Manager. To do this, set the ShowSecurityPage registry parameter, as shown in the following table. The ShowSecurityPage registry parameter HKEY_CURRENT_USER\Software\Microsoft \Exchange\ExAdmin Value Name Data Type Value Description ShowSecurityPage REG_DWORD 1 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: 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.

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 ANONYMOUS LOGON Permitted Create Named Properties in the Information Store Authenticated users Create Public Folder Execute List Contents List Object Read Read Permissions Read Properties Read Properties List Object None Denied None

137

Account Domain Admins (root domain)

Permitted Read Write Execute Delete Read Permissions Change Permissions Take Ownership Create Children List Contents Add/remove Self Read Properties Write Properties List Objects Create Public Folder

Denied Receive As Send As

Create Top Level Public Folder Modify Public Folder Admin ACL Modify Public Folder Replica List Open Mail Send Queue Read Metabase Properties Administer Information Store Create Named Properties in the Information Store View Information Store Status Receive As Send As

138

Account Enterprise Admins

Permitted Full Control

Denied Receive As Send As

Everyone

Create Named Properties in the Information Store Create Public Folder Execute List Contents List Objects Read Read Permissions Read Properties Full Control

None

Exchange Domain Servers

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 and client

140

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 Exchange System Manager

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 SSLspecific 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 Exchange System Manager. 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.

153

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

154

Service Configuration in Exchange System Manager

To support remote updating of configuration settings stored in the registry, Exchange System Manager requires the Remote Registry service to be running on all Exchange servers. For example, when you display the properties of a server object in Exchange System Manager and switch to the Diagnostics Logging tab to view or set the event logging level for the various categories of Exchange services, Exchange System Manager accesses registry settings for the corresponding services through the registry API. The categories that appear for a service on the Diagnostics Logging tab correspond to REG_DWORD parameters stored in the Diagnostics subkey of the Exchange service, under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. The following figure illustrates this relationship for the DSAccess component.

155 Diagnostics logging settings in Registry Editor and in the Properties dialog box for a server object in Exchange System Manager

The Remote Registry service is bypassed when you work with registry settings on the local computer. However, if you want to set the diagnostics logging level for an Exchange server remotely, Exchange System Manager must first use the RegConnectRegistry function of the registry API to establish a connection to the registry key that you want on the remote computer. For this function call, the Exchange administrator must have access permissions to the Remote Registry service. Otherwise, the Remote Registry connection cannot be established. Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry

156

incorrectly may not be able to be resolved. Before editing the registry, back up any 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 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. This section discusses the following concepts: 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

157

organization in order to understand the fundamentals of message routing in Exchange Server 2003. Exchange Server 2003 message handling Before examining the actual routing mechanisms in Exchange Server 2003, you must understand how Exchange 2003 routes messages that are addressed to recipients who reside on the same Exchange server as the sender and recipients who reside on other Exchange servers in the same routing group, in other routing groups, or on external messaging systems. Exchange Server 2003 message routing Exchange Server 2003 uses link state information to make dynamic routing decisions, rather than routing decisions based on a static routing table. To understand dynamic message routing in Exchange Server 2003, you must understand how Exchange Server 2003 selects message routes and how changes to the routing topology influence the message routing process. Propagation of link state information Procedures must exist to replicate link state information between Exchange servers. These procedures ensure that each server has accurate information about the whole organization. With this information, the server can recalculate the optimal path to any destination in the messaging environment according to the current state of the routing topology. You must understand how servers propagate changes to the message routing topology across an Exchange Server 2003 organization. In addition, you must understand the details of the link state table (the table that contains the routing information) and the algorithm that is used to replicate link state information between Exchange servers. Backward Compatibility with Exchange Server 5.5 Several routing issues arise when you integrate Exchange Server 2003 into an Exchange Server 5.5 organization. You must understand these issues to understand how Exchange Server 5.5 can use Exchange Server 2003 connectors and vice versa. This section assumes that you are familiar with routing group topology design and the configuration of messaging connectors. For more information on transport and routing, see the Exchange Server 2003 Transport and Routing Guide.

Exchange Server 2003 Message Routing Topology

The following figure illustrates an Exchange Server 2003 organization routing topology with multiple internal routing groups connected through routing group connectors and a connector that connects the Exchange organization to an external messaging system. In this topology, routing group A represents a central routing hub. All messages to remote routing groups (routing groups B and C) and the non-Exchange messaging system are routed through routing group A. Multiple bridgehead servers are deployed in routing group A to provide redundant message transfer paths.

158 An Exchange Server 2003 message routing topology

The message routing topology shown in the figure above includes the following key components: Routing groups These are logical collections of servers, used to control mail flow and public folder referrals. Routing groups share one or more physical connections. In a routing group, all Exchange servers communicate and transfer messages directly to one another, using Simple Mail Transfer Protocol (SMTP) virtual servers. In a native mode organization, routing groups can include servers from different administrative groups. However, in a mixed mode organization, routing groups cannot span multiple administrative groups, due to backward compatibility with Exchange Server 5.5. This is because the routing topology in Exchange 5.5 is defined by sites, and sites provide the functionality of both the administrative group and the routing group. Tip: SMTP works well over any type of TCP/IP connection. Therefore, a routing group does not necessarily define regions on a computer network with high network bandwidth. Routing groups can span slow network connections, if the connection 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

159

routing group topology. In Figure 5.1, the bridgehead server running a connector to the non-Exchange messaging system must remain connected to the external messaging system. Note, however, that all servers in a routing group periodically poll the routing group master. Gaining control over server-to-server communication might require you to implement multiple routing groups, which might be especially important if communication over wide area network (WAN) connections generates costs. For more information about the design and configuration of routing group topologies, see Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=26041). Routing group connectors A routing group connector enables message transfer between two routing groups. The following Exchange connectors can be used to establish message transfer paths between routing groups: Routing group connectors A routing group connector provides a one-way connection path in which messages are routed from servers in one routing group to servers in another routing group. Routing group connectors use Simple Mail Transfer Protocol (SMTP) to communicate with servers in connected routing groups. Routing group connectors provide the best connection between routing groups. Note: The Routing Group Connector (note the capitalization) is a specific type of connector that can only be used to connect routing groups with each other. Other connectors that can connect routing groups are the SMTP connector and X.400 connector. However, these connectors can also be used to connect an Exchange organization to an external messaging system through SMTP or X.400. To avoid confusion, this guide uses "Routing Group Connector" to refer to the specific connector that can only be used between routing groups and "routing group connector" to refer to all types of connectors that can be used to connect routing groups. SMTP connector An SMTP connector can be used to connect routing groups, but this is not recommended. SMTP connectors are designed for external message delivery. SMTP connectors define specific paths for e-mail messages that are destined for the Internet or an external destination, such as a non-Exchange messaging system. X.400 connectors Although you can use X.400 connectors to connect routing groups, X.400 connectors are designed to connect servers running Exchange with other X.400 systems or to servers running Exchange Server 5.5 outside an Exchange organization. A server running 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.

160

Connectors to non-Exchange messaging systems These connectors support message transfer and directory synchronization between Exchange and non-Exchange messaging systems. When appropriate connectors are implemented, the user experience is similar on both messaging systems and the transfer of messages and other information between the Exchange and non-Exchange messaging system is transparent to the user. However, some message properties might be lost during message conversion from an Exchange format to a non-Exchange format, or vice versa. Mailbox servers A mailbox server is an Exchange server configured to host mailboxes. Users can access their mailboxes through a variety of clients, such as Microsoft Office Outlook, Microsoft Office Outlook Web Access, Microsoft Office Outlook Mobile Access, Post Office Protocol version 3 (POP3)-based clients, and Internet Message Access Protocol version 4rev1 (IMAP4)-based clients. In the Exchange Server 2003 routing topology, mailbox servers are typical sources and destinations of e-mail messages. Bridgehead servers A bridgehead server is a connection point that performs message transfer from one routing group to another routing group, or to an external messaging system. In large organizations, bridgehead servers are often separated from mailbox servers to avoid performance bottlenecks. Mailbox servers create bottlenecks due to increased processing requirements during peak messaging hours. Bridgehead servers are identified as local or remote bridgehead servers, as follows: Local bridgehead servers This server hosts a connector and uses it to transfer messages. When you create a connector, you designate at least one Exchange server as a bridgehead server. You can also designate multiple bridgehead servers for load balancing, performance, and redundancy. For example, the default option for routing group connectors is Any local server can send mail over this connector. In this case, all Exchange servers in the local routing group can use the connector to transfer messages. Remote bridgehead servers The remote bridgehead server, specified in a connector configuration, is the server (in the connected routing group or non-Exchange messaging system) that receives all messages transferred over a connector. Routing Group Connector can have multiple remote bridgehead servers (that is, remote virtual SMTP servers). SMTP connector and X.400 connector, however, can have only one remote bridgehead server per connector instance. Remote bridgeheads are also named target bridgeheads.

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,

161

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. The Exchange Server 2003 transport architecture

In Exchange Server 2003, the SMTP transport engine handles messages as follows:

162

1. A message is received through SMTP, remote procedure calls (RPCs), X.400, or MAPI transfer protocols, as outlined in the following table. Incoming message transfer protocols Transfer Protocol SMTP Comments 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 RPCs

Comments 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 MAPI

Comments 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. MAPIbased messaging connectors convert inbound messages into Exchange format and then place them in the MTS-IN folder. Either way, the MAPI message is put in the Exchange store, and the Exchange store driver then puts the message in the pre-submission queue. For more information about MAPIbased 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 transfers the message to the Local Delivery queue. From the Local Delivery

165

queue, the Exchange store driver obtains the message and puts it in the mailbox of the recipient. Remote delivery The routing engine must process all messages to non-local recipients, because the SMTP transport engine must find an available transfer path for the destination. Correspondingly, the advanced queuing engine transfers the message to the pre-routing queue, calls the routing engine, and then passes the destination address (that is, the FQDN of the recipient's home server for internal recipients or the SMTP domain name for external recipients) to the routing engine. The routing engine returns the next hop that the message will use to the caller and classifies the next hop, as listed in the following table. Hop types for remote delivery Hop Type The next hop is to the local server Comments 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 This indicates that the transport engine must pass the message to a routing group connector on the local Exchange server. It must be noted, however, that this type applies only to messages transferred over SMTP. If you use X.400 connectors to connect routing groups, the transport engine passes the messages to the Exchange MTA (that is, the next hop is to the local server).

166

Hop Type The next hop is to a server outside the Exchange organization

Comments This indicates that the transport engine must 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). 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. This indicates that no final destination path exists, and the transport engine returns the message to the sender with an NDR.

The next hop is to a server that is currently unreachable

The next hop is to a server that is unreachable

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

167

(the connector's MTS-OUT folder). Otherwise, the MTA transfers the message directly using RPCs or an X.400 connector. For more information about the Exchange MTA, see X.400 Transport Architecture.

Exchange Server 2003 Message Routing

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

Message Routes and Link State Table

Every Exchange 2003 server maintains its own routing table, called the link state table, dynamically in memory, based on Active Directory and link state information, as follows: Routing-related Active Directory information This information is stored in attributes of the organization object, routing group objects, connector objects, and server objects. These objects reside in the configuration directory partition and define the routing topology of the entire Exchange organization. Note: Administrative groups are not part of the routing topology in an Exchange organization. Link state information This information specifies whether each connector in the routing topology is available (up) or unavailable (down). Link state information is dynamic and might change when a connector experiences transfer problems or when transfer issues are resolved. For more information about link state changes and the propagation of link state information across an Exchange organization, see Link State Propagation.

Initializing the Link State Table

Upon startup, each Exchange server initializes its link state table with the following information from Active Directory: Organization object The routing topology boundary is the Exchange organization. That is, the link state table does not include any information about external bridgehead servers or messaging connectors in an external messaging system. As far as the routing

168

engine is concerned, the routing topology ends at the connector to the external messaging system. Accordingly, the routing engine reads the GUID that is registered in the objectGUID attribute of the Exchange organization object in Active Directory and stamps the link state table with this GUID to identify the organization to which this routing information belongs. Routing group objects The routing engine enumerates all routing groups that exist in any administrative groups and queries each routing group for all object attributes, including the msExchRoutingGroupMembersBL attribute that contains a list of all routing group member servers. The routing engine places this information in the link state table. The routing engine also places the servers together with the GUID of the server's routing group in a server cache in memory. Each entry in the server cache is a server FQDN appended by the server's routing group GUID. Another important routing group attribute is the msExchRoutingMasterDN attribute, which points to the distinguished name of the routing group master in the selected routing group. For more information about the tasks and responsibilities of the routing group master, see the discussion later in this section. Messaging connector objects The routing engine enumerates all child objects with an object type of msExchconnector that exist in the Connections container of each routing group. The msExchconnector objects in the Connections container are the routing group connectors and connectors to external messaging systems configured in the routing group. The routing engine reads all attributes from these connector objects to determine address spaces, cost values, restrictions, and more. The routing engine places the information for each connector in the link state table. This enables messages to destinations outside the local routing group to be routed. The process continues until the routing engine identifies all directly and indirectly connected routing groups and queries for the configuration details of their messaging connectors. When this process ends, the routing engine has a complete view of all available transfer paths across the Exchange organization. All links are assumed to be up and available for message transfer. Following the initialization of the link state table, the routing engine communicates with the Microsoft Exchange Routing Engine service on the local server to obtain dynamic link state information that reflects the current state of each connector. The Exchange Routing Engine service connects to the routing group master in the local routing group through TCP port 691 to retrieve this information. For more information about link state information, see the section, "Examining the Link State Table," later in this topic.

Routing Engine and Exchange Routing Engine Service

The routing engine in the transport subsystem and the Exchange Routing Engine service have different roles. The Exchange Routing Engine service does not perform any message routing. The Exchange Routing Engine service communicates link state information between

169

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

Examining the Link State Table

The link state table is a small, in-memory database that is not stored on disk. To examine the entries that the routing engine uses to make routing decisions, you can use the Exchange Server 2003 WinRoute tool (Winroute.exe), which is available for download from the Downloads for Exchange Server 2003 Web site. Note: The WinRoute tool also shipped with Exchange 2000 Server, but it is best to download and use the Exchange Server 2003 version of this tool on all Exchange 2000 and Exchange Server 2003 servers in your organization. The WinRoute tool connects to the link state port, TCP port 691, on the selected Exchange server and extracts the link state table. The information in this table is a series of GUIDs and American Standard Code for Information Interchange (ASCII) text that represent routing groups, routing group members, and connectors in the routing groups. The link state table also includes information about the configuration of each connector. The information fields in the link state table are separated by parentheses as follows:
'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group Addresses' (Routing Group Members) (Connectors in Routing Group (Connector configuration))).

The following is a shortened example of a link state table (all but one routing group removed):

170

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 {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 Organization objectGUID Value
d38082e7c9ecd74dbff32bada8 932642

Comments The GUID that is registered in the objectGUID attribute of the Exchange organization object in Active Directory.

171

Field MD5 Digest

Value
d037d6eaf2fa7cd10934aca433 390623

Comments 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-todate 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 GUID that is registered in the objectGUID attribute of the routing group object to which the routing information belongs. This GUID follows next in the link state table.

Routing Group objectGUID

489416bfa3a4ff459b8f4403f2 0cad0d

172

Field Routing Group Master objectGUID

Value
1650c1fe32aef740be236e1089 e0da6a

Comments The GUID that is registered in the objectGUID attribute of the server that acts as the routing group master in this routing group. The routing group master within each routing group is responsible for maintaining and communicating link state information to all routing group members. Only one routing group master exists per routing group. For more information about the role of the routing group master, see the discussion later in this section.

173

Field Version Info

Value
8 0 2 c2da71f9b39ec748aaf44119a2 bdcb36

Comments 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: 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.

174

Field Routing Group Addresses

Value
{26}*.489416BF-A3A4-FF459B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange ;cn=489416BF-A3A4-FF459B8F-4403F20CAD0D;* {55}/o=TailspinToys/ou=Fir st administrative Group/*/489416BF-A3A4FF45-9B8F-4403F20CAD0D

Comments 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. For example, assume that SERVER01 in a routing group named First Routing Group has an FQDN of SERVER01.TailspinToys.co m. According to the routing group address definition, the routing engine creates an entry for SERVER01 in the server cache, as follows:
SERVER01.TailspinToys.com. 489416BF-A3A4-FF45-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 Routing Group Members

Value
( 1650c1fe32aef740be236e10 89e0da6a YES 1 1b20 {10}0701000000000101 )

Comments 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. 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: 1650c1fe32aef740be23 6e1089e0da6a Whether the member is connected to the routing group master. YES indicates that the server is connected. Server version number: 1 Build version: 1b20 hex = 6944 User data:

176

Field Connectors in Routing Group

Value
( aa582d35e9621c4ca8ae57aa 33d953a1 ( CONFIG ))

Comments 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.

The connector configuration information in the link state table has the following fields: Connector objectGUID
aa582d35e9621c4ca8ae57aa33 d953a1

The GUID that uniquely identifies the connector in the Exchange organization.

177

Field Connector Type

Value
{4}SMTP

Comments 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 MAPIbased 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 Source Bridgehead Address

Value
{}

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

The local bridgehead servers are then listed later in the BH field in the connector information. A bridgehead address X.400 connectors and MAPIbased connectors cannot have more than

179

Field Destination Bridgehead Address

Value
{23}_aa582d35e9621c4ca8ae5 7aa33d953a1_D

Comments As with the Source Bridgehead Address field, this field can have one of three values: 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

180

Field Legacy Distinguished Name

Value
{63}/o=TailspinToys/ou=Fir st administrative Group/cn=Configuration/cn= Connections/cn=RGC RG A <> RG B

Comments 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. 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.

Schedule ID

181

Field Restrictions

Value
0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 ()

Comments The Restrictions field identifies the scope of the connector, message size restrictions, and other constraints, as follows: The scope of the connector is identified by the first digit. A value of 0 indicates that the scope is "Organization." A value of 1 indicates that the scope is "Routing Group." Note: Routing group connectors always have a scope of "Organization." Connectors to external messaging systems can be restricted to the local routing group. The next digit indicates whether triggered delivery is configured. A value of 0 means no triggered delivery. A value of 1 means that the remote host must trigger the message transfer (for example, TURN/ETRN). The third digit identifies the message type (high, normal, low, system, and nonsystem) that is allowed through this connector. The next eight bytes

182

Field Address Spaces

Value
ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00f aab3265cd5 1 {23}c=DE;a= ;p=TailspinToys;o=Exchange ; 1 ) {4}X400

Comments 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. 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

183

Field Source Bridgeheads

Value
BH ()

Comments 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 bridgehead server is available. VS_NOT_STARTED A virtual SMTP server is stopped or is not started. CONN_NOT_AVAIL The connection is unavailable on the bridgehead server. For example, the source bridgehead server cannot establish a connection to a destination bridgehead server.

184

Field Destination Bridgeheads

Value
TARGBH ( 766a192b43bfc3459ee85608 d65a98a9 CONN_AVAIL {19}server01.TailspinToys. com )

Comments 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. In the example, the following information identifies the remote bridgehead server: Bridgehead Server objectGUID 766a192b4
3bfc3459ee85608d65a98a 9

Bridgehead Server Status CONN_AVAIL Virtual Server FQDN {19}server01.Ta

ilspinToys.com

185

Field Status

Value
STATE UP

Comments The status of the connector. This field can have two possible values: STATE UP Indicates that the connector is available. STATE DOWN Indicates that the connector is unavailable. The connector state is derived from the state of the connector's source bridgehead servers. A connector is STATE UP only if at least one source bridgehead server is available (CONN_AVAIL). If none of the connector's source bridgehead virtual servers is started (VS_NOT_STARTED) or the source bridgeheads cannot establish a connection (CONN_NOT_AVAIL), the connector state is STATE DOWN. Note: For a connector to be marked as down, all local bridgehead servers for this connector must be unavailable. Routing group connectors configured to use the option Any local server can send mail over this connector, in

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. 3. The routing engine sorts the remaining routing groups according to the current best estimate of their distance from the source routing group. It adds the closest routing group to the set of routing groups for which the shortest paths have been determined. Because routing groups B and C have the same distance value, the routing engine selects one routing group at random. This example assumes that the routing engine selects routing group B. 4. The routing engine calculates the distance value of all remaining routing groups adjacent to routing group B, by combining the cost value of the connector between routing group B and the adjacent routing group with the distance value of routing group B. It updates the distance value of an adjacent routing group only if the calculated distance value is smaller than the value that is already assigned to the routing group, and only then updates the predecessor (indicated by black arrows). The neighbors of routing group B are routing groups C, D, and E. The current distance value of routing groups C and D is not defined. Therefore, their distance value is updated with the cost values of their connectors, plus the distance value of routing group B (1+1). Then the predecessor (indicated by the source of the black arrows) for all these routing groups is updated. The predecessor is routing group B. 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

5. The routing engine sorts the remaining routing groups 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. 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 A single routing group connector with multiple source or multiple destination bridgehead servers, or both. Comments With these types of connectors, the routing engine returns the connector GUID in the next hop information for the advanced queuing engine. The advanced queuing engine then randomly selects the bridgehead server that must be used, thereby load-balancing the message transfer across all bridgehead servers. If a message reaches a source bridgehead server of a routing group connector with multiple source bridgehead servers, the message is not rerouted to any other source bridgehead server. After the message reaches the routing group connector, message transfer to the destination routing group is direct. Therefore, users who have mailboxes on the bridgehead server always use the local server for message transfer to the destination routing group. Note: It is best to specify multiple source and destination bridgeheads for a single routing group connector between two routing groups. This practice improves load-balancing and redundancy.

195

Possible configuration Multiple connectors with the same address space (or connected routing group), same weight (cost), and each with a single source and destination bridgehead server

Comments 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.

196

Load Balancing between Connectors and External Systems

Depending on the scenario, there are a few ways to achieve load balancing across SMTP connectors. If you want to load-balance outbound requests across multiple servers in the sending organization, configure multiple source bridgeheads. If you want to load-balance traffic across multiple destination servers, either have the destination administrator configure DNS correctly (using a suitable configuration of MX and A records), or specify multiple smart host addresses on the connector. Or, if you want to ensure failover resiliency, create multiple SMTP connectors scoped with the same address space, different costs, and different source bridgeheads. If the bridgehead server on the preferred connector with the lowest cost in unavailable, the connector is considered unavailable and routing automatically chooses the second connector. If you use two connectors with the same cost, Exchange servers will randomly select which bridgehead server and connector that they will use. Then if this bridgehead server becomes unavailable, they will fail over to the second connector. However, once the first bridgehead server becomes available, the servers will not fail back to this server because the route has the same cost as the server that they are already using. The connector configuration in the following figure, for example, is not load-balanced for failover configuration because the address spaces do not match. Messages sent to external users in a .NET domain always travel over the SMTP connector with the .NET address space. This is because the routing engine chooses the most detailed address before evaluating costs. A connector configuration that does not provide load balancing or fault tolerance

197

Note: If restrictions exist on the connector with the *.NET address space, and the restrictions prevent certain messages from crossing this connector (for example, because the sender is denied message transfer over this connector), the routing engine returns the message to the sender with an NDR. The routing engine does not fall back to the second connector for those messages. The most detailed address space determines which connectors can be used to transfer a message. Connectors with less detailed address spaces are excluded from the route calculation.

Message Rerouting Based on Link State Information

If a connector cannot transfer messages, the advanced queuing engine notifies the routing engine of a link failure. This might cause the routing engine to mark the connector as down, in which case all queued messages are rerouted. The routing engine considers a connector as down if one of the following conditions is true: The routing engine cannot establish a connection to at least one of the connector's source bridgehead servers, and there is no TCP/IP connection to port 691 between the routing group master and the source bridgehead servers. Unavailable source bridgehead servers are marked as VS_NOT_STARTED in the link state table. None of the source bridgehead servers can transfer the message to a destination bridgehead server successfully. Source bridgehead servers that cannot transfer messages to the destination are marked as CONN_NOT_AVAIL. Note: If you use X.400 connectors, and the connector cannot transfer messages, the Exchange MTA informs the routing engine that a link failure occurred. The state of the source bridgehead server is then CONN_NOT_AVAIL. X.400 connectors can have only one source bridgehead server.

Message Rerouting
To guarantee efficient message transfer, the routing engine informs the advanced queuing engine and Exchange MTA immediately of any link state changes. To avoid sending messages along broken paths, all queued messages must be routed again. This process is named rerouting. In rerouting, the advanced queuing engine discards all cached next hop information, because this information is no longer valid. Each message that is currently waiting to be transferred is passed to the routing engine again, to recalculate the next hop. This can be a resource-intensive task.

198

The following figure shows a rerouting example in which the bridgehead server in routing group E is down. No messages can reach this routing group currently. When the routing engine recalculates the shortest paths for messages to recipients in routing group E, it discovers that no path is available. Connectors marked as down are excluded from the routing process. Therefore, routing group E is currently isolated. Broken routing group connectors

Because no valid path exists, the routing engine cannot determine a valid next hop for messages that are waiting to be transferred to routing group E. The routing engine informs the advanced queuing engine, in the next hop type information, that the next hop is currently unreachable. The advanced queuing engine must retain the message until at least one transfer path becomes available, or until the message expires and is returned to the sender with an NDR. Note: If only one connector to a routing group exists, and there are no alternative paths, the link state is always marked as available to reduce the number of link state changes in the routing topology. Exchange Server 2003 queues the messages and sends them when the route becomes available again.

199

Rerouting and Address Spaces

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

Connector Recovery
The routing engine determines that a connector is available again in one of the following ways: VS_NOT_STARTED The routing group master establishes a connection to TCP port 691 on the source bridgehead server. The source bridgehead server is marked as CONN_AVAIL, and because at least one source bridgehead server is available for the connector, the connector state switches to STATE UP. CONN_NOT_AVAIL For unavailable connectors, the source bridgehead servers continue to retry connection at 60-second intervals, even if no messages are waiting for transfer. When a connection is established, the advanced queuing engine or the Exchange MTA reports to the routing engine an outbound connection success from the source bridgehead server. The routing engine then switches the source bridgehead server to CONN_AVAIL and the connector to STATE UP.

Rerouting and Activation Schedules

All connector types permit you to configure a schedule for the connector so that you can transfer e-mail messages at specific times. Connectors can be configured to be always

200

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

Link State Propagation

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

Link State Algorithm

The propagation of link state information differs within and between routing groups. Within routing groups, reliable TCP/IP connectivity is assumed, and servers communicate with each other over direct TCP/IP connections. Across routing groups, however, direct TCP/IP connections might not be possible. Across routing groups, Exchange Server 2003 propagates link state information through SMTP or X.400.

201

Exchange Server 2003 propagates link state information as follows: Intra-routing group LSA Within a routing group, the routing group master tracks link state information and propagates it to the remaining servers in the routing group. The remaining servers are also named member nodes or routing group members. When a member node is started and has initialized its routing table with information from Active Directory, it establishes a TCP/IP connection to port 691. It then authenticates with the routing group master and obtains most recent information about the state of all links in the routing topology. All intra-routing group connections require two-way authentication. The connection remains so that master and subordinate node can communicate with each other whenever link state changes occur. Master and subordinate in a routing group

Within a routing group, Exchange Server 2003 updates link state information as follows: a. When the advanced queuing engine or the Exchange MTA determines a problem with a bridgehead or routing group connector, it informs the local routing engine, as explained in "Message Rerouting Based on Link State Information" in Exchange Server 2003 Message Routing. b. The local routing engine, acting as a caching proxy between the routing group master and the advanced queuing engine or Exchange MTA, forwards the link state information to the routing group master over the link state connection to TCP port 691. c. When the routing group master is informed of an update, it overwrites the link state table with the new information. Based on this new information, the routing group master creates a new MD5 hash, inserts it into the link state table, and then propagates the new information to all servers in the routing group. Again, communication takes place over TCP port 691. Note: An MD5 hash is a cryptographic block of data derived from a message by using a hashing algorithm that generates a 128-bit hash from a list of blocks with 512 bits. The same message always produces the same hash value

202

when the message is passed through the same hashing algorithm. Messages that differ by even one character can produce very different hash values. d. The routing group master sends the whole link state table (that is, the OrgInfo packet) to each routing group member. Each routing group member compares the MD5 hash of the new OrgInfo packet with the MD5 hash in its own link state table and determines if the local server has the most up-to-date information. e. If the MD5 values are different, the routing group member processes the OrgInfo packet. After replacing the link state table in memory, the routing group member sends a short reply to the routing group master, now also referencing the new MD5 hash value. f. The routing group master processes this information, discovers that the routing group member is updated, and sends a short acknowledgment to the routing group member. g. Every five minutes thereafter, the routing group member polls the master to query for up-to-date routing information. Master and member node compare their MD5 hash values to determine if changes occurred. Note: All servers within a routing group must communicate with the routing group master through a reliable TCP/IP connection. Inter-routing group LSA Link state information is communicated indirectly between routing groups, using bridgehead servers and routing group connectors. To send link state information to another routing group, the routing group master communicates the link state information in the form of an Orginfo packet, which it sends to the routing group's bridgehead server over TCP port 691. The bridgehead server then forwards this information to all the bridgehead servers in other routing groups to which it connects, using the various routing group connectors it hosts. If the communication between routing groups is SMTP-based (that is, Routing Group Connector or SMTP connector), link state information is exchanged before regular message transfer by using the extended SMTP command, X-LINK2STATE, as follows: a. The source bridgehead server establishes a TCP/IP connection to the destination bridgehead over TCP port 25. b. The bridgehead servers authenticate each other using the X-EXPS GSS API command. c. After connecting and authenticating, link state communication begins using the X-LINK2STATE command. 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

203

verb to request the MD5 hash from the remote bridgehead server. The DIGEST_QUERY verb contains the GUID of the Exchange organization and the MD5 hash of the local bridgehead server. e. The remote bridgehead server now compares its MD5 hash to the MD5 hash received through the DIGEST_QUERY verb. If the hashes are the same, the remote bridgehead server sends a DONE_RESPONSE verb to indicate that the link state table does not require updating. Otherwise, the remote bridgehead server sends its entire OrgInfo packet. f. After receiving the OrgInfo packet, the remote and local bridgehead servers reverse roles and the local bridgehead server sends its own OrgInfo packet to the remote bridgehead server. Both bridgehead servers transfer the received OrgInfo packet to their routing group masters. The routing group master determines whether to update the link state table with the information from the OrgInfo packet. A higher version number indicates a more recent OrgInfo packet. Note: Routing group masters never accept information about their local routing group from a routing group master in a remote routing group. g. After the exchange of OrgInfo packets, the remote bridgehead server starts transferring e-mail messages, or issues a Quit command to end the SMTP connection. For details about SMTP communication between servers running Exchange Server 2003, see SMTP Transport Architecture. Note: When you link routing groups by means of an X.400 connector, link state information is exchanged between the MTAs as part of typical message transmission. A binary object, called the Orginfo packet, is sent in a system message to the receiving MTA before interpersonal messages are transferred. The receiving MTA then transfers the Orginfo packet to the local routing engine, which communicates the transfer to the routing group master.

An LSA Example
The following figure illustrates how the link state algorithm works in an Exchange organization that contains multiple routing groups. The figure illustrates an environment that contains an unavailable bridgehead server in routing group E. Also, the bridgehead servers in the other routing groups have not received the information that there is a routing problem.

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 TCP port 691 and transmits new link state information. The routing group master incorporates the information in the link state table and notifies all other servers in the routing group about the change. 10. The link state change causes a rerouting event in routing group C. The message is sent now to routing group D, because the routing engine still sees an available transfer path from routing group D to routing group E. The bridgehead server in routing group C informs its remaining adjacent remote bridgehead servers (routing groups A, B and D) about the link state changes. 11. The message is transferred to routing group D, but before the actual message transfer, the bridgehead servers in routing group B and C compare their MD5 hashes and exchange link state information. 12. The bridgehead server in routing group D connects to its routing group master through TCP port 691 and transmits new link state information. The routing group master 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 Value Type

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\RESvc\Parameters\ StateChangeDelay

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 Type Value Data

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\RESvc\Parameters\ SuppressStateChanges

REG_DWORD 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 Type Value Data

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\RESvc\Parameters\ ReloadOsInterval

REG_DWORD 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

213

Server 5.5, because the bridgehead server then has no link state table. Other servers still 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

This section discusses the following concepts: 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

215

messages must pass through the SMTP transport subsystem. This includes messages sent through MAPI clients, such as Microsoft Office Outlook 2003, Microsoft Office Outlook Web Access, Distributed Authoring and Versioning (DAV) protocol, X.400, and any Exchange Development Kit (EDK)-based connectors, even if the SMTP protocol is not involved, and even if recipients have their mailboxes in the same mailbox store as the sender. If you stop the SMTP service on a server running Exchange Server 2003, all message transfer and delivery stops on that server. You must understand Exchange Server 2003 message handling to understand how transport event sinks process each message. Store drivers Exchange Server 2003 implements an Exchange store driver so that the SMTP service can obtain outbound messages from the Exchange store and deliver inbound messages to Exchange recipients. You must understand the store driver implementation to identify the physical location of messages as they pass through the transport subsystem. Protocol extensions Protocol extensions implement Exchange-specific SMTP protocol commands, also called extended SMTP verbs. To understand Exchange-specific SMTP protocol features, you must understand how the protocol extensions are implemented. Logging and message tracking Protocol logging, event logging, and message tracking are features that you can use to analyze the details of message transfer. You must understand the implementation of these features, especially in troubleshooting situations. This section assumes that you are familiar with the general concept of message handling in Exchange Server 2003. For more information about message handling, see Message Routing Architecture. This section also assumes that you are familiar with the concepts of configuring virtual SMTP servers, SMTP connectors, and routing group connectors. For more information about these concepts, see the Exchange Server 2003 Transport and Routing Guide.

SMTP Service Design

The core SMTP protocol engine is implemented in SMTPSvc.dll, which resides in the \WINDOWS\system32\inetsrv directory. This protocol engine runs as unmanaged code in the IIS Inetinfo process and handles incoming and outgoing SMTP connections at the session layer. The following figure illustrates that the SMTP service is located in the Session, Presentation, and Application layers according to the Open Systems Interconnection (OSI) model of the International Organization for Standardization (ISO).

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 Value Type Value Data Description

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\InetInfo\Parameters PoolThreadLimit REG_DWORD 0 - 4,294,967,295 (unlimited)

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 Value Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Queuing MaxPercentPoolThreads REG_DWORD

The default is

0x5A (90%)

Limits the percentage of ATQ threads that the SMTP service can use. The recommended setting is:
MaxPercentPoolThreads = 90/(2*Number

of

SMTP virtual server instances) You can also increase the overall number of threads in the Inetinfo process using the following registry parameter, if sufficient memory is available for the additional threads. Location Value Type Value Data

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Queuing AdditionalPoolThreadsPerProc REG_DWORD

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 AdditionalPoolThreadsPerProcvalu e is greater than 200, you must increase the value of the PoolThreadLimit parameter under HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Servic es\InetInfo\Parameters\. Set the PoolThreadLimit to at least the same value as AdditionalPoolThreadsPerProc.

Component Object Model-Based SMTP Extensions

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

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 msExchServerBindings Description Specifies the Internet Protocol (IP) port binding for Secure Sockets Layer (SSL) connections. Indicates which type of authentication this SMTP virtual server accepts. Specifies the maximum number of inbound connections allowed for this SMTP virtual server. Specifies the log formats that this SMTP virtual server uses for protocol logging. Identifies the type of encrypted channel that this SMTP virtual server supports.

msExchAuthenticationFlags msExchMaxIncomingConnections

msExchLogType msExchAccessSSLFlags

226

Active Directory Attribute msExchServerAutoStart

Description Specifies when to start the virtual server. If true, starts the virtual server when the operating system is booted. 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). Specifies the maximum time duration before idle incoming connections are cancelled. Specifies the maximum number of outbound connections from this SMTP virtual server. Specifies the maximum time duration before idle outbound connections are cancelled. Specifies the maximum number of outbound connections from this SMTP virtual server to a particular domain. Specifies the outbound connection port number that the SMTP virtual server uses to contact a remote SMTP host. 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. Specifies the maximum number of hops that the message transported by this SMTP virtual server can take to reach the final destination. Specifies the maximum size allowed for a message delivered by this SMTP virtual server.

msExchNTAuthenticationProviders

msExchIncomingConnectionTimeout msExchSmtpMaxOutgoingConnections

msExchSmtpOutgoingConnectionTimeout msExchSmtpMaxOutgoingConnectionsPer Domain msExchSmtpOutgoingPort

msExchSmtpOutgoingSecurePort

msExchSmtpMaxHopCount

msExchSmtpMaxMessageSize

227

Active Directory Attribute msExchSmtpMaxSessionSize

Description Specifies the maximum amount of data in Kilobytes that can be transferred in one SMTP session. Specifies the maximum number of recipients allowed on a message transferred by this SMTP virtual server.

msExchSmtpMaxRecipients

msExchSmtpLocalQueueExpirationTimeout Specifies the time at which this SMTP virtual server must expire a local undelivered message. msExchSmtpLocalQueueDelayNotification Specifies the time at which this SMTP virtual server must generate a delivery status notification to inform the sender that a local message did not reach its destination. Specifies the time at which this SMTP virtual server must expire an undelivered outbound message.

msExchSmtpRemoteQueueExpirationTime out

msExchSmtpRemoteQueueDelayNotificatio Specifies the time at which this SMTP n virtual server must generate a delivery status notification to inform the sender that an outbound message did not transfer. msExchSmtpSmartHost msExchSmtpSmartHostType msExchSmtpMaxOutboundMsgPerDomain Specifies a smart host route for outbound messages from this SMTP virtual server. Specifies the smart host type. Specifies the maximum number of outbound messages that this SMTP virtual server can transfer per domain in one session. Specifies the authentication that is used when connecting outbound from this SMTP virtual server. Controls which SMTP commands are supported on inbound connections. By changing this value, you can disable features like 8BITMIME, BDAT, CHUNKING, and PIPELINING.

msExchSmtpOutboundSecurityFlag

msExchSmtpInboundCommandSupportOpt ions

228

Active Directory Attribute msExchSmtpRelayForAuth msExchSmtpPerformReverseDnsLookup

Description Determines whether the message relaying requires authentication. Specifies whether to perform reverse Domain Name System (DNS) lookups for delivery. 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. Specifies location where badmail (e-mail messages contained in the BadMail folder) is stored on the file system. Specifies an address to which to send badmail. Specifies fully qualified domain name (FQDN) for this SMTP virtual server. Specifies the directory from which mail messages are obtained. Specifies the directory from which mail messages are queued. Specifies the first, second, third, and subsequent retries for remote mail delivery. Specifies a list of IP addresses for relay restriction. Specifies a list of connectors in the SMTP virtual server's routing group for which this SMTP virtual server is the local bridgehead. Specifies a list of connectors in remote routing groups for which this SMTP virtual server is a remote bridgehead.

msExchSmtpDoMasquerade

msExchSmtpBadMailDirectory

msExchSmtpSendBadmailTo msExchSmtpFullyQualifiedDomainName msExchSmtpPickupDirectory msExchSmtpQueueDirectory msExchSmtpRemoteQueueRetries msExchSmtpRelayIpList msExchBridgeheadedLocalConnectorsDN BL msExchBridgeheadedRemoteConnectorsD NBL

229

Note: The metabase update service replicates all these configuration settings into the IIS metabase.

SMTP Configuration Settings in the Metabase

The IIS metabase is a hierarchical store of configuration and schema information, which is used to configure IIS resources. The metabase configuration and schema for IIS 4.0 and IIS 5.0 are stored in a binary file (MetaBase.bin), which is not easy to read or edit. You must use the MetaEdit tool to view and edit the metabase of IIS 4.0 and IIS 5.0. MetaEdit 2.2 is available for download at http://go.microsoft.com/fwlink/?LinkId=47942. In IIS 6.0, Extensible Markup Language (XML)-formatted files, named MetaBase.xml and MBSchema.xml, replace the earlier binary file. The IIS configuration information is stored in the MetaBase.xml file, while the metabase schema is stored in the MBSchema.xml file. When IIS is started, these files are read by the metabase storage layer and then written to the 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.

230

The following figure illustrates the hierarchy of configuration entries for SMTP virtual servers, according to the Location property of each IIsSmtp metabase entry. Hierarchy of SMTP configuration entries in the IIS metabase

Parameters that apply to the SMTP service generally are registered in the metabase in the SmtpSvc node. You can find this node when you search for the Location ="/LM/SmtpSvc". The following section is a shortened listing of this key:
<IIsSmtpService Location ="/LM/SmtpSvc" ConnectionTimeout="600" DefaultDomain="server01.TailspinToys.com" DomainRouting="" EnableReverseDnsLookup="FALSE"

231

FullyQualifiedDomainName="server01.TailspinToys.com" ... SmtpRemoteProgressiveRetry="15,30,60,240" SmtpRemoteRetryThreshold="3" > <Custom Name="AuthFlags" ID="6000" Value="AuthBasic | AuthAnonymous | AuthNTLM" Type="DWORD" UserType="IIS_MD_UT_SERVER" Attributes="INHERIT" /> ... <Custom Name="UnknownName_61537" ID="61537" Value="0" Type="DWORD" UserType="IIS_MD_UT_SERVER" Attributes="NO_ATTRIBUTES" /> </IIsSmtpService>

Under the SmtpSvc node, you find the configuration settings for each SMTP virtual server that you created on the server that is running Exchange Server 2003. SMTP virtual servers inherit the general settings configured for the SMTP service and can overwrite these settings. The following is a schematic listing of the configuration section for the default SMTP virtual server. Note the Location information.
<IIsSmtpServer Location ="/LM/SmtpSvc/1"

... property definitions that apply only to the particular virtual server ... >

232

<Custom ... custom property defintion... /> </IIsSmtpServer>

Note: When you compare the parameter names for SMTP virtual servers in the IIS metabase with the attributes of SMTP virtual servers in Active Directory, you find close matches. For example, the metabase parameter called PickupDirectory corresponds to the Active Directory attribute called msExchSmtpPickupDirectory.

Direct Metabase Editing

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

Local Domain Registrations

Under each SMTP virtual server node in the metabase, you can find important child nodes, such as Domain (Location ="/LM/SmtpSvc/1/Domain") and EventManager (Location ="/LM/SmtpSvc/1/EventManager") nodes. The domain node contains domain definitions that determine the route actions that the SMTP virtual server should perform. For example, the SMTP service must accept messages for all local SMTP domains, as defined in recipient policies, but might be required to reject any attempts to relay messages to non-local domains. The metabase update service replicates the domain information from recipient policies to the IIS metabase for all SMTP virtual servers. Note: The domain definitions also contain entries that refer to Active Directory sites. An example of such a domain name is 705260ab-46c4-454d-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.

233

Event Sink Registrations

The entries under the EventManager node are event registrations. For the SMTP service to work with event sinks, event sinks must be registered in the IIS metabase, so that the SMTP service can create and run these sinks when relevant events occur. IIsConfigObjects define event bindings in the IIS metabase. For example:
<IIsConfigObject Location ="/LM/SmtpSvc/1/EventManager/

EventTypes/{283430C9-1850-11D2-9E03-00C04FA322BA}/ Bindings/{A928AD15-1610-11D2-9E02-00C04FA322BA}/ SinkClass" > <Custom Name="MD_0" ID="0" Value="Exchange.Router" Type="STRING" UserType="UNKNOWN_UserType" Attributes="NO_ATTRIBUTES" /> </IIsConfigObject>

This binding associates the GUID of a particular event, such as 283430C9-1850-11D2-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.

234 Event binding information Property Description ID DisplayName SinkClass Enabled Property Description A GUID that uniquely identifies the binding. This information is required. An optional user-friendly name for the binding. The programmatic identifier (ProgID) of the event sink class. 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. The number of event notifications the sink can receive before the binding is disabled. This parameter is optional. A dictionary (or hash) of additional properties that are defined for the entire binding. This parameter is optional. 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.

MaxFirings

EventBindingProperties

SinkProperties

235

Property Description SourceProperties

Property Description 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

236

GUID in this example of a binding definition, A928AD15-1610-11D2-9E02-00C04FA322BA, is the CLSID of the Exchange Router class, implemented in Reapi.dll. The registry key for this COM component is HKEY_CLASSES_ROOT\CLSID\{A928AD15-1610-11d2-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

Before you perform the procedure in this topic, consider the following: 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" ... ...a472"

AdminACL="4963...

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 Exchange Server 2003. Note: The OnSubmission event is the only event that offers a Collaboration Data Objects (CDO) interface. Therefore, you can program event sinks using Microsoft Visual Basic or Visual Basic Scripting Edition (VBScript). You must program all other event sinks using C/C++ or Microsoft Visual C#. CDO-based event sinks can register for the CDO_OnArrival event, which is a wrapper around the OnSubmission event that provides a handle to the message in CDO message format. The major benefit to using CDO_OnArrival is that the CDO message object interface has many useful methods, such as the parsing of MIME and Request for

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 Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Queuing MaxPendingCat REG_DWORD 0x3E8

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. System queues in the advanced queuing engine Queue Messages With an Unreachable Destination Description 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.

247

Queue Messages Queued for Deferred Delivery

Description This queue contains messages that are queued for later delivery. This queue might contain messages that were sent by earlier versions of Microsoft Outlook, such as Microsoft Outlook 2000. Newer versions of Outlook store these types of messages in the Exchange store. Messages remain in the Messages Queued for Deferred Delivery queue until their scheduled delivery time. Note: This queue might also contain messages sent to a mailbox that was recently moved to another mailbox store or Exchange server, while waiting for directory replication to update the mailbox location.

DSN Messages Pending Submission

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

248

Queue Failed Message Retry

Description This queue contains messages that failed a queue submission. Messages can fail a queue submission for several reasons, and the failure can occur before any other processing is done. If messages are corrupted or system resources are low, messages appear in this queue.

Limiting the Number of Messages in Message Queues

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

HKEY_LOCAL_MACHINE\Software\Microsoft\Ex change\Mailmsg MaxMessageObjects REG_DWORD 0x000186a0

249

Description

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

SMTP Transport Components

In Exchange Server 2003, the advanced queuing engine uses the following six transport event sinks to deliver messages to their destinations: Exchange Transport XEXCH50 Submission This event sink is implemented in Peexch50.dll and enables the SMTP transport subsystem to receive messages from remote Exchange servers through SMTP, using the XEXCH50 command. This event is registered for the OnSubmission event. Exchange Transport AntiVirus API This event sink is implemented in OnSubmit.dll and enables non-Microsoft vendors to implement virus scanners, which check each message for malicious attachments and data structures before they reach their destinations. This event is registered for the OnSubmission event. By default, transport scanning is not enabled, as it causes messages to be scanned twice, once at the SMTP layer and once in the Exchange store. However, if you are using front-end servers to connect an Exchange organization to the Internet, you can enable this feature on these servers by using the following registry key. Location Value Type Value Data

HKey_Local_Machine\Software\Microsoft\Ex change\TransportAVAPI Enabled REG_DWORD 0x1

250

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-todate notifications for mobile devices, such as Microsoft Pocket PC, which is a new feature in Exchange Server 2003. By default, up-to-date notifications are installed with Exchange Server 2003. When an event is generated, for example, when a user receives a message, a notification is sent to the user's Pocket PC. The Pocket PC can then perform synchronization in the background, so that the most current information is available when the user next checks the device. Note: Up-to-date notifications are available only on devices that run the Microsoft Windows Mobile 2003 operating system. Exchange Router This event sink is implemented in Reapi.dll and registered for the events in the OnGetMessageRouter event category. The Exchange Router sink is the second most important component in the transport subsystem. The advanced queuing engine uses this component to determine the next hop to the message destination. For detailed information on the routing architecture of Exchange Server 2003, see Message Routing Architecture. Exchange LoadBalancer This event sink is implemented in Reapi.dll and registered for the OnDnsResolveRecord event. The advanced queuing engine uses this sink to distribute outbound message transfer evenly across all bridgehead servers

251

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 Exchangespecific features. The Exchange categorizer is implemented in PhatCat.dll. PhatCat.dll is registered for the events in the OnCategorize event category. The advanced queuing engine triggers these events through the base categorizer. The base categorizer and Exchange categorizer jointly process the message in ten categorizer events. Note: The base categorizer triggers the events that drive the message categorization process. The advanced queuing engine triggers the following ten categorizer events: Register The base categorizer and the Exchange categorizer use this event to initialize their interfaces. For example, the Exchange categorizer initializes its interfaces to Directory Service Access (DSAccess), routing engine, and store driver. If any one of these interfaces fail, then the Exchange categorizer fails to initialize itself. All categorizers require interfaces to these components for the following reasons: a. Communication with DSAccess is required to determine if recipients are in the DSAccess cache, in which case the required information can be obtained directly from DSAccess without the overhead of performing Active Directory lookups. The Exchange categorizer also determines the list of global catalog servers that DSAccess is using and provides this list to the base categorizer to use for its Lightweight Directory Access Protocol (LDAP) lookups. By default, the base categorizer uses the Active Directory domain topology to determine the global catalog servers for LDAP lookups. However, on a server running Exchange Server 2003, the categorizer should use the global catalog servers that DSAccess determined dynamically, based on the Active Directory site topology, or statically, if you hard coded global catalog servers in a DSAccess profile in the registry. For more information about the DSAccess discovery process, see Exchange Server 2003 and Active Directory. b. Communication with the routing engine is necessary, for example, when encapsulating a non-SMTP one-off address to an SMTP address. A one-off 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

252

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

253

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 queries to Active Directory. The following is an example of an LDAPcompliant search filter that can be used to find multiple users at once:
(|(proxyAddresses=smtp:Ted@fabrikam.com) (proxyAddresses=smtp:Birgit@fabrikam.com))

254

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 Possible cause Troubleshooting 5.1.4 Two objects have the same (proxy) address, and mail is sent to that address. Check the recipient address and resend the message. This issue can also occur if the recipient does not exist on the remote server. For more information about NDR codes, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server."

Comments

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

255

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. Details of non-delivery reports with code 5.1.1 Numerical code 5.1.1

256

Possible cause

The e-mail account does not exist at the organization to which this message was sent. For example, if an Internet user sends a message to user_does_not_exist@fabrikam.com, where your server is authoritative for fabrikam.com and no one in Active Directory has that address, a 5.1.1 NDR is generated. A 5.1.1 NDR is an "authoritative not found" NDR. It applies to SMTP addresses according to recipient policies, to legacyExchangeDN recipients according to the legacyExchangeDN attribute of the local administrative group, and to X.400 addresses according to the administrative group's X.400 site address. Otherwise, a 5.1.2 NDR is generated any time you have a non-SMTP address that is not routable and does not match a recipient object in Active Directory.

Troubleshooting

Either the recipient address is incorrectly formatted or the categorizer cannot properly resolve the recipient. You must check the recipient address and resend the message to resolve this error. For more information about NDR codes, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server."

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 perrecipient 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 Possible cause Troubleshooting 5.5.3 Too many recipients on the sent message. 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. For more information about NDR codes, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server."

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.

258 Details of non-delivery reports with code 5.4.6 Numerical code Possible cause 5.4.6 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 For more information about NDR codes, see Microsoft Knowledge Base article 284204, "Delivery status notifications in Exchange Server and in Small Business Server."

Message bifurcation If recipients require different message formats, the Exchange categorizer bifurcates the message to create multiple message copies. Message bifurcation is explained in more detail later in this section. CompleteItem The base categorizer calls this event to perform final processing when the work of all other categorizer event sinks is complete. Final processing includes the following tasks: Journaling Journaling is the process of copying messages sent or received by users on an Exchange server to a message archive. If the 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

259

envelope and forwards a copy of the message to the archive mailbox for that sender. Servers running Exchange Server 2003 communicate message transfer envelope information, including the list of journal addresses for sender and recipients, using the XEXCH50 command. If multiple Exchange servers are involved in message transfer and a server finds a journaling address in the message transfer envelope, it does not add the journaling address again, thus preventing duplicate messages in the message archive. Note: Message journaling might not reliably account for blind carbon-copy recipients, recipients from transport forwarding rules, or recipients from distribution group expansions. If you must record the message transport envelope data, in addition to the message data, you must enable Envelope Journaling. This is accomplished using the E-Mail Journaling Advanced Configuration tool, available for download at the Exchange Server Email Journaling Advanced Configuration Web site. Forwarding unresolved recipients If you configured the SMTP virtual server to forward all messages with unresolved recipients to an alternate host, the Exchange categorizer sets the destination server for all unresolved recipients to the fully qualified domain name (FQDN) of the alternate server. Recipient marking The Exchange categorizer marks each recipient by setting a per-recipient property on the message. This property indicates the destination server for each recipient. The typical format of this property is the FQDN of the recipient's home server. Based on the FQDN that the categorizer sets on each recipient, the advanced queuing engine decides whether to deliver the message locally or call the routing engine. All messages matching the local server's FQDN go straight from the pre-routing queue to the local delivery queue, without performing message routing. For recipients that are not local, the advanced queuing engine must call the routing engine later to determine the next hop for message transfer. 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

260

requests delivery or read receipts, the delivery status notifications are generated and sent to the distribution group, rather than to the sender only. To address this issue, the categorizer directs status notifications to the actual sender by changing the sender address in the message transfer envelope of the message to the address of the actual sender. Users rarely send messages on behalf of a distribution group. A more common situation occurs when a user receives multiple out-of-office notifications, auto replies, and delivery status notifications, such as non-delivery reports, after sending a message to a large distribution group. To mitigate this issue, the Exchange categorizer suppresses out-of-office notifications and auto replies by default when sending messages to a distribution group. To accomplish this, the Exchange categorizer adds a property to the recipients in the message envelope. The Exchange store uses this property as a parameter during local delivery operation to suppress rules which would otherwise generate out-of-office notifications and auto replies. This extended property of the message envelope is transmitted between servers running Exchange Server 2003 using XEXCH50, if the individual distribution group members reside on different mailbox servers. The Exchange categorizer redirects or deletes out-of-office notifications, auto replies, and delivery status notifications according to the criteria listed in the following table.

261 Delivery status notification redirection and deletion criteria Criteria Action

Distribution group has an owner, and Redirect non-delivery reports to notify the delivery reports are configured to be sent to configured owner of the group when an this owner error occurs during the delivery of a message to the group or to one of its members. The categorizer redirects any non-delivery reports for group members that would usually return to the message sender. By default, only NDRs are redirected to the group owner. In cases in which a sender requests explicit status notifications (such as a delivery receipt notification), SMTP protocol delivery status notification extensions are used to generate the reports. If a sender requests a delivery status notification in a message to a group with report redirection enabled, the sender receives the delivery status notification when the group is either expanded successfully or redirected to its expansion server (if the local server is not an expansion server for the group). Delivery reports are configured to be sent 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 Exchange-Advanced tab, is not selected for the group. By default, this check box is not selected.

262

Criteria

Action

Distribution group is configured to suppress Suppress all out-of-office notifications, auto delivery reports for group members to avoid replies, and all types of delivery status disclosing membership information notifications (such as delivery notifications and read receipts). This is similar to redirecting NDRs, except that the categorizer suppresses all types of delivery notifications, including non-delivery reports for individual group members. To block all delivery reports, the categorizer changes the sender address in the message transfer envelope of the message to "<>". If a sender requests a delivery status notification (such as a delivery receipt notification) in a message to the group, SMTP protocol delivery status notification extensions generate the delivery status notification when the group is either expanded successfully or redirected to its expansion server (if the local server is not an expansion server for the group).

Note: By default, the categorizer suppresses out-of-office notifications, auto replies, and delivery status notifications when a user sends a message to a distribution list. You can configure this by selecting the Send out-of-office messages to originator check box, on the Exchange-Advanced tab, in the distribution group properties. For more information, see Microsoft Knowledge Base article 325469, "Automatic replies from distribution group do not work in Exchange Server 2003 or Exchange 2000 Server." Status code mapping The Exchange categorizer also maps the status codes that previous categorizer sinks have returned to the recipients in the e-mail message. Error codes then cause the advanced queuing engine to generate NDRs for affected recipients.

Message Bifurcation
As mentioned previously, the categorizer might create multiple copies of a message during the categorization process. This process is called bifurcation and is performed any time

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\Ex change\StoreDriver\Exchange\nn\EnableTne f

Value Type Value Data Description

Disabled REG_DWORD 0x0

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

268

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

Categorizer Performance Tuning

As mentioned in the section "Exchange Categorizer" earlier in this topic, the Exchange categorizer determines the list of global catalog servers to use for LDAP lookups from DSAccess. DSAccess determines this list dynamically, based on the Active Directory site topology or statically, if you hard coded global catalog servers in a DSAccess profile in the registry, as explained in Exchange Server 2003 and Active Directory.

269

By default, DSAccess determines the list of global catalog servers dynamically, which enables global catalog servers to be excluded from the list, if they become unavailable for any reason. The connection retry period for an unavailable global catalog server is five minutes. By default, DSAccess recalculates its list at least every 15 minutes. The Exchange categorizer calls DSAccess once every hour to update the list of global catalog servers. The Exchange categorizer also updates the list of global catalog servers if there are more than 100 connection failures per global catalog server. A global catalog server might be down for maintenance or other reasons, or there might be a network communication problem causing an LDAP connection to fail. You can use the following registry parameters to specify the timeout values that the categorizer uses to classify LDAP connections as not operational. Caution: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Location Value Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters LdapResultTimeout REG_DWORD 0x79

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters LdapRequestTimeLimit

270

Type Value Data Description

REG_DWORD 0x258

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 Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters MaxConnectionRetries REG_DWORD 0x14

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 Type Value Data

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\SMTPSVC\Queuing CatRetryMinutes REG_DWORD 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 Type Value Data

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters MaxLdapConnections REG_DWORD 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

273

required to match the results to the recipients in the message. Batched LDAP searches work well for individual recipient objects that can be grouped together into a single query to a global catalog. Most Exchange categorizer operations are in this category, but there are exceptions. The categorizer uses non-batched queries in the following situations: The categorizer must expand a dynamic distribution group.

The categorizer must request paged attributes. For example, this is the case for distribution groups with more than 1,000 members. Note: The Exchange categorizer checks with DSAccess to determine if a recipient object is in the DSAccess cache. For cached objects, directory lookups are not performed. You can manage the performance of the Exchange categorizer using the following registry keys. For example, you can increase the maximum number of recipients in a batched search. However, dramatically increasing this number might actually have a negative impact on performance, because the overhead for matching results to recipients also increases. In general, the default values are sufficient for most situations. Therefore, it is not a good idea to change these values without the assistance of a Microsoft Product Support specialist. Location Value Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters MaxSearchBlockSize REG_DWORD 0x14

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 Type Value Data

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Parameters MaxPendingSearches REG_DWORD 0x3C

274

Description

This is the maximum number of prebatched, 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: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting

277

from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Location Value Type Value Data Description

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\SMTPSVC\Queuing\ ResetMessageStatus REG_DWORD 0x1

This parameter forces re-categorization of all messages on enumeration. If this parameter does not exist, the default is no re-categorization (0x0). For changes to take effect, you must stop and restart the SMTP service. After the SMTP service is restarted, the categorizer enumerates and reprocesses all previously queued messages. When the messages leave the \Queue folder, delete the ResetMessageStatus key again. You can then restart the SMTP service to resume normal operation.

SMTP Service Store Drivers

The advanced queuing engine passes a MailMsg object (an in-memory message object that allows for fast processing) from sink to sink. The MailMsg object is made up of a message transfer envelope and a pointer to the actual physical message, if the message resides in the \Queue directory on NTFS. If the message resides in the Exchange store, the pointer refers to the RFC 822 content of the message, which is in a temporary file in the streaming database. Note that event sinks do not work with MAPI messages directly, and any changes to a MAPI message during message processing in the transport subsystem are not persisted. Components, such as the categorizer, use the message pointer primarily to read data from the message content. The advanced queuing engine also uses the message pointer to manage the deletion of messages when requested.

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 "x-receiver" headers are not copied to the content written to the file in the \Queue directory. The following is an example of an Internet text message with extended header information for recipients and sender. The "x-receiver" header identifies a single recipient. If you want to include multiple recipients, add an "x-receiver" header for each recipient. The header must appear first in the text file, with the "x-sender" header listed first. According to RFC 822, there must be an empty line between the header information and the body of the message. The file name of the message item is not important. The SMTP service uses its own logic to name the message file in the \Queue directory and append an .eml file name extension, for example NTFS_7224ae2001c4125c0000001b.eml.
x-sender: Ted@contoso.com x-receiver: Birgit@fabrikam.com From: Ted@contoso.com To: Birgit@fabrikam.com Subject: RFC 822 Pickup Message

This message is passed to the SMTP service through the \Pickup directory.

Note: You should create the text messages in another folder on the file system and then move the messages to the \Pickup folder. To avoid conflicts with the monitoring SMTP service, do not create the files directly in the \Pickup folder. \Queue This folder holds all messages received through SMTP that are currently waiting for transfer to a remote destination through SMTP. However, messages received through the Exchange store are not in this directory during processing in the SMTP transport subsystem. Messages might accumulate in this folder if a connection is busy or currently unavailable.

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 highvolume 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

285

provides access to all private and public databases. The format is file://./backofficestorage/DomainName, such as file://./backofficestorage/fabrikam.com. Note: Win32 files are used primarily by the HTTP-DAV protocol and EXOLEDB and CDOEX APIs. EA EA is the acronym for extended attributes, which are stored in a special property of each message. ExIFS copies the extended attributes to an in-memory structure called the scatter list (SLIST). The scatter list is basically a binary large object (BLOB) that can be used to open a message item. EA files are for internal use by the Exchange transport subsystem and are not visible to users through any one of the documented APIs or protocols. An EA path might look like this: \;E:\Ted\$705260a-46c4-454d-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

286

Outbound Message Transfer

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

287

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

288

parameters to pass a message request packet through Epoxy.dll to Exsmtp.dll inside the Store.exe process. 12. Exsmtp.dll calls an internal Exchange store method named EcGetMime with the folder ID and message ID to request the content of the message in RFC 822 format, specifying any additional parameters that Drviis.dll might have passed. Note: You might notice the EcGetMime call in application event log entries with an event source of MSExchangeTransport and an event category of Exchange Store Driver. For an example, see Microsoft Knowledge Base article 319682, "XGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be Fragmented." 13. Because the message was submitted through Outlook, the message is not in RFC 822 format. The message is in MAPI format, stored in the .edb file. Therefore, the content that Exsmtp.dll is requesting does not exist in the streaming database (that ExIFS is using) when the message is opened by a transport component or Internet client. Note: Exchange Server 2003 stores messages received from MAPI clients, X.400 connectors, or Exchange Development Kit (EDK)-based connectors in MAPI format in the .edb database. 14. If the message does not exist in the streaming database, it must be created using the various properties and tables in the .edb database that describe the message. Accordingly, the Exchange store uses IMAIL to create a temporary ExIFS file and to render the message from the database to that file in RFC 822 format, according to the requested formatting parameters that are passed. Note: The Exchange categorizer uses the IMAIL mechanism to apply message formats to the content, as defined for Internet domains in Exchange System Manager or as specified by the user per recipient in Outlook. If no formatting parameters are passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF) format. 15. In Exchange Server 2003, ExIFS.sys creates a temporary ExIFS file so that a malfunctioning event sink that attempts to modify the RFC 822 content cannot corrupt the committed pages in the streaming database. Instead of writing to actual content pages, the event sink is writing to a copy only. 16. Once the temporary ExIFS file is generated, the file handle is passed back to Exsmtp.dll. Exsmtp.dll calls to ExIFS to retrieve a pointer to the pages that the file occupies in the streaming database (that is, to the extended attributes which ExIFS copies to an in-memory structure called a scatter list).

289

17. Exsmtp.dll copies the scatter list to shared memory and passes the list back to Drviis.dll through Epoxy.dll. 18. Drviis.dll uses this scatter list to open the ExIFS file in the form of an extended attributes (EA) file. Now that Drviis.dll has the open ExIFS file handle, it returns the file handle to MailMsg, which can then process ReadContent or WriteContent requests to the RFC 822 message content. 19. The SMTP protocol engine can now read the message content and transfer the data to a remote host or Exchange server through SMTP. 20. After successful message transfer, the advanced queuing engine deletes the MailMsg object, because it is no longer needed. Accordingly, the advanced queuing engine calls to the Exchange store driver (drviis.dll) to delete the message. Drviis.dll creates a request to delete the message in shared memory and transfers the request through EPOXY to Exsmtp.dll. Then Exsmtp.dll either moves the message from the sender's Outbox to the Sent Items folder or deletes the message. Note: The content is re-rendered every time it is requested. Each time the content is requested, it is returned in a temporary ExIFS file. As long as that file remains open, it can be used. After the file is closed, it is automatically discarded, because it is only a temporary copy of the message. To minimize the number of rendering cycles, the advanced queuing engine keeps the content file open until the message is transferred or delivered. The content file is closed only when messages are ready to be deleted or are scheduled to be retried at a later time. A message might be retried at a later time either because the remote server is unavailable, or because more than 10,000 content files are open and actively processed in the queue. If more than 10,000 content files are open and actively processed, some files must be closed to make room for other messages. When a message is opened again at a later time (for example, because message transfer is retried), the content must be re-rendered. It is important to understand that IMAIL renders a new temporary ExIFS file when the file is opened. Any changes to this ExIFS file are lost when the file is closed.

Inbound Message Transfer

The Exchange store driver performs the following steps for inbound messages that must be delivered to a local recipient or the Exchange MTA. 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.

290

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

291

store driver, the call is passed to NTFSDrv.dll, which deletes the message from the \Queue directory on the file system. Message was submitted through the Exchange store driver The advanced queuing engine calls back to MailMsg to delete the message. Because the MailMsg object is bound to the Exchange store driver, the call is passed to Drviis.dll, which queues an EPOXY request to ExSMTP.dll. ExSMTP.dll then either moves the message from the sender's Outbox to the Sent Items folder or deletes the message. Note: Messages for remote recipients that arrive through \Pickup directory or SMTP protocol engine do not reach the Exchange store. They remain in the \Queue folder on the file system until they are successfully transferred to the next hop on route to their destination. However, the categorizer might use the Exchange store for messages that are not delivered through the Exchange store driver. The categorizer might need to generate delivery status notifications, which are created in the Exchange store.

Transfer Retries
Note that messages that enter the advanced queuing engine through the Exchange store driver remain in the Exchange store during the categorization and routing process, as well as during the actual transfer process. The message is not copied to the SMTP virtual server's \Queue folder. These types of messages also remain in the Exchange store if a connection failed and must be retried. If a message cannot be transferred immediately, it is moved to a temporary table. Therefore, the message disappears from the sender's Outbox folder and is copied to the Sent Items folder (if Outlook is configured to keep a copy of all messages in the Sent Items folder). The message remains in the temporary table until it is transferred successfully or expires. You can view these messages in the Failed Message Retry queue using the Queue Viewer snap-in in Exchange System Manager.

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

292

communicate with other Exchange servers in the organization more efficiently than over standard SMTP. You can verify that the extended SMTP commands for Exchange Server 2003 are loaded when you connect to the TCP port of your SMTP virtual server using telnet. As shown in the following figure, the server response indicates the features that the SMTP virtual server supports when you submit the EHLO command to initiate an ESMTP connection. The standard commands are listed when you submit a HELP command. Standard and extended SMTP commands of Exchange Server 2003

The following table explains the SMTP features that the Exchange-extended SMTP service supports. SMTP features supported in Exchange Server 2003 SMTP Server Response 8BITMIME Comments Indicates that the local SMTP virtual server supports eight-bit Multipurpose Internet Mail Extensions (MIME) messages. 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.

AUTH, AUTH GSSAPI NTLM LOGIN, and AUTH=LOGIN

293

SMTP Server Response BDAT, CHUNKING

Comments 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. Sent by a remote host to initiate the transfer of message content. An ESMTP command that enables delivery status notifications as defined in Request for Comments (RFC) 1891.

DATA DSN

294

SMTP Server Response EHLO

Comments 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). 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. 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. Sent by a client to identify itself, usually with a domain name, and to signal the start of a standard SMTP session. Returns a list of SMTP commands that are supported by the SMTP virtual server in standard SMTP sessions (as opposed to ESMTP sessions). Identifies the start of a message transfer by identifying the sender of the message; used in the form MAIL FROM. Provides the ability to send a stream of commands without having to wait for a response after each command. Signals the end of a standard or extended SMTP session. Identifies the message recipients; used in the form RCPT TO. Nullifies the entire message transaction and resets the buffer.

ENHANCEDSTATUSCODES

ETRN

HELO

HELP

MAIL

PIPELINING

QUIT RCPT RSET

295

SMTP Server Response SIZE

Comments 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. 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. Allows a remote host and the local host to switch roles and send mail in the reverse direction, without establishing a new connection. 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> 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.

STARTTLS

TURN

VRFY

XEXCH50

296

SMTP Server Response X-EXPS GSSAPI NTLM LOGIN, XEXPS=LOGIN

Comments 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: 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-64encoded user name and password.

X-LINK2STATE

Adds support for link state propagation to the SMTP service. For details about the link state algorithm used to propagate link state information within and between routing groups, see Message Routing Architecture.

Note: All Exchange-specific SMTP commands start with "X-" (without the quotation marks). If these commands are not listed in the EHLO response of your SMTP virtual server, then the server is running the Windows Server 2003 base version of the SMTP service. In this case, you must reinstall Exchange Server 2003 and any Service Packs.

Protocol Event Categories

The SMTP protocol engine triggers protocol events to control the host-to-host communication. There are three main types of events that can occur in such a communication over SMTP:

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 OnInboundCommand Comments Occurs when an SMTP command is received by the SMTP protocol service, which gives an event sink an opportunity to respond. Occurs when the SMTP service receives an SMTP response to a previously sent SMTP command. Occurs before the EHLO command is transmitted. Occurs before the MAIL FROM command is transmitted. Occurs before the RCPT TO command is transmitted. Occurs before the DATA protocol command is transmitted. Occurs before the QUIT command is transmitted.

OnServerResponse

OnSessionBegin OnMessageStart OnPerRecipient OnBeforeData OnSessionEnd

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. Protocol extensions for the XEXCH50 command Event sink Exchange SMTP Protocol XEXCH50 Before Data Sink Protocol event OnBeforeData Comments 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. Notifies the XEXCH50 sink that an EHLO command was received. Implements the XEXCH50 command to start an XEXCH50 conversation. Implements the MAIL command in an XEXCH50 conversation. Enables the local SMTP virtual server to receive recipient information in an incoming XEXCH50 communication. Enables the local SMTP virtual server to send recipient information in an outgoing XEXCH50 communication.

Exchange SMTP Protocol XEXCH50 Inbound EHLO Sink Exchange SMTP Protocol XEXCH50 Inbound XEXCH50 Sink Exchange SMTP Protocol XEXCH50 Inbound MAIL Sink Exchange SMTP Protocol XEXCH50 Inbound RCPT Sink

OnInboundCommand

OnInboundCommand

OnInboundCommand

OnInboundCommand

Exchange SMTP Protocol XEXCH50 Per Recipient Event Sink

OnPerRecipient

299

Event sink Exchange SMTP Protocol XEXCH50 Ehlo Response Sink

Protocol event OnServerResponse

Comments Enables the local SMTP 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). Enables the local SMTP 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.

Exchange SMTP Protocol XEXCH50 Response Sink

OnServerResponse

300

Event sink Exchange SMTP Protocol XEXCH50 RCPT Response Sink

Protocol event OnServerResponse

Comments Enables the local SMTP 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.c om.

X-LINK2STATE This feature is implemented using five event sinks. However, one event sink is used for two separate events, as indicated in the following table. All XLINK2STATE event sinks are implemented in Xlsasink.dll in the \Program Files\Exchsrvr\bin directory. Protocol extensions for the X-LINK2STATE command Event sink EHLO Inbound Command Handler Sink for XLSA Protocol event OnInboundCommand Comments Notifies the X-LINK2STATE event sinks that an incoming EHLO command was received. Notifies the X-LINK2STATE event sinks that an incoming X-LINK2STATE command was received.

X-LSA Inbound Command Handler Sink

OnInboundCommand

301

Event sink X-LSA Sink

Protocol event OnMessageStart, OnSessionEnd

Comments Signals the start (MAIL command) and end (QUIT command) of an outbound X-LINK2STATE communication. Because the remote SMTP virtual server is the ultimate recipient of the Orginfo packet being transmitted, there is no need to specify recipients in an outbound RCPT command. This event sink transmits the link state information. 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. Responds to an incoming EHLO command by listing the X-LINK2STATE command in the server response.

X-LSA Response Handler Sink

OnServerResponse

EHLO Response Handler Sink for X-LSA

OnServerResponse

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.

302 X-EXPS protocol security extensions Event sink Exchange SMTP Protocol Security EXPS-EOD Sink Exchange SMTP Protocol Security EXPS-Aux Sink Exchange SMTP Protocol Security EHLO Sink Protocol event OnInboundCommand OnInboundCommand OnInboundCommand, OnServerResponse Comments Signals the end of data transfer ( _EOD). Signals an incoming AUTH command. Signals an incoming EHLO command and responds to EHLO by listing the X-EXPS command in the server response. 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. 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.

Exchange SMTP Protocol Security Mail Sink

OnInboundCommand, OnServerResponse, OnMessageStart

Exchange SMTP Protocol Security EXPS Sink

OnInboundCommand, OnServerResponse, OnSessionStart

SPAM Control This feature is implemented using three event sinks that process sender and recipient information on incoming SMTP connections, as listed in the following table. The spam control event sinks are implemented in Turflist.dll in the \Program Files\Exchsrvr\bin directory.

303 Spam control SMTP extensions Event sink RCPT Inbound Command Handler Sink Protocol event OnInboundCommand Comments Signals an inbound RCPT command with a recipient address that should be checked. Signals an inbound MAIL command with a sender address that should be checked. Signals an inbound _EOD command.

MAIL Inbound Command Handler Sink for TURF

OnInboundCommand

EOD Inbound Command Handler Sink

OnInboundCommand

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.

304

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.

305

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 Exchange System Manager. 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

306

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

Before you perform the procedure in this topic, consider the following: 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.

307

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

Before you perform the procedure in this topic, consider the following: 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: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry

308

incorrectly may not be able to be resolved. Before editing the registry, back up 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

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 Exchange System Manager

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

Before you perform the procedure in this topic, consider the following:

309

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.

310

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/). This section discusses the following concepts: 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.

311

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.

312 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.

313

SMTP service In Exchange Server 2003, the Exchange MTA does not perform message routing. Message routing is the task of the routing engine, which is part of the SMTP service. The Exchange MTA communicates with the routing engine through Mtaroute.dll to make its routing decisions. Note that the communication with the SMTP service is bi-directional. The MTA communicates with the SMTP service for message routing purposes. The SMTP service initiates communication when the routing topology changes, to inform the MTA that all messages must be rerouted. For more information about the interaction between the MTA and the SMTP service, see Connecting Routing Groups Using X.400 Connectors. Exchange store As illustrated in the following figure, the SMTP service passes outbound messages to the Exchange MTA through the MTA's message queue in the Exchange store. The Exchange MTA also passes inbound messages to the SMTP service through the Exchange store. Communication with the Exchange store is required if messages must be transferred over MAPI-based messaging connectors for which the Exchange MTA is responsible. MAPI-based messaging connectors, similar to the SMTP service, maintain message queues in the Exchange store, as explained in Gateway Messaging Connectors Architecture. MTA communication through the Exchange store

314

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

315

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.

316 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.

317 Important attributes of the MTA directory object Directory Attribute objectClass cn transRetryMins Purpose Identifies the directory object as an MTA object. Contains the common name (cn) of the MTA. Defines the period of time between transfer retries in minutes. The default is five minutes. Defines the timeout period for message transfer in minutes. The default is 20 minutes. 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. Defines the maximum deliverable message size, in kilobytes (KB), that can be sent over the MTA. Specifies the location of the diagnostic registry key. If this key does not exist, the MTA uses the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\Curren tControlSet\Services\MSExchangeMTA\Dia gnostics. 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.

transTimeoutMins

mTALocalDesig

delivContLength

diagnosticRegKey

expandDLsLocally

318

Directory Attribute msExchHomeRoutingGroupDNBL associationLifetime

Purpose A back link to the routing group of which this MTA is a member. 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. 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. Specifies the maximum number of times that the Exchange MTA tries to transfer a message across an open connection. The default is two times. Specifies the number of seconds that the system waits after an error before attempting to reopen a connection. The default is 600 seconds. 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. 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. 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. Specifies the amount of time in seconds that the Exchange MTA waits before ending a connection after all associations over this connection are ended.

numOfOpenRetries

numOfTransferRetries

openRetryInterval

rTSCheckpointSize

rTSRecoveryTimeout

rTSWindowSize

sessionDisconnectTimer

319

Directory Attribute tempAssocThreshold

Purpose 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. Specifies the number of seconds that the system waits after a message transfer fails before re-sending a message across an open connection. The default is 120 seconds. Specifies the amount of time in seconds per kilobyte that the system waits before sending an a non-delivery report (NDR) for a non-urgent message. Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for a normal message. Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for an urgent message. Indicates the path to the MTA database directory. Contains the distinguished name of the server hosting the MTA.

transferRetryInterval

transferTimeoutNonUrgent

transferTimeoutNormal

transferTimeoutUrgent

msExchMTADatabasePath msExchResponsibleMTAServerBL

320

Directory Attribute msExchEncryptedPassword

Purpose Specifies the MTA password that remote MTAs must use when connecting to this MTA. The password can be up to 64 characters long and is stored in Active Directory in encrypted form. Note: The MTA password is stored in encrypted form in Active Directory, but this does not mean that MTA names and passwords are secure. X.400 MTAs exchange their names and passwords in clear text when establishing connections.

Internal Exchange MTA Architecture

The internal architecture of the Exchange MTA is based on thread pools, message queues, and database queues. Threads perform the actual processing within the Exchange MTA process (Emsmta.exe). Message queues, indicated by arrows in the following figure, handle interactions and notifications between threads. Database queues contain messages waiting for processing by one of the thread pools. For example, the work queue, shown in the following figure, is a database queue that holds messages until the MTA has transferred them successfully or until they expire and are returned to the sender with a non-delivery report (NDR). Running multiple threads allows the Exchange MTA to perform multiple tasks concurrently. This figure shows the internal architecture of the Exchange MTA.

321 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. Location

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data

Transfer threads REG_DWORD 0x1

322

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 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

323

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

Dispatcher threads REG_DWORD 0x1

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). The default value is 0x1. The recommended value is 0x3 if this MTA communicates with more than five LAN-MTAs.

Submit and deliver threads These thread pools are a legacy from Exchange Server 5.5. They are not used in Exchange 2000 Server and Exchange Server 2003 under typical circumstances, because in Exchange 2000 Server and Exchange Server 2003, there is no direct submit or delivery. All messages must pass through the SMTP service. The SMTP service delivers messages to local recipients through the Exchange store driver, as explained in SMTP Transport Architecture. The Exchange MTA treats the SMTP service similar to a MAPI-based connector with message queues in the Exchange store. XAPI gateways handle the message transfer in and out of the message queues in the Exchange store. XAPI gateways are threads in the Exchange store that interface with the XFER IN and XFER OUT MTA threads. The Exchange MTA uses the following threads for inter-process communication and to perform system functions, such as updating configuration information when changes occur. OSI stack The Exchange MTA uses a number of thread pools to handle communication tasks between the various layers of the Open Systems Interconnection (OSI) stack. These thread pools include reliable transfer service (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.

324

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

MTA database path REG_SZ C:\Program Files\Exchsrvr\Mtadata

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

DB data buffers per object REG_DWORD 0x3

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. The default value is 0x3. The recommended value is 0x6 if this MTA communicates with 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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services \MSExchangeIS\<server_name>\Private<database_guid>

Value Type Value Data

Gateway In Threads Gateway Out Threads REG_DWORD 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 Adjacent MTA Associations Messages/Sec Message Bytes/Sec Free Elements Description The number of open associations that this MTA has to other MTAs. The rate at which messages are processed. The rate at which message bytes are processed. The number of free buffer elements in the MTA pool.

333

Performance counter Free Headers Admin Connections

Description The number of free buffer headers in the MTA pool. The number of Microsoft Exchange Administrator programs connected to the MTA. The number of threads in use by the MTA. This number can be used to determine whether additional processors might be beneficial. The number of outstanding messages in the Work Queue. This indicates the number of messages not yet processed to completion by the MTA. The number of XAPI gateways connected to the MTA using the XAPI interface. A single gateway can have multiple XAPI gateway sessions. The number of XAPI clients connected to the MTA using the XAPI interface. A single client can have multiple XAPI client sessions. The number of disk file delete operations per second. The number of disk file sync operations per second. The number of disk file open operations per second. The number of disk file read operations per second. The number of disk file write operations per second. The rate of read calls to the Directory service. The rate at which bytes are received over a XAPI connection.

Threads In Use

Work Queue Length

XAPI Gateways

XAPI Clients

Disk file deletes Disk file syncs Disk file opens Disk file reads Disk file writes ExDS Read Calls/sec XAPI Receive Bytes/sec

334

Performance counter XAPI Transmit Bytes/sec Admin Interface Receive Bytes/sec Admin Interface Transmit Bytes/sec LAN Transmit Bytes/sec LAN Receive Bytes/sec RAS Receive Bytes/sec

Description The rate at which bytes are transmitted over a XAPI connection. The rate at which bytes are received over an admin connection. The rate at which bytes are transmitted over an admin connection. The rate at which bytes are transmitted over a LAN to MTAs. The rate at which bytes are received over a LAN from MTAs. The rate at which bytes are received over a RAS connection. RAS-based X.400 connectors are not available in Exchange Server 2003. The rate at which bytes are transmitted over a RAS connection. RAS-based X.400 connectors are not available in Exchange Server 2003. The rate at which bytes are received over a TCP/IP connection. The rate at which bytes are transmitted over a TCP/IP connection. The rate at which bytes are received over a TP4 connection. TP4-based X.400 connectors are not available in Exchange Server 2003. The rate at which bytes are transmitted over a TP4 connection. TP4-based X.400 connectors are not available in Exchange Server 2003. The rate at which bytes are received over an X.25 connection. The rate at which bytes are transmitted over an X.25 connection.

RAS Transmit Bytes/sec

TCP/IP Receive Bytes/sec TCP/IP Transmit Bytes/sec TP4 Receive Bytes/sec

TP4 Transmit Bytes/sec

X.25 Receive Bytes/sec X.25 Transmit Bytes/sec

335

The Exchange MTA also provides a performance object for each connection established by the MTA. In the Add Counters dialog box, select the MSExchangeMTA Connections object from the Performance object drop-down list. You can then find the individual connection instances under Select instances from list. Each MSExchangeMTA Connections instance describes a single connection, but you can also choose to monitor all instances together. Performance counters for individual connections established by the MTA

The following table lists the performance counters that are available for MSExchangeMTA Connections performance objects. MSExchangeMTA connections performance counters Performance counter Associations Description The number of associations between the MTA and the connected MTA. MTAs can open multiple associations, if additional transfer throughput is necessary. The rate at which bytes are received from the connected entity.

Receive Bytes/sec

336

Performance counter Send Bytes/sec Receive Messages/sec Send Messages/sec

Description The rate at which bytes are sent to the connected entity. The rate at which messages are received from the connected entity. 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

337

information. Do not forget to reset the logging level on all categories to None when you are done examining the MTA. Tip: It is also possible to filter events according to event sources and categories. In Event Viewer, select the Application log, click View, and then click Filter. Under Event source, select MSExchangeMTA. To display all events of the Exchange MTA in Event Viewer, ensure that Category is set to All. Event logs can be viewed locally or remotely, and they can be saved to *.EVT files. Diagnostics logging categories for the Exchange MTA Category X.400 Service Description Reports events related to X.400 protocol handling, such as delivery of messages to a remote MTA. Reports events related to the use of MTA resources. Reports events related to MTA security and security violations. Reports events related to communication between the MTA and the Exchange store and communication between MTAs using RPCs. 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. 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. Reports events related to problems with MTA configuration settings. Corrupt run files in the \Mtadata directory or invalid registry parameters can cause these events. Reports events related to Active Directory communication.

Resource Security Interface

Field Engineering

MTA Administration

Configuration

Directory Access

338

Category Operating System

Description Reports events related to operating system services that the MTA uses to create and manage files and threads. Reports events related to the internal processing in the Exchange MTA, which can be useful to a Microsoft Product Support Services support specialist. 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.

Internal Processing

Interoperability

339

Category APDU (Application Protocol Data Unit)

Description This category does not cause the MTA to write information to the Application Event Log. Instead, it tracks the message envelope content (the P1) for messages the MTA sends and receives, as well as the fully-encoded application protocol data units (APDUs) that are transmitted between the MTAs. Use this category in conjunction with the X.400 Service category to log information to BF*.log files in the \Program Files\Exchsrvr\Mtadata directory. BF*.log files are useful when diagnosing interoperability or conformance problems, for example, when messages from remote MTAs are bad or formatted incorrectly. An ASN.1 Parser tool, such as the Aspirin tool (included in Exchange 2000 Server Resource Kit, available in bookstores), can be used to decode the data in a Bf*.log. Increasing diagnostic logging levels to Medium or higher for both the APDU and X.400 Service categories generates BF*.log files. The current log is always named Bf0.log. Prior logs are named BF#.log, with the # increasing with the age of the log. When a log reaches 5 megabytes in size, it is renamed and a new BF*.log is created. Note: BF*.log files can grow very quickly and have a performance impact on the Exchange MTA.

Text Event Logging

To log all MTA event information to EV*.log files in the \Exchsrvr\Mtadata directory, set the following registry parameter. The EV*.log files are a non-localized text copy of the same MSExchangeMTA events that are logged to the Application Event Log. The categories and

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 Value Type Value Data Description

HKEY_LOCAL_MACHINE\CurrentControlSet\Ser vices\MSExchangeMTA\Parameters TextEventLogging REG_DWORD 0x1

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

Before you perform the procedure in this topic, consider the following: If you need to wipe an MTA database, you should contact Microsoft Product Support Services for assistance to ensure that the steps are performed correctly. If you apply the steps incorrectly, you may lose e-mail messages that are present in the MTA message queues.

Procedure
Wipe the MTA database 1. Use the Services tool (Administrative Tools program group in the Start menu) to ensure that the Microsoft Exchange MTA Stacks service is stopped.

343

2. Copy the entire contents of the MTA database directory (by default, this is the \Program Files\Exchsrvr\Mtadata directory) to a different location. This is preferable to moving only the .dat files, because Microsoft Product Support Services might require the entire contents of the Mtadata directory to determine what caused the problem. Note: Do not delete the original .dat files until the messages have been recovered. 3. Verify that the copy process completes successfully, and then delete the .dat files from the MTA database directory. 4. Copy all files found in the \Setup\i386\Exchange\Bootenv directory on the Exchange Server 2003 product CD to the active MTA database directory. The Microsoft Exchange MTA Stacks service cannot start without the core .dat files. 5. Remove the read-only file attribute from the copied files. There should be no read-only files in the MTA database directory. 6. Restart the Microsoft Exchange MTA Stacks service. If the MTA had problems from corrupted messages in the .dat files, the MTA can now resume operation and message transfer.

For More Information

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.

How to Replay DAT Files After an MTA 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

Before you perform the procedure in this topic, consider the following:

345

When you prepare to perform the replay, be sure that the MTA on the Exchange server of origin has nothing in its queues. If there are no messages currently residing in the MTA queues, the MTA can be stopped. The current .dat files can be safely moved and eventually deleted, because there are no messages pending delivery. If there are messages in the MTA queues, the MTA should be allowed to finish sending the messages until all of the queues are empty. After all queues are empty, the MTA must be stopped immediately. After the MTA is stopped, move the current .dat files to a different location. Do not leave any earlier .dat files in the MTA database directory. Copy the .dat files that must be replayed to the MTA database directory.

Procedure
To perform a complete replay of .dat files after an MTA database wipe 1. Verify that all the MTA queues on the server running Exchange Server are empty. If the queues are not empty, allow the MTA to finish delivering any messages that are in the queues. Note: You can use the Performance Monitor tool (Perfmon.msc) to verify that no messages are in the MTA queues. For example, to check the work queue, select the MSExchangeMTA performance object, and then select the Work Queue Length performance counter, as illustrated in the following figure. Checking the number of messages in the MTA work queue

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 More Information

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.

347

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.

How to Replay DAT Files After an MTA 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

Before you perform the procedure in this topic, consider the following: 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. This topic contains information about editing the registry. 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.

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\ MSExchangeMTA\Parameters

Value Type Value Data Description

Dispatch remote MTA messages REG_DWORD 0x1

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 More Information

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

How to Replay DAT Files After an MTA 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

Before you perform the procedure in this topic, consider the following: 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. This topic contains information about editing the registry. 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.

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.

350

3. If no messages are residing in the MTA work queue, stop the Microsoft Exchange MTA Stacks service and copy the current .dat files to another location. Eventually, these .dat files can be deleted, because there are no messages pending transfer. 4. Delete all .dat files from the MTA database directory. 5. Copy all files that can be found on the Exchange 2003 product CD in the \Setup\i386\Exchange\Bootenv directory to the active MTA database directory. 6. Remove the read-only file attribute from the copied files. 7. Move a portion of the .dat files to be replayed to the MTA database directory. For example, if you must replay 30,000 .dat files, you might want to replay the messages in chunks of 5,000 or 10,000 .dat files. Note: Ensure that you move the files. If you copy the files instead, it becomes difficult to distinguish between files that you already replayed and files that you must replay. Replaying a message multiple times leads to multiple message deliveries. When the working copy of the .dat files is on the same directory as the MTA database directory, moving the files to the MTA database directory is simplified. 8. Run Mtacheck /V to check the MTA database. 9. Start the Microsoft Exchange MTA Stacks service and monitor the MTA work queue and event logs to ensure that all messages are processed successfully and that the MTA is functioning normally. 10. Repeat the steps until all of the .dat files are replayed. 11. If you are performing an incremental remote replay, do not forget to remove the Dispatch remote MTA messages registry key, or set it to 0x0 when you are finished.

For More Information

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 MTA

352

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 MDBEF Content Type 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 Public Folder MDBEF

Content Type 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.

Object Identifier 2A864886F7140502

P2

Defined in X.400 of the 1984 conformance year. Defines the format of an interpersonal message (IPM).

56010A00

P22

Defined in X.400 of the 1988 conformance year. Extends the format of an interpersonal message (IPM), as defined in X.400-84.

56010A01

P772

Military message.

2B1A00A236000401

Extends the P22 protocol with extensions defined for Defense Message System (DMS) in "Allied Communication Publication (ACP) 123." These extensions (additional properties) are allowed by the X.400 standard and are typically only exposed by DMS-capable clients, and STANAG 4406 v1.7 and v3 clients.

355

Format P42

Content Type 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."

Object Identifier 60864801650201022A

CSP

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."

608648016502010203

356

Format TNEF

Content Type 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 Exchange Server 2003. 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.

358

Data transfer The RTSE uses RT-TRANSFER APDUs for data transfer. The dialog may be one-way or two-way alternate, depending on whether data is transferred only from one MTA or in both directions by turns. Each association, over a two-way alternate link, has a turn token that only one MTA can possess at a time. When an MTA must send a message, but does not have the turn on an open association, it must determine how many open associations are on the link. If there are fewer than eight associations, the MTA attempts to open a new association on which it has the turn. If there are already eight associations open, the MTA sends an RT_TURN_PLEASE request over one of the associations. If the receiving MTA can release the turn, it sends back an RT_TURN_GIVE response and the requesting MTA is allowed to transfer the message. If the receiving MTA cannot release the turn, it simply does not respond until it is ready to release the turn. In a two-way alternate communication, the RTSE can use RT-TURN-PLEASE and RT-TURN-GIVE APDUs to switch data transfer directions, as follows: RT-TURN-PLEASE If an MTA has the turn and receives an RT-TURN-PLEASE request from the other MTA, the MTA issues a P-TOKEN-PLEASE request primitive, so that the requesting MTA can become the sending MTA. RT_TURN_PLEASE requests can have different priorities, which relate to the priority of the message. Priority 0 is reserved for when an MTA wants to shut down an association or when an MTA wants to send routing information. RT-TURN-GIVE If an MTA has the turn and receives an RT-TURN-GIVE request primitive from a requesting MTA, it issues a P-CONTROL-GIVE request primitive and becomes the receiving MTA. Association termination The RTSE uses RT-CLOSE, RT-U-ABORT, and RT-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.

359

Caution: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Location

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

RTS threads REG_DWORD 0x1

Determines the number of RTS threads. The default value is 0x1. The recommended value is 0x3 if this MTA communicates with 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.

360

Association termination Association termination is provided by three services: A-RELEASE This is the normal release mechanism used to end an association. A-ABORT This is an unconfirmed (abrupt) cancellation of an association.

A-P-ABORT This is an unconfirmed (abrupt) cancellation of an association similar to A-ABORT. The difference is that A-P-ABORT indicates to the remote MTA that the association has been broken by service providers at lower OSI layers. Each connection between two MTAs can have up to ten associations, and because each association is effectively a conversation, up to ten messages can be sent simultaneously over a single X.400 connector. Two of the ten associations are reserved for sending urgent messages. Each MTA holds the turn on one of the two associations and never releases the turn. If a remote MTA attempts to establish more than eight concurrent associations for messages with normal priority, the Exchange MTA refuses the additional associations and logs an event with the event ID 58 in the application event log. The following is an example of this event:
Event Type: Event Source: Warning MSExchangeMTA

Event Category: X.400 Service Event ID: Date: Time: User: Computer: 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) 58 04/01/2004 4:27:34 AM N/A SERVER01

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

361

APDUs from the higher level to presentation protocol data units (PPDUs), and the service provider at the session layer adds further information to the data packets to create valid session protocol data units (SPDUs). The first information sent over the presentation layer is a P-ACTIVITY-START indication. If the message is large, the MTA might have to send more than one P-DATA packet. P-DATA packets are not confirmed by the receiving MTA, so the sending MTA also sends P-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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data

Kernel threads REG_DWORD 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.

363

Note: X.400 MTAs that operate according to the 1984 conformance year support only TSAPs. SSAPs and PSAPs should not be specified. To support X.400 connectors, you must install one of the following two MTA transport stacks: TCP/IP Transport Stack TCP/IP is a good choice for X.400 message transfer over the Internet and over intranets. The TCP/IP transport stack implements ISO transport services on top of TCP/IP, as defined in Request for Comments (RFC) 1006. When you install and configure a TCP/IP transport stack, you create a configuration object in Active Directory that defines the service access points and other settings that the MTA uses. Transport stack objects are located in the configuration directory partition under the MTA directory object. You can use the following LDIFDE command to export all TCP/IP transport stacks configured on all servers in an Exchange organization to a file named Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First
Organization,CN=Microsoft 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. Important attributes of the TCP/IP transport stack object Attribute objectClass nAddressType Description Indicates the class of the directory object as rFC1006Stack. Indicates the type of information in the nAddress attribute. The address information can be a host name or an IP address. Specifies the host name or IP address of the local Exchange MTA. Specifies the TSAP in the stack's OSI address information. Specifies the SSAP in the stack's OSI address information. Specifies the PSAP in the stack's OSI address information. Lists the distinguished names of X.400 connectors that use this transport stack.

nAddress tSelector sSelector pSelector supportingStackBL

364

Attribute x400SelectorSyntax

Description Indicates the type of information in the tSelector, sSelector, and pSelector attributes. The OSI address information can be a hex value or a decimal value. Specifies the name of the transport stack object as displayed in Exchange System Manager.

name

X.25 Transport Stack You must install an EICON X.25 card on the server running Exchange Server 2003 and the EICON WAN drivers in Windows Server 2003 to support X.400 connectors over X.25. The X.25 configuration is very complex and can be completed only by using the configuration utilities that come with the EICON X.25 card. The X.121 address (comparable to a telephone number) is the most important information that must be configured. X.121 address data, call user data, and facilities data that you specify in the X.25 transport stack must match the EICON card configuration, as specified by your X.25 provider. You can use the following LDIFDE command to export all X.25 transport stack objects configured on all servers in an Exchange organization from Active Directory to a file called Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First
Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass= x25Stack)"

The following table describes the important attributes of the X.25 transport stack. Important attributes of the X.25 transport stack object Attribute objectClass nAddress x25CallUserDataIncoming x25FacilitiesDataIncoming x25LeasedLinePort tSelector Description Indicates the class of the directory object as x25Stack. Specifies the local X.121 address. Specifies the call user data for the X.25 adapter. Specifies the facilities user data for the X.25 adapter. Specifies the X.25 adapted port number. Specifies the TSAP in the stack's OSI address information.

365

Attribute sSelector pSelector supportingStackBL x400SelectorSyntax

Description Specifies the SSAP in the stack's OSI address information. Specifies the PSAP in the stack's OSI address information. Lists the distinguished names of X.400 connectors that use this transport stack. Indicates the type of information in the tSelector, sSelector, and pSelector attributes. The OSI address information can be a hex value or a decimal value. Specifies the name of the transport stack object as displayed in Exchange System Manager.

name

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value

Transport threads

367

Type Value Data Description

REG_DWORD 0x1

Determines the number of transport threads. The default value is 0x1. The recommended value is 0x3 if this MTA communicates with 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 C A Abbreviation Country ADMD Attribute Type Country ADMD name Example C=US; A=MCI;

371

Label P S G I Q CN X.121 N-ID T-TY T-ID O OU1 OU2 OU3 OU4 DDA

Abbreviation PRMD Surname Given Name Initials Generation Common Name X.121 N-ID T-TY T-ID Organization Org.Unit.1 Org.Unit.2 Org.Unit.3 Org.Unit.4 DDA

Attribute Type PRMD name Surname Given name Initials Generation qualifier Common name X.121 address UA numeric ID Terminal type Terminal identifier Organization

Example P=TAILSPINTOYS; S=BREMER; G=TED; I=TB; Q=SR; CN=TED BREMBER; X.121=49309872210 2 N-ID=208973240 T-TY=TTY; T-ID=309; O=EXCHANGE;

Organizational unit 1 OU1=IT; Organizational unit 2 OU2=USA; Organizational unit 3 OU3=SEA; Organizational unit 4 OU4=DOWNTOWN; Domain Defined Attribute (DDA:type=value attribute) DDA:SMTP=Ted@ta ilspintoys.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 connector with other address types, for example, by specifying SMTP address information, as

372

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:rfc822=Ted@tailspintoys.com. Exchange Server 2003 uses SMTP DDAs instead of RFC822 DDA and does not support MIXER.

373

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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Bodypart IA5 text Telex (ITA2 5-bit) Voice G3 facsimile Text interchange format (TIFO) Telex (T.61) Videotex Nationally defined Encrypted Forwarded IP message Simple Formatable Document (SFD) Text interchange format 1 (TIF1) Octet string ISO6937 text Bilaterally-defined (binary) Binary file transfer (first defined in 1988)

When connecting to a remote Exchange MTA in the same organization, you can select the Allow Exchange Contents check box. The native Exchange format is not X.400 conforming, but between Exchange MTAs this is not an issue. However, you must clear this check box when communicating with an Exchange MTA that is external to the local Exchange organization, because native Exchange content includes legacyExchangeDN address information, which is only valid in the local organization. The recipients specified through legacyExchangeDN addresses do not exist in the directory of the external Exchange MTA. To send messages in Exchange format to Exchange users in external organizations, from the General tab of the connector, select the Remote Client Supports MAPI check box. When you select this check box, the Exchange MTA encapsulates the messages using Transport

375

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 when the MTA receives a message from an MTA in another organization. If an MTA

376

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 Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=x400Link)"

378

The following table describes the important attributes of X.400 connector objects. Important attributes of X.400 connector objects Attribute activationSchedule activationStyle Description Specifies the activation schedule for this X.400 connector. Specifies the activation style for this X.400 connector. (0=Never schedule, 1=Use schedule) Specifies the ADMD portion of a manually defined global domain identifier. 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. Specifies the country portion of a manually defined global domain identifier. Specifies the deliverable message types in encoded format according to the content restrictions configured for this connector. Specifies the object IDs for content types supported by this connector. Specifies the name of the remote X.400 MTA that the local MTA uses when establishing a connection. Specifies the distinguished name of the MTA that uses this X.400 connector. Specifies the number of characters in the message text after which the MTA inserts a line break. Specifies whether the local MTA or the remote MTA has the initial turn on new associations. Designates this connector object as an X.400 connector.

aDMD associationLifetime

c delivEITs

delivExtContTypes gatewayLocalDesig

homeMTA lineWrap

localInitialTurn

msExchConnectorType

379

Attribute msExchEncryptedPassword

Description 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. Specifies the override name for the local MTA. Specifies the host name or IP address of the local Exchange MTA. Indicates the information type in the nAddress attribute. The address information can be a host name or an IP address. Specifies the name of the transport stack object, as displayed in Exchange System Manager. Specifies the maximum number of times that the Exchange MTA tries to open a connection before it sends a non-delivery report (NDR).

mTALocalDesig nAddress nAddressType

name

numOfOpenRetries

380

Attribute numOfTransferRetries

Description Specifies the maximum number of times that the Exchange MTA tries to transfer a message across an open connection. Indicates the class of the directory object as x400Link. The following object classes are derived from this class: rFC1006X400Link TCP/IP X.400 connectors x25X400Link X.25 X.400 connectors

objectClass

openRetryInterval

Specifies the number of seconds that the system waits after an error, before attempting to reopen a connection. Specifies the PRMD portion of a manually defined global domain identifier. Specifies the PSAP in the stack's OSI address information. Specifies the address spaces configured for this X.400 connector. 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. 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. 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.

pRMD pSelector routingList rTSCheckpointSize

rTSRecoveryTimeout

rTSWindowSize

381

Attribute sessionDisconnectTimer

Description Specifies the amount of time in seconds that the Exchange MTA waits before disconnecting a connection after all associations over this connection are cancelled. Specifies the SSAP in the stack's OSI address information. Specifies the object identifiers of application contexts that an OSI application, such as the Exchange MTA, supports. Specifies the distinguished name of the MTA transport stack that the MTA uses to communicate over this connector. 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. Specifies the number of seconds that the system waits after a message transfer fails before re-sending a message across an open connection. Specifies the amount of time in seconds per kilobyte that the system waits before sending an a non-delivery report (NDR) for a non-urgent message. Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for a normal message. Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for an urgent message. Specifies the translation table that the MTA uses to encode the message text.

sSelector supportedApplicationContext

supportingStack

tempAssocThreshold

transferRetryInterval

transferTimeoutNonUrgent

transferTimeoutNormal

transferTimeoutUrgent

translationTableUsed

382

Attribute transportExpeditedData

Description 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. Specifies the TSAP in the stack's OSI address information. Specifies whether the MTA association is one-way or two-way alternate. Specifies the syntax of the P, S, and T selectors. (0 or undefined=Hex, 1=Text)

tSelector twoWayAlternateFacility x400SelectorSyntax

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 Source: MSExchangeMTA 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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Values

TCP/IP control blocks TP4 control blocks Eicon X.25 connections

Type Value Data Description

REG_DWORD 0x14 (20)

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

TCP/IP threads REG_DWORD 0x2

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 Source: MSExchangeMTA 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 Source: MSExchangeMTA 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 MTSIN 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 objectClass Common name Description Identifies the directory object as a mailGateway and msExchConnector object. Represents the name of the connector object in Active Directory, relative to its parent container. 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. Identifies the delivery mechanism that is used by Exchange Server 2003 to pass messages to the XAPI gateway. Represents the distinguished name of the connector object in Active Directory. Identifies the private mailbox store that holds the connector mailbox. Identifies the Exchange MTA that is responsible for message routing to the XAPI gateway. Represents the distinguished name of the connector object in the earlier Exchange Server 5.5 directory format. This attribute must be set on the connector object for the Queue Viewer snap-in to work. Lists the object IDs for content types supported by this connector. Represents the name of the connector object.

computerName

deliveryMechanism

distinguishedName homeMDB homeMTA

legacyExchangeDN

delivExtContTypes Name

388

Attribute canPreserveDNs

Description Indicates whether the connector object can handle distinguished names in recipient information.

Exchange MTA Message Transfer

The following figure illustrates how the SMTP service and the Exchange MTA interact with each other.

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data Description

Min RPC Threads REG_DWORD 0x4

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

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

Value Type Value Data

Max RPC Calls Outstanding REG_DWORD 0x32

394

Location

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\ MSExchangeMTA\Parameters

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 Source: MSExchangeMTA 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 Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=siteAddressing)".

The following table describes the important attributes of the GWART directory object. Important attributes of GWART object Attribute objectClass Description Identifies the directory object as a GWART object, based on the siteAddressing object class. Contains the routing table in the format required by Exchange Server 5.5 MTAs. Specifies the date and time when the GWART object was last updated. Points to the server that maintains the GWART for this administrative group.

gatewayRoutingTree gWARTLastModified ridServer

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. This section discusses the following concepts:

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

399

transport subsystem. For detailed information about Exchange Server 2003 message handling, see Message Routing Architecture. On the non-Exchange side of a message transfer, message delivery and retrieval depend on the features and programming interfaces that the non-Exchange messaging system provides. Typically, only a single point of contact is used on this side of a message transfer also. For example, Connector for Lotus Notes connects to only one Lotus Domino server. It is up to the non-Exchange messaging system server to route messages to their final destinations. The following figure illustrates the typical steps that a MAPI-based connector must perform to accomplish outbound and inbound message transfer. Message transfer through a MAPI-based connector

Message transfer to and from a non-Exchange messaging system includes the following steps: a. Message transfer begins with obtaining messages from the source system. MAPI-based connectors use MAPI to retrieve messages from Exchange. On the 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

400

useful, because it provides all users with access to complete address lists that include the recipients in the Exchange and non-Exchange messaging environments. In Exchange Server 2003, directory information resides in the Microsoft Active Directory directory service, and directory synchronization is performed using Lightweight Directory Access Protocol (LDAP) and Active Directory Service Interfaces (ADSI). Performing support functions Message transfer and directory synchronization are the most important tasks that a MAPI-based connector must perform. In addition, support functions should be implemented to increase the level of integration with Exchange Server 2003. Support functions include the following: Performance monitoring MAPI-based connectors provide performance counters so that an administrator can create performance monitoring reports using the Performance tool, available from Administrative Tools in the Start menu. Event logging MAPI-based connectors track significant events (such as connector service starts, stops, converts message, transfers message) according to various diagnostics levels in the application event log. The administrator can use the Event Viewer tool, available from Administrative Tools, to determine if the connector is operating correctly. The application event log is an essential information source when you troubleshoot message transfer issues. Error handling MAPI-based connectors inform message senders about transfer issues using delivery status notifications. For example, a connector sends a 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.

401

MAPI-based connectors consist of the following components: Connector service Typically, MAPI-based connectors are implemented as Microsoft Windows services that are running directly on the Exchange Server 2003 bridgehead server. Therefore, they start automatically when the server starts and run in their own security context. In Exchange Server 2003, all services, including the services of MAPI-based connectors, use the LocalSystem account, as discussed in Exchange Server 2003 Services Dependencies. Note: Connector components can run directly on a server running Exchange Server 2003 or on a separate computer that communicates with Exchange Server 2003 over the network. The non-Exchange messaging system is usually accessed over the computer network, although it might improve connector performance if the non-Exchange messaging system is local to the connector server. For example, it is possible to run both Exchange Server 2003 and Lotus Domino on the same server. Conversion DLLs MAPI-based connectors can register conversion DLLs with the Exchange Server 2003 framework for message translation, so that the appropriate translation code is called when the connector converts inbound or outbound messages. These DLLs must be registered in the registry, under the HKEY_LOCAL_MACHINE\Software\Classes\MAPI Conversions key. A subkey must then exist for each conversion DLL. The DLL subkey name must be the name of the DLL file. These DLLs must be installed in the \System32 directory of the bridgehead server. Each DLL key contains a subkey for each entry point in a conversion DLL, which the conversion engine uses to perform the conversion. Note: Conversion DLLs are optional components. The code to perform message conversions can also be embedded directly in a MAPI-based connector, in which case conversion DLLs are not used. For example, Connector for Lotus Notes and Connector for Novell GroupWise do not rely on conversion DLLs. The mechanisms that these connectors rely on to perform message conversions are covered in later sections. 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 email 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

402

the message, the connector performs address translation and replaces the Lotus Notes (proxy) address of the Exchange user with the actual Exchange address (the X.500 address of the user, as specified in the legacyExchangeDN attribute). Similarly, Connector for Lotus Notes replaces Ted's Exchange address information with his Lotus Notes proxy address information in all outbound messages to Lotus Notes. The native Exchange Server 2003 address format is SMTP. Note: Exchange users typically appear in non-Exchange messaging systems as regular recipients who exist in the non-Exchange messaging systems. To enable recipient update service to generate proxy addresses in the correct format, MAPI-based connectors must install an appropriate proxy address generation DLL on the server running Exchange Server 2003. Proxy address DLLs reside in subdirectories that correspond to address types and computer processor types, under \Program Files\Exchsrvr\Address. This subdirectory is shared for network access (share name: \\<server name>\Address), so that the recipient update service can access the DLLs, even if the messaging connector is installed on another server running Exchange Server. You can read more about the recipient update service in Exchange Server 2003 and Active Directory. The following figure illustrates an example of proxy addresses that the recipient update service assigned to an Exchange user.

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 Common-Name Description The common name of the Address-Type that is used to build the distinguished name of the object in Active Directory. The version number of the proxy address generator DLL file. 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. The name of the address type, such as NOTES:i386.

File-Version proxyGeneratorDLL

name

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 Routing Architecture. Connector objects reside in the Connectors container under their routing groups in Exchange System Manager. A corresponding administrative snap-in is required to configure the settings of the msExchConnector object. Settings include connector 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. Important general attributes of msExchConnector objects Attributes Common name Description Represents the name of the connector object in Active Directory relative to its parent container. 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. Identifies the delivery mechanism that is used by Exchange Server 2003 to pass messages to the MAPI-based connector. Represents the distinguished name of the connector object in Active Directory.

computerName

deliveryMechanism

distinguishedName

406

Attributes homeMDB homeMTA

Description Identifies the private store that holds the connector mailbox. Identifies the Exchange MTA that is responsible for message routing to the MAPI-based connector. Represents the distinguished name of the connector object in the earlier Exchange Server 5.5 directory format. This attribute must be set on the connector object for the Queue Viewer snap-in to work. 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. Represents the name of the connector object. Exchange System Manager uses this name as the display name of the connector object.

legacyExchangeDN

msExchConnectorType

name

407

Attributes objectClass

Description 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 sub-class of msExchConnector.

routingList

Identifies the address spaces associated with this connector. Each connector has at least one associated address space. The routing engine uses this information to determine possible connectors for a particular message by comparing the recipient addresses with available address space information.

Administrative snap-in MAPI-based connectors should add and register an MMC extension snap-in to Exchange System Manager, so that Exchange administrators can configure the connector's msExchConnector object in Active Directory (and possibly registry settings) using a friendly user interface. For example, Connector for Lotus Notes comes with an Exchange Notes Connector snap-in and Connector for Novell GroupWise comes with an Exchange GroupWise Connector snap-in. Both snap-ins are implemented in Exadmin.dll, as explained in Exchange System Manager Architecture.

408

Connector mailbox When an msExchConnector object is created in Active Directory for a MAPI-based connector, Exchange Server 2003 creates a special mailbox for the connector in the mailbox store that is specified in the msExchConnector object's homeMDB attribute. The Exchange store creates this special mailbox on the bridgehead server when the connector service is started for the very first time or when the first message is routed to the connector. This mailbox includes the inbound and outbound message queues of the MAPI-based connector, named MTS-IN and MTS-OUT, and possibly other folders, named Badmail, ReadyIn, and ReadyOut, Deferred Action, Spooler Queue, and Temp, that the connector might use during message processing. For example, Connector for Lotus Notes and Connector for Novell GroupWise place corrupted messages in the Badmail folder. Whether additional folders beyond MTS-IN and MTS-OUT are used depends on the actual connector implementation. Note: At a minimum, a connector mailbox must have an MTS-IN and an MTS-OUT folder.

Message Transfer to and from Exchange Server 2003

Whereas the processes that communicate with the non-Exchange messaging system are specific to the individual connector type, all EDK connectors use MAPI to access their connector mailboxes in the Exchange store. As illustrated in the following figure, the Exchange message transfer agent (MTA) places messages addressed to the non-Exchange messaging system in the MTS-OUT folder, and the MAPI-based connector places inbound messages that it has retrieved and converted from the non-Exchange messaging system in the MTS-IN folder. The Exchange MTA is discussed in detail in X.400 Transport Architecture. Note: Because the connector message queues are always available, MAPI-based connectors are always marked as STATE_UP in the link state table and the Exchange MTA continues to deliver messages to a MAPI-based connector even if the connector service is not running. This can cause numerous messages to collect in the MTS-OUT message queue.

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 Per-message properties Description Many of these properties are native MAPI properties that define the date and time that the message arrived at the connector, the entry ID of the message, subject ID, originator information, and trace information. Trace information indicates the message path. Each time the Exchange MTA routes a message, it adds the country/region code, the administrative management domain (ADMD), and the private management domain (PRMD) of the local domain to the message. The MTA also adds time stamps and an action flag that indicates whether the message was expanded, redirected, relayed, or rerouted. Trace information is critical for preventing message transfer loops. Per-recipient properties For each recipient in the MTE recipient table, these properties indicate the recipient type, whether a delivery status notification is requested for the recipient, whether the message sender requests the MTA to attach a physical forwarding address for a recipient, whether the message sender requests proof of delivery for a recipient, and diagnostic codes that can be used as part of a non-delivery report (NDR). These MAPI properties identify the type of attached object and specify how the contents of the attachment can be accessed.

Attachment properties

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

415

address in the message envelope of the outbound message. For inbound messages, the translation is performed in the opposite direction. If address information for a non-Exchange sender or recipient does not exist in Active Directory, the MAPI-based connector must create one-off addresses for these users. The term "one-off" indicates that something is used only once and not retained permanently. One-off addresses are used in one message only and are not retained for reuse in other messages. The one-off address format is defined by MAPI as follows: Display name[Address type:E-mail address], such as Ted Bremer[NOTES:Ted@Exchange]. One-off addresses can also be used to encapsulate non-Exchange addresses. For example, if a user sends a message to a Lotus Notes user and a user on the Internet, the user on the Internet might not have a recipient object in Active Directory with a NOTES proxy address, in which case Connector for Lotus Notes cannot map the Internet user directly and must encapsulate the SMTP address in a one-off NOTES address to ensure that all recipients specified in the outbound Lotus Notes message appear in the non-Exchange system in a supported format.

Address Mapping Issues

If a MAPI-based connector cannot map the sender address or a recipient address, it must perform the following tasks: Sender address If the MAPI-based connector cannot convert the Exchange address of a sender into non-Exchange format, the connector must generate an NDR. The connector must mark as undeliverable each recipient of the message that the connector is required to handle. This occurs because the connector cannot generate a return address for replies to the message. The NDR is returned to the message sender to signal that no recipient was reached. Recipient address in target system If the MAPI-based connector cannot determine the address of a recipient that the connector is required to handle, the connector must generate an NDR for this recipient to inform the message sender that the message did not reach all intended recipients. Recipient address not in target system If the MAPI-based connector cannot determine the address of a recipient that the connector is not required to handle (for example, a recipient in a messaging system that is not connected by this connector), the connector does not generate an NDR. The connector must preserve as much address information as possible, by using address encapsulation. The connector can also drop the recipient from the message, or place the recipient information in a purely textual field.

416

Message Conversion
Exchange Server 2003 uses message classes to define which properties a message contains, the type of information the message conveys, and how the message can be handled. Each message class has an associated set of properties, and because different MAPI message classes support different sets of properties, multiple algorithms must be used to convert a MAPI message to the message format of the non-Exchange messaging system. Similarly, if the message format of the non-Exchange messaging system supports its own message classes, separate translation algorithms are necessary to handle these message classes. To handle a message class, the connector converts outgoing messages to an appropriate format (when the non-Exchange messaging system has an analogous message class) and converts incoming messages to an appropriate MAPI message class. The connector also generates the various REPORT message classes when an incoming or outgoing message requires them. In addition to handling a message class, the connector also converts message attachments. The following table lists the message classes that MAPI-based connectors must handle. Message classes that MAPI-based connectors must handle Message Class ENVELOPE.{Message Class} Description 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.

417

Message Class REPORT.{Message Class}.NDR

Description 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. The delivery report. Delivery reports are optional reports that provide various amounts of information about the delivery of the original message, depending on the non-Exchange messaging system. If the non-Exchange messaging system does not support delivery reports, the MAPI-based connector can generate a delivery report when it successfully transfers a message to the non-Exchange messaging system. This type of report indicates to the sender only that the non-Exchange messaging system accepted the message. 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}.DR

REPORT.{Message Class}.IPNRN

418

Message Class REPORT.{Message Class}.IPNNRN

Description The interpersonal note non-receipt notification. Non-read receipts are similar to read receipts, only they inform a sender that a recipient deleted a message without opening it. Non-read receipts are generated by the messaging client of the recipient. Not all non-Exchange messaging systems support non-read receipts.

Directory Synchronization
MAPI-based connectors, such as Connector for Lotus Notes and Connector for Novell GroupWise, support directory synchronization, which establishes a consistent global address list across all messaging systems. MAPI-based connectors must also ensure that directory information stays current in both directories. For example, if you change or delete a user in the non-Exchange messaging system, the corresponding recipient object must also be changed or deleted in Active Directory. Therefore, the MAPI-based connector uses MAPI to interact with the Exchange store, but it uses ADSI to interact with Active Directory. Directory synchronization is made up of two separate, sequential processes: 1. Synchronizing recipients from a non-Exchange messaging system to Active Directory. 2. Synchronizing recipients from Active Directory to a non-Exchange messaging system.

Directory Synchronization from a 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 MAPI-based connectors use the programming interfaces that the nonExchange messaging system provides to extract the directory information from the nonExchange 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.

419

2. Preparing the directory information for an import to Active Directory MAPIbased 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 nonExchange users are not yet in the Active Directory environment, but will be in the environment after migration to Exchange Server 2003. Enabled mail-enabled user accounts This is a good choice for non-Exchange users who work in your Active Directory environment, even though they do not have an Exchange mailbox. Mail-enabled contacts This is a good choice for non-Exchange users who are not, and never will be, in the Active Directory environment. Internet users in external messaging systems are an example. A MAPI-based connector can synchronize distribution lists as contact objects. This is an advantage because the connector does not need to maintain distribution list membership information in Active Directory. However, messages sent to a distribution list must then first be transferred to the legacy messaging system for distribution list expansion, before the messages can be delivered to the individual recipients. If the distribution list contains recipients that refer back to users in the Exchange Server 2003 organization, messages must travel back to the Exchange Server 2003 organization after the distribution list expansion. To avoid this unnecessary message transfer, you might choose not to synchronize distribution lists. If the number of distribution lists is manageable, you can create mail-enabled groups in Active Directory and specify the individual members directly. In this case, Exchange Server 2003 can perform the distribution list expansion immediately and without the overhead of additional message transfer to the legacy messaging system. Groups in Active Directory can contain any type of recipient objects, such as user accounts, contacts, or other groups. 3. Importing the directory information to Active Directory MAPI-based connectors use ADSI to create mail-enabled user accounts or mail-enabled contacts. Both Connector for Lotus Notes and Connector for Novell GroupWise import recipient information to a single target organizational unit in Active Directory. The target organizational unit, where the MAPI-based connector places the recipient objects that are created during directory synchronization for non-Exchange users, is also named the import container. There can be only one import container. Note: The computer account of the Exchange Server 2003 bridgehead server running the MAPI-based connector requires permissions to create and modify recipients in the selected import container. The following figure illustrates the general process for transferring directory information from a non-Exchange messaging system to an Exchange organization.

420 Directory synchronization from a non-Exchange messaging system to Active Directory

Directory Synchronization from an Exchange Organization to a Non-Exchange Messaging System

Directory synchronization from an Exchange organization to a non-Exchange messaging system follows the same principle as directory synchronization from a non-Exchange messaging system to an Exchange organization. The MAPI-based connector must extract information about mailbox-enabled user accounts from one or multiple organizational units (also named export containers) in Active Directory by using ADSI, process the information, and then import, update, or delete the information in the non-Exchange directory. For Active Directory to non-Exchange directory synchronization to work, the non-Exchange messaging system must contain directory information for users who are outside the local messaging system. Most messaging systems support this functionality. For example, Exchange users appear in Lotus Notes as users in a Lotus Notes foreign domain. In addition to exporting mailbox-enabled user accounts from Active Directory, MAPI-based connectors also support exporting contacts and groups, which then appear as regular Exchange recipients in the non-Exchange directory.

421

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. Directory synchronization from Active Directory to a non-Exchange messaging system

422

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

Before you perform the procedure in this topic, consider the following: Mdbvu32.exe is available for download from the Downloads for Exchange Server 2003 Web site. This topic contains information about editing the registry. 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.

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-15-18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles. 3. Right-click the key that represents the connector's MAPI profile and select Export. For example, export the SERVER01-LME-GWISE V5.5 key if you want to examine the message queues of Connector for Novell GroupWise. 4. Export the key to a .reg file, and then close the registry editor. 5. Open the exported .reg file in Notepad and replace all occurrences of HKEY_USERS\S-1-5-18 with HKEY_CURRENT_USER. 6. Save the changes and close Notepad. 7. Double-click the .reg file and in the dialog box that informs you that you are about to import settings into the registry, click Yes. In the dialog box that informs you that

423

this step is complete, click OK. 8. Ensure that the administrator account with which you are working is not a member of the Enterprise Admins or Domain Admins group. Temporarily, add your account to the Exchange Domain Servers group to gain access permissions for the connector mailbox. 9. Start Mdbvu32.exe and in the MAPILogonEx dialog box, click OK. 10. In the Choose Profile dialog box, select the MAPI profile of the connector, such as SERVER01-LME-GWISE V5.5, and then click OK. 11. From the MDB menu, select OpenMessageStore. In the Select Message Store To Open dialog box, verify that the MAPI-based connector is selected, and then click Open. 12. From the MDB menu, select Open Root Folder, and in the MAPI_FOLDER Root dialog box, double-click on the system folder that you want to examine, such as MTS-IN. 13. Close Mdbvu32.exe and remove your account from the Exchange Domain Servers group.

Connector for Lotus Notes Architecture

Connector for Lotus Notes can connect an Exchange organization to a Lotus Notes and Lotus Domino network. Lotus Notes releases 3 and 4 and Lotus Domino releases 4.5, 4.6, 5, and 6 are supported with Exchange Server 2003 Service Pack 1 (SP1). This MAPI-based connector uses the Lotus Notes Client API to communicate with a Lotus Notes or Lotus Domino server. This requires a Lotus Notes client on the connector server. A license from Lotus Development is required to use the client software. For information about how to install and configure Connector for Lotus Notes, see the Exchange Server 2003 Interoperability and Migration Guide. Note: Because Connector for Lotus Notes uses the Lotus Notes Client API to communicate with a Lotus Notes or Lotus Domino server, the connector requires a dedicated Notes ID that has permissions to access Lotus Notes databases. The following table lists the important components of Connector for Lotus Notes.

424 Connector for Lotus Notes components Component Connector mailbox Description 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).

425

Component Connector service

Description 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

426

Component Lotus Notes databases

Description 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

427

Component Connector store

Description Connector for Lotus Notes uses a folder structure on the file system to maintain control files used during directory synchronization. Control files are schema definition files and mapping rule files, which determine how attributes in one directory are mapped to the other directory. The connector store is located in the \Program Files\Exchrvr\Conndata directory. You can edit the following schema definition files and mapping rule files in Notepad to determine how attributes in one directory are mapped to the other directory: AMAP.TBLin the \Dxamex subdirectory Defines the Exchange mailbox attributes to be synchronized. AMAP.TBLin the \Dxanotes subdirectory Defines the Lotus Notes attributes to be synchronized. MAPMEX.TBLin the \Dxanotes subdirectory Determines the attribute mapping from Exchange Server 2003 to Lotus Notes. MAPNOTES.TBLin the \Dxamex subdirectory Determines the attribute mapping from Lotus Notes to Exchange Server 2003. For detailed information about customizing the directory synchronization between Lotus Domino and Exchange Server 2003, see Microsoft Knowledge Base article 180517, "XFOR: Customizing Directory Synchronization Between Exchange and Notes."

428

Component Registry settings

Description In the Registry, settings for Connector for Lotus Notes are stored in the following location: HKEY_LOCAL_MACHINE\SYSTEM\Curren tControlSet\Services\LME-NOTES. 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. The common name of the addrType object of Connector for Lotus Notes in Active Directory is NOTES:i386.

Proxy address generation DLL

addrType object

429

Component msExchConnector object

Description 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 Specifi es 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 directory synchronization. msExchPartnerLanguage Specifi es the language (code page) of the connected Lotus Notes and Domino server. msExchDirsyncSchedule Specifi es the times at which directory synchronization is performed automatically. msExchDirsyncStyle Specifies whether full or incremental directory synchronization is performed. msExchNotesNotesServer Speci fies the name of the Lotus Notes and Domino server (in Notes format) that the connector uses as the non-

430

Component Administrative snap-in

Description 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.

431

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 Exchange Server 2003. 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

432

conversion from one format to another might cause some changes in message characteristics. For example, certain features of a Lotus Domino message, such as the expiration date, are lost when the message is converted to the Exchange format. Messages that cannot be mapped to a corresponding message type in the target domain are converted to e-mail messages. Note: Connector for Lotus Notes is not designed to convert HTML-formatted messages. If you plan to route messages in HTML format between Exchange Server 2003 and Lotus Notes (for example, because you want to route all messages to and from Internet recipients through Exchange Server 2003), consider deploying an SMTP connector instead of Connector for Lotus Notes. The following table illustrates how different message types are converted between Exchange Server 2003 and Lotus Domino. Message conversion between Lotus Domino and Exchange Server 2003 Exchange Server 2003 feature E-mail messages E-mail delivered receipt E-mail read receipt Non-delivery report Importance Voting buttons Embedded OLE object Embedded file attachment Lotus Domino feature E-mail messages E-mail delivered receipt E-mail read receipt Non-delivery report Importance No feature Embedded OLE object Embedded file attachment Lotus Domino to Exchange Server 2003 Yes Yes Yes Yes Yes No Yes Yes Exchange Server 2003 to Lotus Domino Yes Yes Yes Yes Yes No Yes Yes No No Yes No Yes

Message expiry date Message expiry date No No feature Web URL No feature Meeting requests Reply By Web URL URL hotspot Appointments No Yes No Yes

433

Exchange Server 2003 feature Meeting accepted Meeting declined Meeting tentatively accepted Meeting request read Meeting request delivery Meeting updates

Lotus Domino feature Meeting accepted Meeting declined Meeting accepted Meeting request read Meeting request delivery Meeting updates

Lotus Domino to Exchange Server 2003 Yes Yes Appears as accepted Yes Yes Appear as new meeting requests containing the word "Updated" in the subject line Yes Task requests appear as e-mail messages or tasks No

Exchange Server 2003 to Lotus Domino Yes Yes Appears as accepted Yes Yes Appear as new meeting requests containing the word "Updated" in the subject line Yes Task requests appear as e-mail messages Appear as meetings with midnight as the start and end time No Default to e-mail messages

Meeting cancellation Task requests

Meeting cancellation Tasks

All day meeting requests No feature Other messages

No feature

Phone messages Other messages

Appear as 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.

434

Connector for Lotus Notes handles meeting requests and phone messages as follows: Meeting Requests and Appointments Connector for Lotus Notes synchronizes Exchange meeting requests and Lotus Domino appointments. Updated meeting requests are identified as Updated in their subject lines. Because of a limitation of the Lotus Domino API, meeting requests that Exchange Server 2003 users send to Lotus Domino users are not automatically updated in Lotus Domino. The user must manually update them. All Day Meeting Requests All-day meeting requests generated in Exchange Server 2003 appear with a start and end time of midnight. Phone Messages Lotus Notes phone messages appear as e-mail messages in Exchange Server 2003.

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 Size Color Bold Underline Italic Strikethrough Tables Microsoft Outlook Converts correctly. Converts correctly. Converts correctly. Converts correctly. Converts correctly. Converts correctly. 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. Convert correctly and can be edited. Ignored. Ignored.

Embedded OLE objects, including graphics Double strikethrough Superscript

435

Lotus Notes Subscript Shadow Outline Emboss Engrave Small caps All caps Drop caps Hidden Underline other than single Bitmaps not embedded as OLE objects Bullets

Microsoft Outlook Ignored. Ignored. Converts to italic. Ignored. Ignored. Ignored. Ignored. Ignored. Ignored; text is visible. Ignored. Not migrated; formatting is lost. Ignored.

Directory Synchronization
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>).

436 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

437

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

438

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 Connector mailbox Description 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).

439

Component Connector service

Description 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" -vLMEGWISE 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

440

Component Exchange Router for Novell GroupWise service

Description 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.

441

Component Connector store

Description The connector store, located in the \Program Files\Exchrvr\Conndata directory, acts as the communication media between Connector for Novell GroupWise and Router for Novell GroupWise. Connector for Novell GroupWise uses the following connector store subdirectories: \GwrouterThis directory has further subdirectories polled by Router for Novell GroupWise. The subdirectories are temporary repositories for message header files with an .api name extension, and message body and attachment files with a .bdy name extension that Router for Novell GroupWise transfers to and from Novell GroupWise API Gateway. Header and body files are keyword-based text files that Novell GroupWise API Gateway can convert to messages in Novell GroupWise format. The \Gwrouter directory has the following subdirectories: \Archive This directory only exists when archiving is enabled for Connector for Novell GroupWise. To enable archiving, you must configure the REG_DWORD registry parameter called Archive that you can find at the following location:
HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\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\G wrouter directory when you restart the Exchange Router for Novell

442

Component Novell GroupWise API Gateway

Description Connector for Novell GroupWise uses Novell GroupWise API Gateway to communicate with the Novell GroupWise environment. This is a universal GroupWise gateway that uses keyword-based text files to communicate with non-Novell GroupWise messaging systems, such as Exchange Server 2003. Novell GroupWise API Gateway maintains a folder structure with the following directories: \API_IN Receives incoming message header files from nonGroupWise systems \API_OUT Holds outgoing message header files to nonGroupWise systems \ATT_IN Receives incoming message bodies and attachments from non-GroupWise systems \ATT_OUT Holds outgoing message bodies and attachments to non-GroupWise systems \WPCSIN The GroupWise MTA inbound queue where incoming messages are placed after their processing through the API Gateway \WPCSOUT The GroupWise MTA outbound queue where outgoing messages are located before they are converted to keyword-based text files and placed in API_OUT and ATT_OUT through the API Gateway

Registry settings

In the Registry, Connector for Novell GroupWise settings are stored in the following location: HKEY_LOCAL_MACHINE\SYSTEM\Curre ntControlSet\Services\LME-GWISE.

443

Component Proxy address generation DLL

Description 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. The common name of the addrType object of Connector for Novell GroupWise in Active Directory is GWISE:i386.

addrType object

444

Component msExchConnector object

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 Specifi es whether mail-enabled contacts are propagated to Novell GroupWise through directory synchronization. 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 directory synchronization. msExchPartnerLanguage Specifi es the language (code page) of the connected Novell GroupWise post office. msExchDirsyncSchedule Specifi es the times at which directory synchronization is performed automatically. msExchDirsyncStyle Specifies whether full or incremental directory synchronization is performed. msExchGWiseAPIGatewayPath Specifies the path to the Novell GroupWise API Gateway directory.

445

Component Administrative snap-in

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 <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 Novell GroupWise.

446 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.

447

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 Exchange Server 2003. 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:

448

1. The Router for Novell GroupWise service obtains the message from the API_OUT and ATT_OUT directories of Novell GroupWise API Gateway in the form of header and body files and places them in the connector store. 2. The Gw2mex.exe process converts the header and body files to a message in Exchange Server 2003 format, before it places the message in the READYIN folder. 3. The Lsmexin.exe process obtains the converted message from the READYIN folder, verifies the validity of the recipient (converting the address to Exchange format, if necessary), and delivers the message to the MTS-IN folder. 4. The Exchange MTA then processes the message from the MTS-IN folder and places it in the SMTP service's MTS-OUT folder, from which it is then routed to its destination in the Exchange organization.

Message Conversion
Novell GroupWise supports several specific message types, such as e-mail messages, appointments, notes, tasks, forms, presentations, and documents. MAPI message types are mapped to corresponding message types in Novell GroupWise, when possible. In other words, e-mail messages appear as e-mail messages, meeting requests as appointments, and so on. Message types that are not supported in Exchange Server 2003, such as Novell GroupWise phone messages, are converted to regular e-mail messages. Connector for Novell GroupWise can track delivery confirmation reports, read receipts, and non-delivery reports. Message Conversion between Novell GroupWise and Exchange Server 2003 Exchange Server 2003 feature E-mail messages E-mail read receipt Non-delivery report Importance GroupWise feature GroupWise to Exchange Server 20 03 Yes Yes Yes Yes Exchange Server 20 03 to GroupWise Yes Yes Yes Yes (low priority does not have a representation in GroupWise) Yes Yes Yes

Messages E-mail read receipt Non-delivery report Importance

Sensitivity Meeting requests Meeting accepted

Sensitivity Appointments Meeting accepted

Yes Yes Yes

449

Exchange Server 2003 feature Meeting declined Meeting tentatively accepted Meeting request read Meeting request delivery Meeting updates

GroupWise feature

GroupWise to Exchange Server 20 03 Yes Appears as accepted Yes Yes Appear as new meeting requests containing the word "Updated" in the subject line No No Task requests appear as e-mail messages Yes

Exchange Server 20 03 to GroupWise Yes Appears as accepted Yes Yes Appear as new meeting requests containing the word "Updated" in the subject line No Yes Tasks appear as e-mail messages 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 Default to e-mail messages

Meeting declined Meeting accepted Meeting request read Meeting request delivery Meeting updates

Meeting reminder times Meeting cancellation Task requests

Meeting reminder times Meeting cancellation Tasks

All day meeting requests

Meeting requests

No Other messages

Phone messages Other messages

Appear as e-mail messages Default to e-mail messages

Note: Connector for Novell GroupWise does not support signed or encrypted messages.

450

E-mail Message Type Conversion

E-mail messages that originate in either Exchange or Novell GroupWise are converted to the format of the target system. Connector for Novell GroupWise also tracks message delivery by using delivery confirmation reports, read receipts, and non-delivery reports. Connector for Novell GroupWise handles meeting requests and phone messages as follows: Meeting Requests and Appointments Exchange meeting requests and Novell GroupWise appointments are transferred through Connector for Novell GroupWise. Updated meeting requests are identified as "Updated" in their subject lines. Because of a limitation of the GroupWise API Gateway, meeting requests sent from Exchange Server 2003 users to GroupWise users cannot be updated automatically in Novell GroupWise and must be updated manually by the user. Note: The API Gateway does not support recurring meeting requests from GroupWise that use the AutoDate feature. These recurring meeting requests are not transferred to Exchange Server 2003. Recurring meetings transferred from Exchange Server 2003 to Novell GroupWise are added to the Novell GroupWise calendar once, and recurring information is then displayed at the top of the message body. It is the user's responsibility to remember when the meetings take place or to enter multiple meeting occurrences individually in the calendar. All Day Meeting Requests All day meeting requests generated in Exchange Server 2003 appear as meeting requests in Novell GroupWise. However, if the meeting continues over multiple days, the connector creates a single instance on the first day with the date range in the message field. Phone Messages Novell GroupWise phone messages appear as e-mail messages in Exchange Server 2003.

E-mail Message Property Conversion

The connector discards rich text format (RTF) information in the message body of Exchange messages, because API Gateway supports plain text only. Objects embedded in messages sent by Exchange Server 2003 clients (Microsoft Office Outlook) are converted to attachments. These attachments, if embedded more than one level deep, appear as attachments to the primary message. If a Novell GroupWise user sends a message that includes an attached message that contains additional attachments, all attachments appear in Exchange Server 2003 as single attachments to the primary message.

451 E-mail message conversion between Novell GroupWise and Microsoft Outlook Novell GroupWise Size Color Bold Underline Italic Strikethrough Tables Microsoft Outlook Converts correctly. Ignored. Ignored. Ignored. Ignored. Converts correctly. Convert correctly if Microsoft Word is used as the primary e-mail editor in Outlook. Do not convert correctly in Outlook. Convert correctly and can be edited. Ignored. Ignored. Ignored. Ignored. Converts to italic. Ignored. Ignored. Ignored. Ignored. Ignored. Ignored, text is visible. Ignored. Not migrated, formatting is lost. Ignored.

Embedded OLE objects, including graphics Double strikethrough Superscript Subscript Shadow Outline Emboss Engrave Small caps All caps Drop caps Hidden Underline other than single Bitmaps not embedded as OLE objects Bullets

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.

452

Directory Synchronization
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

453

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.

454

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.

455

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 0 1 2 3 Meaning Free Tentative Busy 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).

456

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 common, but it can occur because of client errors, replication failures, and so on. If Outlook

457

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 subsubfolders, 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.

458

12. If the list of lowest-cost servers is exhausted, the count is reset to the size of the remaining servers in the list, and the process returns to Step 9. If the entire list is exhausted, an error is returned to the MAPI client. Note: These steps are identical, regardless of which folder the client wants (Offline Address Book, Free/Busy, or another folder) or for what reason it wants the content in that folder.

Free/Busy Publishing in Outlook Web Access and Outlook Mobile Access

Because they do not use MAPI, Outlook Web Access and Outlook Mobile Access cannot publish free/busy data directly to the public folder store. Instead, they rely on a free/busy publishing agent (MadFB) that runs in the System Attendant process (Mad.exe). MadFB has two functions: Publishing free/busy messages for Outlook Web Access and Outlook Mobile Access Deleting duplicate free/busy messages

As part of the transaction involved in the creation, deletion, or update of an appointment that affects the start or end time, a server-side call sends a free/busy update message to the System Attendant's mailbox. MadFB, which resides inside System Attendant, processes these messages and updates the free/busy data in the MAPI public folder. Depending on System Attendant's message polling interval, there can be up to a 15-minute delay before the updated free/busy data is published. MadFB's publishing process is identical to the Outlook publishing process described earlier. Therefore, if duplicate messages are present, they are appended by a number. Although Outlook Web Access and Outlook Mobile Access follow a process that is similar to the process that Outlook follows, the Outlook Web Access and Outlook Mobile Access processes are generally more reliable, because all the processing occurs between servers that are running Exchange Server.

Free/Busy Data Lookup

When locating free/busy data, Outlook operates differently than Outlook Web Access and Outlook Mobile Access, as described in the following bullets However, for all clients, this 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

459

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

460

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.

461

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.

462 Calendar Connector components

463

Component Connector service

Description 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 Connecto r 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 non-Exchange recipient that is found in Active Directory. The free/busy records are empty at first initialization. Note: It is best to schedule Calendar Connector to run after each directory synchronization cycle, so that Calsync.dll can create free/busy items for new recipient objects immediately. Use the Schedule tab in

464

Component Exchange Calendar Connector add-in

Description 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 running Exchange Server. In the Registry, settings for the Connector for Lotus Notes are stored in the following location: HKEY_LOCAL_MACHINE\SYSTEM\Curre ntControlSet\Services\MSExchangeCalC on.

Registry settings

465

Component msExchConnector object

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 S pecifies the time that Calendar Connector waits for the nonExchange messaging system to return a response for a free/busy request. If this time is exceeded, Calendar Connector returns the information that is currently available in the free/busy record to the Exchange user. When responses are late, Exchange Server 2003 returns the existing data to the Outlook client. When new data is finally received, Calendar Connector updates the free/busy record for the non-Exchange user. The updated information is not returned to the Outlook client, and the user does not receive an indication that free/busy information might not include the most recent updates or that more up-to-date information could be obtained with a subsequent query. msExchCalConRefreshInterval Specifies the time frame within which Calendar Connector considers the free/busy records for non-Exchange users to be most recent. Within the msExchCalConRefreshInterval,

466

Component Administrative snap-in

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 <Organization Name>/Administrative Groups/<Administrative Group Name>/Routing Groups/<Routing Group Name>/Connectors.

Free/Busy Lookups to and from Lotus Notes

The following figure illustrates how Calendar Connector integrates with a Lotus Notes messaging environment.

467 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.

468

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.

469

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.

470

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

471

under Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar in the Calendar Connector configuration, Mapical.dll returns this data immediately. 2. If a free/busy record does not exist for the Novell GroupWise user or exceeds the maximum time limit, Mapical.dll passes the free/busy query to Gwisecal.dll to update the target user's free/busy record in the Exchange free/busy folder. 3. Gwisecal.dll translates the request to a SEARCH-type keyword-based text file and puts it in the \Program Files\Exchsrvr\Conndata\GWRouter\Togwise directory. The message originator of this SEARCH-type message is System Attendant. The message is addressed to the Novell GroupWise user for whom Calendar Connector requests the free/busy information. The following is an example of a SEARCH-type request:
WPC-API= 1.2; MSG-TYPE= Search; Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51; From= WPD= CONTOSO_DOM; WPPO= Exchange Gateway; WPU= Microsoft System Attendant; CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; ; To= WPD= CONTOSO_DOM; WPPO= CONTOSO_PO; WPU= FrankM; CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; ; Begin-Time= 2/12/2003 21:28; End-Time= 31/1/2004 21:28; -END-

4. The Router for Novell GroupWise obtains the message from the \Togwise directory and puts it in the API_IN directory of Novell GroupWise API Gateway. 5. The API gateway processes the message according to the MSG-TYPE keyword and puts it in the WPCSIN directory for the Novell GroupWise MTA. 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).

472

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;

473

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

474

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

475

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. This section discusses the following concepts: 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.

476

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.

477

Examining the Interprocess Communication Between IIS and Microsoft Exchange Information Store Service
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.

478 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.

479 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.

480

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.

481

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.

482 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

specifies an RPC object universal unique identifier (UUID).

selects the protocol sequence specification for RPC over HTTP.

rpc_server is the network address of the computer that is running the RPC server process. The server address must be specified in a form visible and understandable by

483

RPC Proxy computer, rather than by the client. Because the client does not connect directly to the server, it does not resolve the name of the server or establish a connection to it. RPC Proxy establishes the connection on the client's behalf. Therefore, rpc_server must be a name recognizable by RPC Proxy.
endpoint

specifies the TCP/IP port that the RPC server process listens to for RPCs.

HttpProxy optionally specifies an HTTP proxy server on the RPC client's network, such as Microsoft Proxy Server. If a proxy server is selected, no port number is specified, the RPC stub uses port 80 by default if SSL is not requested, and port 443 if SSL is specified. RPCProxy specifies the address and port number of the IIS computer that acts as a proxy to the RPC server. You need to specify this only if the RPC server process resides on a different computer than RPC Proxy. If you do not specify a port number, by default the RPC client stub uses port 80 if SSL is not specified and port 443 if SSL (HTTPS) is specified.

RPC Virtual Directory

Although RPC over HTTP is a Windows Server 2003 feature and not an IIS feature, it is implemented as an Internet Server Application Programming Interface (ISAPI) extension that runs inside a protocol virtual server. The RPC virtual directory is created under Default Web Site when RPC Proxy service is installed. You should use SSL together with Basic Authentication.

RPC over HTTP and the Microsoft Exchange Information Store Service
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.

484

HTTP
The Microsoft Exchange Information Store service includes native HTTP access to data. Every object in the Microsoft Exchange Information Store service is URLaccessible with short, easily understood names. Because every object in the Microsoft Exchange information store is URLaccessible, 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.

485

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 HTTP User-Agent Field header Used to Determine the browser type, version, operating system, and how to render content Determine the language for the rendered content Determine if the content should display in a browser or if it should return without rendering to a WebDAV application Determine a specific action to perform

HTTP Accept-Language header HTTP Translate header

Query string

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.

486

WebDAV creates improved performance and user experience over the basic Microsoft Outlook Web Access client by exploiting client-side data binding and rendering. For example, when you click the column header, you can sort the Inbox in several different ways, enabling views based on the sender's name, the message subject line, or received date. The browser caches the user interface elements, such as Internet Explorer HTML components, Microsoft Jscript libraries, XSL, and Graphics Interchange Format (GIF) files. When the user changes the sort criteria, the browser can reformat the user interface elements locally and query the server for the view data. The following process shows how clients access items in their Inbox using WebDAV: The client issues an HTTP GET request for the client's Inbox.

IIS receives the request on port 80 (unless you change this configuration) and sends the request to Davex.dll for processing using ExIPC. The request is forwarded using ExIPC to the Exchange Store OLE DB driver, Exoledb.dll. Exoledb.dll renders the request in a format that the Exchange store can process, sends the request to the Exchange store, and then retrieves the client's Inbox properties from the Exchange store. After the clients Inbox properties are retrieved, Exchange 2003 routes the information back to the client using the same components that it used to process the client request.

POP3
Exchange Server 2003 implements a POP3 protocol stack that is compliant with RFC 1725, RFC 1734, and RFC 1939. Exchange 2003 supports the ten POP3 commands listed in the following table. POP3 protocol command verbs Command List Description 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.

487

Command Uidl

Description 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. 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. 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. 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. Used to deselect all messages that are selected for deletion.

Retr

Stat

Dele

Rset

488

Command Noop

Description 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. 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. 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. Used to quit the current POP3 session and delete any messages that are selected for deletion.

Top

Auth

Quit

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.

489 IIS and Exchange Server shared memory architecture

1. The client logs on to the server and gives the command to check e-mail. 2. A Request Mail Message 1 command is created on the IIS side. 3. IIS allocates shared memory from the shared memory heap for the request. A corresponding handle is assigned to part of the shared memory. The handle, which functions as a placeholder or pointer to a referenced part of memory, is then placed in the circular memory queue (enqueued) in the direction of the Exchange information store. 4. On the Exchange store side, the ExIPC.DLL for POP3 checks for incoming POP3 requests. The DLL receives the Request Mail Message and removes the handle from the circular memory queue. The Exchange store-side POP3 stub references the handle to the data in the shared memory heap. 5. If there are no failures or performance problems on the Exchange store side, the ExIPC process is complete and the data is successfully communicated from the IIS to the Exchange store. If a queue is full or the Exchange store has stopped, an error message is returned. 6. A response (the mail message) is generated on the Exchange store side. The Exchange information store allocates the appropriate shared memory for the response from the shared memory heap. A corresponding handle is assigned to that shared memory. The handle is then enqueued in the direction of IIS. 7. IIS removes the handle from the circular queue, references the shared memory, and binds them together. If there are no failures or performance problems on the IIS side, the response is complete and the data is successfully communicated from the Exchange store to IIS.

490

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 APPEND Description 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. Indicates an authentication mechanism to the server (for example, AUTHENTICATE KERBEROS_V5). Used to request a list of capabilities that the server supports. 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. Permanently removes from the currently selected mailbox all messages that have the \Deleted flag set, and returns to authenticated state from selected state.

AUTHENTICATE

CAPABILITY CHECK

CLOSE

491

Command COPY

Description 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. Used to create a mailbox with the particular name. An OK response is returned only if a new mailbox with that name is created. Permanently removes the mailbox with the particular name. A tagged OK response is returned only if the mailbox is deleted. 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. Permanently removes from the currently selected mailbox all messages that have the \Deleted flag set. Retrieves data associated with a message in the mailbox. Returns a subset of names from the complete set of all names available to the client. Identifies the client to the server and carries the plain text password authenticating this user. Informs the server that the client is done with the connection. Returns a subset of names from the set of names that the user declared as being "active" or "subscribed."

CREATE

DELETE

EXAMINE

EXPUNGE

FETCH LIST

LOGIN

LOGOUT LSUB

492

Command NOOP

Description 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. Changes the name of a mailbox. A tagged OK response is returned only if the mailbox is renamed. Searches the mailbox for messages that match the specified searching criteria. Searching criteria consist of one or more search keys. Selects a mailbox so messages in the mailbox can be accessed. 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. Alters data associated with a message in the mailbox. 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. 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.

RENAME

SEARCH

SELECT STATUS

STORE SUBSCRIBE

UID

493

Command UNSUBSCRIBE

Description Removes the specified mailbox name from the server's set of "active" or "subscribed" mailboxes, as returned by the LSUB command. This command returns a tagged OK response only if un-subscription is successful.

NNTP
Network News Transfer Protocol (NNTP) is a TCP/IP protocol based on text strings that are sent bi-directionally over seven-bit ASCII TCP channels. The IETF owns the NNTP protocol, which is defined in RFC 977. NNTP is commonly referred to as the Internet News Protocol, because it contains the rules for transporting news articles from one computer to another. NNTP is discussed here as a client/server protocol. It also encompasses server-to-server based news transfer. The NNTP service in Windows is designed to support a stand-alone newsgroup server that can easily create group discussions. When Exchange 2003 is installed, the NNTP service is enhanced with the ability to interface with other news servers through news feeds. The NNTP service can communicate with external NNTP servers to make popular USENET groups available to users. The standard storage location for the NNTP service is in one or more directories in the file system. With Exchange Server 2003, the NNTP service can also store newsgroups in the public folders of any available public folder tree. Internet Newsgroups folder is the default location for newsgroups. The NNTP service uses virtual directories to reference these locations. You can arrange multiple news servers in a master server/subordinate server layout. This enables clients to connect to a large group of servers and still maintain accurate views of newsgroup content. A bank or group of servers provides additional scalability for many clients and provides fault tolerance if a subordinate server goes offline. The Exchange Server 2003 implementation of NNTP provides the following additional features for this protocol: Content indexing provides search features for public folders. Full news feeds are accepted independent of back-end storage.

MAPI or NNTP clients can read or post to newsgroups that are supported by the Exchange information store.

494

Configuration Settings in Active Directory

Although Exchange integrates with IIS, as soon as Exchange 2003 is installed, protocol virtual servers are managed by Exchange System Manager, and not by Internet Services Manager. When you add, remove, or configure an item in Exchange System Manager, the configuration changes are first saved to the Microsoft Active Directory directory service and then replicated to the IIS metabase, on the appropriate Exchange 2003 server, by the Directory Service/Metabase Synchronization (DS2MB) function that runs in the System Attendant process. Note: You can view a semi-graphical representation of Exchange 2003 configuration information stored in Active Directory in Microsoft Knowledge Base article 252370, "Layout of Exchange Configuration in Active Directory."

Configuration Settings in the Metabase

The IIS metabase is a hierarchical database that is used to store configuration values for IIS and Exchange 2003. The IIS metabase is both a storage mechanism and an application programming interface (API) set used to make changes to the configuration parameters. The function of the DS2MB process is to transfer configuration information from Active Directory to the Exchange server's local IIS metabase. For performance and scalability reasons, this configuration is stored in the local IIS metabase instead of in the registry. Note: On computers running Windows 2000 Server, the IIS metabase is located at System32\Inetsrv\Metabase.bin. On computers running Windows Server 2003, the IIS metabase is located at metabase.xml. The IIS metabase can be manipulated through a variety of tools. On computers running Windows Server 2003, the built-in IISCNFG tool can be used. On computers running Windows 2000 Server, the MetaEdit 2.2 or later tool from the IIS Resource Kit is a good option. You can download the IIS 6.0 Resource Kit from the Internet Information Services (IIS) 6.0 Resource Kit Tools Web site. Paths in the metabase are named keys. Properties can be set at each key, and each property can have attributes that customize that property. All identifiers that are present in the directory service image of the subtree are required in the metabase, including identifiers such as KeyType. Additionally, the Relative Distinguished Name of the object in the directory is mapped directly to the key name in the metabase.

495

IIS Metabase Updates Through DS2MB

DS2MB is a subprocess that is launched when System Attendant is started, and every 15 minutes thereafter. DS2MB copies all subtrees from Active Directory without changing the shape of the subtree. This is a one-way write from Active Directory to the metabase; the metabase never writes to Active Directory. It does not add or compute any attribute when copying. Note: The DS2MB process overwrites changes that are made to Exchange virtual servers and directories using the IIS snap-in with information that is contained in Active Directory. The operation of SMTP, POP3, IMAP4, and HTTP depends on the replication by DS2MB. Not all settings are synchronized from Active Directory, some are written to the metabase directly during the installation of Exchange. Upon instantiation, DS2MB registers with the configuration domain controller. The configuration domain controller notifies DS2MB, within 15 seconds, of any changes that are made to the Exchange configuration . As soon as the change is replicated to the configuration domain controller, it must be replicated to the metabase by DS2MB.

High Water Marks

High water marks are entries in the metabase that enable DS2MB to track changes that have been synchronized from Active Directory. High water mark entries are entered in the IIS metabase in the form of GUIDs. These GUIDs appear under the [/DS2MB/HighWaterMarks] node in the metabase, as illustrated below:
[/DS2MB/HighWaterMarks] KeyType : (STRING) "Ds2mbHighwatermarks" [/DS2MB/HighWaterMarks/{BE583A06-9083-400F-954C-CF4ACCA78B04}] [/DS2MB/HighWaterMarks/{028C8F78-8CF0-43D9-9B35-9819D538849F}] [/DS2MB/HighWaterMarks/{84ECD394-05BB-4661-BA1D-81D3E32BF804}]

Because DS2MB handles the entry and synchronization of high water marks in the metabase, there is usually no reason to adjust or manage this information. However, there are known scenarios in which the resolution includes deleting the high water mark entries from the metabase to reset them.

Front-End Server Architecture

A front-end server is a server running Exchange Server 2003 that does not host a database (except when also serving as an SMTP server), but instead forwards client requests to the back-end server for processing. The front-end server uses Lightweight Directory Access

496

Protocol (LDAP) to query Active Directory to determine which back-end server hosts the user's mailbox. A back-end server is a server running Exchange Server 2003 that maintains at least one database. This architecture is available only for RPC over HTTP, HTTP/WebDAV, POP3, and IMAP4 clients. It is not intended for MAPI or NNTP clients. Clients that are supported connect to a front-end server that proxies client commands to the user's back-end server, which hosts an Exchange information store. This functional division between a front-end server and a back-end server provides several benefits. For example: Single Namespace As multiple back-end servers are configured to handle additional mailboxes, it is best to identify all the servers with a single name. You can refer to a front-end server with a single name, and it can proxy user requests to the correct back-end server containing that user's mailbox. If multiple front-end servers are configured to manage a high number of requests, a single namespace for these servers is maintained by configuring the Domain Name System (DNS) with one name mapped to the IP address on the server. It is not important which front-end server the client connects to. Offload SSL Encrypting and decrypting message traffic uses many CPU cycles. A front-end server can perform encryption work, giving the back-end server more cycles to manage the mailbox and public folder information stores. Public Folder Referrals for IMAP4 Clients Many IMAP4 clients do not support referrals. With this architecture, the front-end server can retrieve public folders that exist on a server other than the user's e-mail server. Server Location You can put the back-end servers that contain the databases behind a firewall for increased protection. You can configure the firewall to allow traffic only from the front-end server. Additionally, you can put a reverse proxy (such as ISA Server) in front of a front-end server and only publish the front-end server. It is not necessary to publish the back-end mailbox servers to the Internet. Therefore, you can configure your firewalls and reverse proxies to allow traffic only to the front-end server.

Considerations When Using Front-End Servers

You can configure either Exchange Server 2003 Standard Edition or Exchange Server 2003 Enterprise Edition for use as a front-end server in a front-end and back-end server configuration. The following considerations apply when you configure either edition as a frontend server: If the front-end server accepts SMTP mail from the Internet, you must start the Microsoft Exchange Information Store service and mount at least one mailbox store. In certain situations (most notably in the generation of non delivery reports), the SMTP service requires a mailbox store to perform a conversion.

497

If the mailbox store is not mounted, messages that must be converted are stuck in the local delivery queue. For security reasons, make sure that user mailboxes are not homed on the mailbox store of a front-end server. If there are servers that are running Exchange Server 5.5 in the same site (routing group), you must configure the Microsoft Exchange MTA Stacks service to run on the front-end server. In this configuration, the MTAs can bind and transfer mail by using RPCs. If X.400 connectors or Exchange Development Kit (EDK) gateway connectors are homed on the front-end server, the MTA service must also run on the front-end server. If you delete all public folder and mailbox stores, you cannot change the configuration by using Internet Services Manager. If you must change the configuration by using Internet Services Manager, for example when you change an SSL encryption configuration, make sure that you either complete the procedures that this guide describes before you remove the stores, or leave the private information store intact on the front-end server. When you create a front-end server, do not delete the First Storage Group object in Exchange System Manager. The Microsoft Exchange Information Store service (and its related services) depends on the First Storage Group object.

Exchange ActiveSync and Exchange 2003

Exchange ActiveSync enables you to synchronize data between your mobile device and Exchange Server 2003. E-mail, contacts, and calendar information (Personal Information Manager, or PIM, data) can all be synchronized. This feature was previously available through Mobile Information Server and was referred to as Microsoft Server ActiveSync. It is now integrated with Exchange Server 2003. With Mobile Information Server, devices running Microsoft Windows Powered Pocket PC 2002, Microsoft Windows Powered Pocket PC 2002 Phone Edition, and Microsoft Windows Powered Smartphone had the Server ActiveSync client component installed and were supported. With Exchange ActiveSync, devices that are running Pocket PC 2002, Pocket PC 2002 Phone Edition, and Smartphone are still supported. Additionally, Microsoft Windows Powered Pocket PC 2003 devices are supported. Pocket PC 2003 devices enable greater granularity in scheduling synchronization and also support the Always Up To Date functionality that is introduced in Exchange Server 2003. Exchange ActiveSync is implemented in the following files:
Massync.dll Masperf.dll MasPerf.ini

OMA Sync ISAPI extension DLL OMA Sync Performance Counter DLL OMA Sync Performance Counter INI

498

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.

499 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.

500

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 Mobile Information Server 2002 Exchange Server 2003 Protocols Supported 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 Pocket PC 2002 Pocket PC 2003 Protocols Supported 1.0 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).

501

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.

502

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.

503

The client sends the SyncKey to the server with each synchronization request. Each object that is synchronizedwhether a message, contact, or calendar itemhas 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.

504

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.

505

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

506

interface (GUI) applications to applications based on the latest innovations provided by ASP.NET Web Forms and XML Web services.

ASP.NET
ASP.NET enables developers to use the .NET Framework to target Web-based applications. ASP.NET is more than a runtime host. ASP.NET is a complete architecture for developing Web sites and Internet-distributed objects using managed code. Both Web Forms and XML Web services use IIS and ASP.NET as the publishing mechanism for applications. Both have a collection of supporting classes in the .NET Framework. The .NET Framework also provides a collection of classes and tools to assist in development of mobile controls. Mobile controls are used to develop applications for handheld devices and are device-specific. Mobile controls reduce development time and make sure that the correct markup is returned to the client device. ASP.NET Framework 1.1 provides an abstraction of a user interface with objects representing the fundamental components of a visual display, such as text labels and input boxes. It is the runtime's task to convert this abstract representation to device-specific markup. ASP.NET provides mobile Web Form controls that represent individual components of the user interface. These components are used to define a user interface in a Web page. ASP.NET delivers the content in the markup language appropriate to the requesting device. There are two major client protocols that are used by browsers to date: cHTML and xHTML. ASP.NET automatically renders the correct elements for the specified wireless device.

Session Management
As mentioned at the beginning of this section, Outlook Mobile Access requires Session State management to operate correctly. The HTTP protocol is effectively stateless, as it provides no mechanism for identifying or maintaining sessions between a Web server and a client. This problem is addressed in ASP by providing a Session object that enables you to uniquely identify a user and store information specific to his or her interactions with a Web server. ASP.NET offers an updated and improved version of the Session object. This object enables you to perform the following tasks: Identify a user through a unique session ID Store information specific to a user's session Manage a session lifetime through event handler methods Release session data after a specified timeout

Outlook Mobile Access uses ASP.NET default, in-process session state handling, and the modified URL method of session management.

507

Modified URL Session ID

A modified URL is a URL that contains a session ID. The session ID takes the form of the standard URL with a unique identifier added between the application and the Web page (such as http://server/oma/(a5db038hclb4b1g5ukhrsu55)/oma.aspx). When the Web server receives the request, it parses the session ID from the modified URL. The runtime then uses the session ID just as it would use a session ID obtained from a cookie. If the client does not support cookies, runtime does not automatically use modified URLs. Note: There is a potential problem with mobile devices that do not support modified URLs for session ID. Some wireless browsers experience difficulties dealing with relative URLs after they have been redirected to a modified URL. The problem occurs because they support URL lengths much shorter than those supported by desktop browsers. An application in a deeply nested hierarchy might require URLs with lengths that exceed what is supported by some browsers.

ASP.NET Device Updates

Mobile device updates are incorporated into the .NET Framework Device Updates. After all, Outlook Mobile Access derives from these base classes. The Device Updates (DUs) are tentatively scheduled for quarterly updates. Any modifications required to provide proper rendering on a specific device are included in the web.config in the root of the browse directory. The web.config is updated as part of the device updates. Any customization will be overwritten. Administrators and developers are discouraged from modifying web.config settings for a device Microsoft has not tested. In many cases, there will be no interoperability problems between the mobile device and Exchange. However, there is no support for such modifications, and the end result may remove the ability to debug Outlook Mobile Access.

Outlook Mobile Access Architecture

For data access and processing, CDOEX, DAV, Microsoft Outlook Web Access Templates and system.directory services are used inside the Outlook Mobile Access process. Active Directory, the registry, the IIS metabase, and the web.config file are read to obtain configuration settings. Outlook Mobile Access must receive the user credentials in clear text through Basic authentication. Outlook Mobile Access does not support or work with Windows Integrated Authentication even if the device/browser supports it.

508

ASP.NET works in conjunction with IIS, the .NET Framework, and the underlying security services provided by the operating system, to provide a range of authentication and authorization mechanisms.

Outlook Mobile Access and Microsoft Outlook Web Access Templates

Web Distributed Authoring and Versioning (WebDAV) provides raw access to most data hosted on Exchange. Some common tasks, such as accepting a meeting request, creating a meeting request, and resolving an ambiguous e-mail recipient, are difficult to implement using WebDAV. Generally, Microsoft Outlook Web Access responds to a user request with an HTML page. The runtime does not automatically use modified URLs if the client does not support cookies. The format of the response page is determined by templates. Outlook Mobile Access leverages Microsoft Outlook Web Access functionality. Outlook Mobile Access uses custom templates to control the information and the format of the information returned from the Microsoft Outlook Web Access functions. These templates return data in a format that is similar to a WebDAV response. This provides unification of the data format returned by functions using Microsoft Outlook Web Access for data retrieval and those using WebDAV. WebDAV is the foundation for most operations in the Outlook Mobile Access Exchange Data Provider. The WebDAV protocol, designed for general data access, extends HTTP to HTTP 1.1. This enables data storage on the server and retrieval by the HTTP client. The fundamental operations are: Navigate folder Enumerate folder items Search folder for items Get item details Modify attributes of message, contact, and task Submit composed message

The Exchange Data Provider classes provide the interface with Exchange Server for those functions not obtained from Microsoft Outlook Web Access.

Outlook Mobile Access Data Sources

Outlook Mobile Access retrieves configuration and other data from a variety of sources, including Active Directory, the IIS metabase, the Windows registry and Web.config. Retrieving data for a user through WebDAV and Microsoft Outlook Web Access templates requires Outlook Mobile Access to construct the WebDAV/OWA URL as follows:

509

http://<servername>/<virtualdirectoryname>/<mailbox>. In this case, the value for <servername> is retrieved from the User object of the user who is logged on. In cross forest topologies, this information is read from the disabled user account in the resource forest. The <virutaldirectoryname> is retrieved from the ExchangeVDir registry. Determining the correct <mailbox> is more complex. The only way to determine a user mailbox name is to find the user's SMTP address for the mailbox. You can find this value from the User object. However, there is a problem with this method. The attribute might contain more than one SMTP address for the user. The correct SMTP address is determined by the SMTP Domain of the mailbox in question. The SMTP Domain is configured through Exchange System Manager per virtual directory for Microsoft Outlook Web Access, Outlook Mobile Access and Exchange ActiveSync. This facilitates hosting as the same front-end server can have multiple Outlook Mobile Access virtual directories and each virtual directory represents a unique SMTP Domain. This setting is stored in the directory with one SMTP Domain per virtual directory per Exchange server. Outlook Mobile Access, in addition to Exchange ActiveSync and Microsoft Outlook Web Access, do not have read access to this attribute. Access rights are restrictive because it is an administrator setting. The DS2MB process does have read access. The mailbox resolution process is as follows: 1. Exchange System Manager writes an SMTP Domain value to Active Directory for a certain virtual directory on a certain server. 2. DS2MB on that server picks the setting up and replicates it to the IIS metabase on the computer. 3. Outlook Mobile Access reads the SMTP Domain for the virtual directory in which they are running. 4. Outlook Mobile Access looks up the SMTP addresses on the Active Directory User object (in cross-forest topologies, this information is read from the disabled user account in the Exchange resource forest). 5. Outlook Mobile Access picks out the SMTP address using the SMTP Domain in the list. 6. The SMTP address is on the format <mailboxname>@<SMTP Domain>, Outlook Mobile Access extracts the <mailboxname>. The <servername>, <virtualDirectoryName>, and <mailbox> values are then linked together to provide the DAV/OWA URL that the back-end server requires.

Outlook Mobile Access Directory Settings

Outlook Mobile Access reads configuration settings from Active Directory whenever a new session is created (and only when a new session is created). The following two tables

510

describe the forest-wide and user-specific Outlook Mobile Access configuration settings in Active Directory. Forest-wide Outlook Mobile Access directory settings Directory Setting Outlook Mobile Access Description Outlook Mobile Access root node under Exchange Active Directory settings. Contains Outlook Mobile Access-global attributes and containers for more Outlook Mobile Access settings. 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).

msExchOmaAdminWirelessEnable

Per-user Outlook Mobile Access directory settings Directory Setting msExchOmaAdminExtendedSettings Description Space for admin controlled settings for a user. Example: Allow/disallow access to features such as calendar or contacts in Outlook Mobile Access. Reserved for future feature-expansion (without requiring Active Directory schema changes).

msExchOmaExtendedProperties

511

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.

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

512

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 Specifies what virtual 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 (/). 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. When set to '1', the character set iso-8859-15 is used wherever the iso-88591 would have been used.

MasSync\Parameters\Excha /Exchange or other string ngeVDir that starts with /

MSExchangeWEB\OWA\Us eRegionalCharset

1 or anything

MSExchangeWEB\OWA\Us eISO8859_15

1 or anything

513

Key MSExchangeWEB\OWA\Us eGB18030

Value 1 or anything

Description When set to '1', the character set GB18030 is used wherever the GB2312 would have been used. Used to publish Outlook Mobile Access performance objects and counters.

MSExchangeOMA\Performa N/A nce

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 <appSettings> Setting <add key="CredentialsTimeout" value="60"></add> Description 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="DefaultConnectionLimi number of simultaneous t" value="500"></add> connections Outlook Mobile Access can open to an individual back-end server. <add key="MaxServicePointIdleTi me" value="60000"></add> Tells Outlook Mobile Access how many milliseconds to wait for replies from the back-end server before timing out.

514

<add key="UnsupportedMessage " value="http://<server>/OMA Devices"></add> <system.web> <sessionState mode="InProc" cookieless="true" timeout="20" />

When this message is defined, additional text shows up on the unsupported warning and unsupported error pages. By default this key is null. Specifies the session state configuration that is used by Outlook Mobile Access. The timeout value indicated for how many minutes the session state is kept in memory after the last request arrives for the session. 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). Defines the default characters set Outlook Mobile Access uses to send HTTP responses and interpret incoming requests without a character set specified. Determines whether Outlook 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. Sets Response.Charset to this value for all requests.

<mobileControls SessionStateHistorySize="8 ">

<globalization requestEncoding="utf-8" responseEncoding="utf8" />

<browserCAPs>

supportsBackNavWithExpir esHeader

preferredResponseCharset

515

preferredResponseCodePa ge

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. supportsOpenwaveUniversa Tells Outlook Mobile Access lLocalSrc to insert access keys before links. defaultTextboxMaxlength Sets the MaxLength of strings permitted in TextBox controls. The P800, for example, will default to 64 without this set.

Outlook Mobile Access Client Requests

When an Outlook Mobile Access client issues a Web request, the following sequence of authentication and authorization events occurs: 1. The HTTP(S) Web request is received from the network. SSL can be used to verify the server identity. SSL also provides a security channel to help protect sensitive data passed between client and server. 2. IIS authenticates the caller by using Basic authentication. IIS creates a Windows access token for the authenticated user. 3. IIS authorizes the caller to access the requested resource. NTFS file system permissions defined by access control lists (ACLs) attached to the requested resource are used to authorize access. 4. IIS passes the authenticated caller's Windows Server access token to ASP.NET.

Outlook Mobile Access Security Architecture

The underlying security architecture of Outlook Mobile Access depends on whether Exchange 2003 is running on Windows Server 2003 or Windows 2000 Server. On Windows Server 2003, Outlook Mobile Access runs in its own process in a dedicated program pool,

516

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. This section discusses the following concepts: Exchange Storage Architecture Exchange Server 2003 uses a transaction-based storage architecture that includes a database file, a native content file, transaction logs, and other files, such as checkpoint files and reserved logs. You must understand how Exchange Server 2003 uses these files to store messaging data. Extensible Storage Engine Architecture Extensible Storage Engine is at the core of the Exchange store. You must be familiar with Extensible Storage Engine to understand the architecture of the Exchange store. Responsibilities of the Exchange store In the client/server architecture of Exchange Server 2003, the Microsoft Exchange Information Store service has exclusive access to the messaging databases. Exclusive database access entails a number of responsibilities that you should be familiar with to understand the role of the Microsoft Exchange Information Store service.

517

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

518 Current Exchange Server 2003 database

The following two types of databases are available in Exchange Server 2003: Private store databases These databases store mailboxes and message queues for MAPI-based messaging connectors. Public store databases These databases store public folder hierarchies and public folder contents. The following figure illustrates the internal Exchange store architecture. The Microsoft Exchange Information Store service (Store.exe) uses Extensible Storage Engine (ESE) to access the database files in the file system, and provides access to the data through various interfaces, such as MAPIsvr, ExPOP, ExIMAP, ExSMTP, and ExOLEDB. Client application and application programming interfaces, such as Collaboration Data Objects for Exchange (CDOEX), can use these interfaces or communicate with the messaging database (MDB) module. Exchange store architecture

Storage Groups
Each storage group is made up of a set of log files and auxiliary files (internal temporary databases, the checkpoint file, and reserve logs) for all the databases (.edb files, .stm files) in the storage group. Exchange Server 2003 supports multiple storage groups and multiple databases in each storage group. In Exchange Server 2003, a single server supports up to four storage groups and a single storage group supports up to five databases. Support for multiple databases enables you to distribute numerous mailboxes and public folders across

519

numerous, smaller databases, thus making database management easier. Exchange 2000 Server and Exchange Server 2003 can support up to 20 mailbox and public folder databases on a single server.

Storage Group Architecture

As illustrated in the following figure, all storage groups are hosted from the same Store.exe process. Each storage group is represented by an ESE instance. Storage group architecture

Within each storage group, each .edb and .stm database pair represents a mailbox store or a public folder store. As shown in Figure 10.3, all mailbox and public folder stores in a particular storage group share a common set of log files and other system files. These files enable transaction-oriented processing. The log files and other system files in each storage group have the following purposes: <Log Prefix>xxx.chk This is the checkpoint file (for example, E00.chk) that determines which transactions require processing to move them from the transaction log files to the databases. Checkpoint files are updated when ESE writes a particular transaction to a database file on a disk. This update always points the checkpoint file to the last transaction that was transferred successfully to the database. This update provides a fast recovery mechanism. However, checkpoint files are not required to commit transactions to databases. ESE has the ability to process transaction log files directly and to determine for itself which transactions have not yet been transferred. This process takes significantly more time than using checkpoints. Note: Extensible Storage Engine guarantees that transactions are not written to a database multiple times.

520

Exx.log This is the current transaction log file for the storage group. Transaction log files give ESE the ability to manage data storage with high speed efficiency. ESE stores new transactions, such as the delivery of a message, in a memory cache and in the transaction log concurrently. The data is written sequentially. New data is appended to existing data without the need for complex database operations. At a later time, the transactions are transferred in a group from the memory cache to the actual databases, which update them. By default, the default storage group, named First Storage Group, uses the prefix E00, which results in a transaction log file name of E00.log. The E00.log is used for all mailbox and public stores in this storage group. If you create additional storage groups, the prefix number is incremented to E01, E02, and E03. <Log Prefix>XXXXX.log These are transaction log files that have no room remaining for further data. By default, transaction log files are always exactly 5.242.880 bytes (five megabytes) in size. It is theoretically possible to change the log file size, but this is not recommended. When a log is full, it is renamed to allow the creation of a new, empty transaction log file. Renamed transaction log files are named previous log files. The naming format of previous log files is <Log Prefix>XXXXX.log (such as E00XXXXX.log), where XXXXX represents a five-digit hexadecimal number from 00000 to FFFFF. Previous log files reside in the same directories as the current transaction log file. Res1.log and Res2.log These are reserved transaction log files for the storage group. Reserved log files are an emergency repository for transactions. They provide enough disk space to write a transaction from memory to the hard disk, even if a server's disk is too full to admit new transactions to a log file. The reserved log files can be found in the transaction log directory. They are created automatically when the databases are initialized. They cannot be created later. ESE uses reserved transaction log files only to complete a current transaction process. It then sends an error notification to Store.exe to dismount the Exchange store safely. In the application event log, there is an entry that indicates the issue. In this situation, you should create additional free hard disk space (for example, add a new hard disk) before you mount the database again. Tmp.edb This is a temporary workspace for processing transactions. Tmp.edb contains temporary information that is deleted when all stores in the storage group are dismounted or the Exchange Information Store service is stopped. Note: Tmp.edb is not included in online backups. <file name>.edb These are the rich-text database files for individual private or public stores. The rich-text database file for the default private store is named Priv1.edb. The file for the default public store is named Pub1.edb.

521

<file name>.stm These are the streaming Internet content files for individual databases. The streaming database file for the default private store is named Priv1.stm. The file for the default public store is named Pub1.stm.

Storage Group Attributes in Active Directory

You can determine the path to a storage group's transaction log file and the log file's name in Exchange System Manager. Right-click the desired storage group, select Properties, and from the General tab, look at the information in the Transaction Log Location and the Log File Prefix fields. Using the Browse buttons, you can move the transaction log and system files to a new location, such as a separate physical drive. The configuration settings for a storage group are stored in Active Directory. If you want to use ADSI Edit to locate the directory object for a storage group, you must open the configuration naming contacts, expand the services node, then CN=Microsoft Exchange, and then expand the Exchange organization object, administrative group, and server container. Underneath it, you can find a container named CN=InformationStore, which contains the storage groups, such as CN=First Storage Group. The object class for storage group objects is msExchStorageGroup. If you plan to use custom scripts to manage Exchange store resources, you can access msExchStorageGroup objects by using Active Directory Service Interfaces (ADSI). The following code example demonstrates how to access the default storage group on a server called SERVER01 in an Exchange organization called Contoso. It displays the current path to the transaction log files of that storage group.
strStorageGroupDN = "CN=First Storage Group," _ & "CN=InformationStore," _ & "CN=SERVER01,CN=Servers," _ & "CN=First Administrative Group," _ & "CN=Administrative Groups," _ & "CN=Contoso,CN=Microsoft Exchange," _ & "CN=Services,CN=Configuration," _ & "DC=Contoso,DC=com" Set oStorageGroup = GetObject("LDAP://" & strStorageGroupDN) MsgBox oStorageGroup.Get("msExchESEParamLogFilePath")

The following are important Exchange attributes of msExchStorageGroup objects that you can use in custom scripts based on ADSI: msExchESEParamCircularLog This is a Boolean flag that determines whether circular logging is enabled or disabled. A value of 0 indicates that circular logging is disabled; a value of 1 indicates that circular logging is enabled. Circular logging causes ESE to discard transactions when the committed changes are transmitted to the database file on disk. The checkpoint file indicates which log files and transaction entries are successfully committed to the database. Any existing previous logs are deleted, while transactions in the current transaction log file are marked as

522

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

523

msExchESEParamEnableIndexChecking This is a Boolean flag that determines whether the operating system version is checked for Unicode indexes. A value of 0 indicates that index checking is not performed. A value of 1 indicates that index checking is performed. This parameter detects changes in the operating system that result from upgrading to a newer version or from applying a service pack. This flag determines whether the sort order for Unicode has changed. Whenever the operating system is changed in this manner, re-indexing occurs automatically. msExchESEParamBaseName This attribute specifies the base name for the log files in this storage group. For example, a base name of E00 results in a transaction log file name of E00.log. msExchESEParamDbExtensionSize This attribute specifies the database extension size, in pages. The default value is 2 megabytes (MB). msExchESEParamPageTempDBMin This attribute specifies the minimum size of the temporary database, in pages. The default value is 0. msExchESEParamCheckpointDepthMax This attribute specifies the preferred (not hard) maximum checkpoint depth, in bytes.

Storage Group Minimum Disk Space Requirements

Each storage group consumes about 50 MB of free disk space. The files listed above that are required by the storage group use a minimum of 11 MB of disk space. The minimum disk space for private and public stores is 5 MB and 8 MB, respectively. Although the total disk space used is about 24 MB, extra disk space is also needed for the actual creation of the storage group and for read and write operations. When working with storage groups, remember the following: A server running Exchange Server 2003 can have up to five storage groups. Because one of the storage groups is reserved for database recovery operations, only four storage groups can be used to hold databases that are accessible by clients. Attempts to create more than four storage groups result in an error message. You can create only five databases in a storage group. Attempts to create more databases result in an error message.

Exchange Store Databases

Exchange Server uses ESE as an embedded database engine that determines the structure of the databases and manages memory. The database engine caches the databases in memory by transferring four-kilobyte chunks of data (pages) in and out of memory. It updates the pages in memory and writes new or updated pages back to the disk. When requests

524

come to the system, the database engine can buffer data in memory, so that it does not have to access the disk constantly. This makes the system more efficient, because writing to memory is approximately 200,000 times faster than writing to disk. When users make requests, the database engine starts loading the requests to memory and marks the pages as dirty. A dirty page is a page in memory that contains data. These dirty pages are later written to the Microsoft Exchange Information Store service databases on disk. Although caching data in memory is the fastest and most efficient way to process data, it means that while Exchange is running, the information on disk is never completely up-to-date. The latest version of the database is in memory, and because many changes in memory are not on disk yet, the database and memory are not synchronized. If there are any dirty pages in memory that have not been transferred and written to disk, the databases are flagged as inconsistent. Exchange databases are synchronized only when all dirty pages in memory are transferred to disk. This happens when you properly shut down the Microsoft Exchange Information Store service. During the shutdown process, the Microsoft Exchange Information Store service flushes all pages to disk.

MAPI Database File

The Exchange Server 2003 MAPI database file contains the tables that hold the metadata for all e-mail messages, other objects in the database, and the contents of MAPI messages. Every folder displayed in Microsoft Office Outlook is a separate database table in the Exchange store. Every sort order used to view these folders is represented by a separate index on that table. The Store.exe process manages these sort orders. Messages from MAPI clients, such as Outlook, are stored in the MAPI database, just as they were stored in previous versions of Exchange Server. MAPI-based clients can then access these messages without conversion. However, if an Internet protocol-based client attempts to read a message in this database, the message is converted to the requested format. The traditional .edb file and its accompanying .stm file are a single unit. One of these files is of little use without the other file. It is important to understand that a single database in the Microsoft Exchange Server Information Store service contains two files, the .edb file and the .stm file. A record in the .edb file contains a column (of data type JET_coltypSLV) that references a list of pages in the streaming file that contains the raw data. Space usage (maximum of four kilobytes of page numbers) and checksum data for the data in the streaming file is stored in the .edb file.

Streaming Database File

Exchange Server 5.5 and earlier store messages in message database encapsulated format (MDBEF). This is the native format for Outlook clients. When a non-MAPI client requests a message, the Microsoft Exchange Information Store service converts the contents from

525

MDBEF to the appropriate format, based on what the client requests. This conversion consumes processor bandwidth and slows server performance. Later versions of ESE enable Internet messaging clients to store raw data in native format. The repository for this raw data is referred to as the streaming database, or simply the streaming file. The streaming file has no balanced tree (B-tree) overhead. Instead, it contains two four-kilobyte pages of header information and then raw data in four-kilobyte pages. This flat data structure is designed for binary large objects (BLOBs) of data that are unlikely to need content conversion and that can be received and transmitted very quickly.

Property Promotion
Property promotion determines where data is stored in an ESE database and is therefore an important concept to understand. The Microsoft Exchange Information Store service supports the property promotion of data held in the .stm file to the .edb file. Property promotion enables folder views and indexes to be maintained efficiently. For example, a message streamed to the .stm file has its properties, such as sender, subject, and date sent and received, promoted to the records representing the message in the .edb file. When a MAPI client, such as Microsoft Outlook, submits a message to the Microsoft Exchange Information Store service, the contents of that message are stored in the .edb file. If a non-MAPI client opens the message, the Microsoft Exchange Information Store service does an immediate conversion of the MAPI content to Internet format by performing some of the conversion and calling IMAIL, which in turn calls RTFHTML, to complete the conversion. None of this conversion is persistent, meaning that data is not moved out of the .edb file and written to the .stm file. If an Internet client submits a message to the Microsoft Exchange Information Store service, the contents of that message are stored in the .stm file. Certain headers from the Internet message are duplicated to the .edb file, so the Microsoft Exchange Information Store service can find the message. This is referred to as a state 0 conversion. If any client asks for a property, such as PR_Subject, or one of its many aliases, then the Microsoft Exchange Information Store service promotes all of the Internet message's header information to Properties. This is referred to as a state 1 conversion. If any client asks for attachment information, then the Microsoft Exchange Information Store service creates a near duplicate (in MAPI form) of the Internet message. At first, the message is still in the .stm file. However, much of the data needed for MAPI access is in the .edb file. If a client alters the message in a way that changes the Multipurpose Internet Mail Extensions (MIME), then the .stm file version of the message is discarded and the .edb file of the message is preserved. This is referred to as a state 2 conversion. Regardless of how a message is submitted to the Microsoft Exchange Information Store service, if Exchange Server receives Internet content that includes Application/ms-tnef content, the message initially goes to the .stm file, but it is then immediately decoded and

526

moved to the .edb file. The same applies to messages with a winmail.dat attachment, encoded using UUEncode. Transport neutral encapsulation format (TNEF) and Winmail.dat are encapsulation methods for MAPI messages to preserve MAPI properties on transports that do not support MAPI. Therefore, the general principal that MAPI messages reside in the .edb file and Internet messages reside in the .stm file is correct. The current functionality has the TNEF decoded before any one of the MAPI properties are read.

Database Size Limit Configuration and Management

Prior to Microsoft Exchange Server 2003 Service Pack 2 (SP2), there was no method to configure database size limits for Exchange Server 2003. Exchange Server 2003 SP2 introduces the following new features: For the Standard Edition, the default configured database size limit will now be 18 GB, a 2 GB addition to the previous limit, with a new maximum size of 75 GB. For the Enterprise Edition, there is no default configured database size limit, and no software set maximum size. Both versions of Exchange Server 2003 with SP2 have the ability to configure a limit, a warning threshold, and a warning interval set through registry keys. Size check done against the database now uses logical database size. Empty or white space in the database does not count against the configured database size limit; therefore, no offline defragmenting is required for recovery exceeding the configured or licensed database limits. Limit checks, done at regular intervals, are now controlled by the store process instead of JET. The default time interval is 24 hours and this interval is configurable through the registry.

Registry Settings
The database size limit registry keys are read when the database mounts (not when the service starts up), and when each limit check task runs. You must set registry parameters for each database targeted for size limit modification. The registry entries should be located under each database entry in the local server registry. Accordingly, you must reset the registry keys manually if the server has to be rebuilt using the /disasterecovery setup switch.

527

Note: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. 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 databases Active Directory object. Note: By default, registry entries mentioned in this article are not present; when you create the entry, you override the default value set in code. Note: All of registry values mentioned in this article are in decimal, not hexadecimal. The following new registry settings are available with SP2: Database Size Limit in GB Database Size Buffer Warning in Percentage Database Size Check Start Time in Hours from Midnight

Database Size Limit in GB

The Database Size Limit in GB setting is the configurable maximum size of a database not to exceed the maximum licensed size of your database. For Standard Edition, you can set the database size limit between 1 and 75 GB. By default, the limit is 18 GB. For Enterprise Edition you can set the database size limit between 1 and 8,000 GB. By default, there is no limit. The following registry value controls the Configurable Database Size Limit: Data type REG_DWORD Name Database Size Limit in GB Value (in GB) Standard: 1-75 Enterprise: 1-8000 Default (in GB) Standard: 18 Enterprise: 8,000 Unlimited

528

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 REG_DWORD Name Database Size Buffer Warning in Percentage Value (in %) 1 - 100 Default (in %) 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. Data type REG_DWORD Name Database Size Check Start Time in Hours from Midnight Values 1 - 24 Default 5 Description Determines the hour the first database size check will occur after a database is mounted.

529

Behavior When the Configured Database Size Limit or Licensed Database Size Limit Are Reached
When a database mounts, the store process compares the physical database size against the Configured Database Size Limit in GB. If the physical size is within or exceeds the configured Database Size Warning Buffer in Percentage, the store performs a logical calculation of the database size. If it is below this warning buffer, there is no need to calculate the free space because the logical size will never exceed the physical size. Generally, the physical size is less than the warning threshold, so the size check should take under a millisecond to complete. If the free space calculation must be performed, the size check may require a few seconds to parse through the database to generate the logical size calculation. If the Database Size Warning Buffer in Percentage is reached or exceeded, an error event, event ID 9688, is logged in the Application event log. With Exchange Server 2003 SP2 or later, the server performs the following tasks when the configurable (or default configured) database size limit is reached: If the first check after a database mount finds the database size above the limit, the database will not be taken offline but an error event (ID 9689) will be logged in the Application event log. If it is the second check, an error event will be logged in the Application event log and the database will be taken offline. After the administrator remounts the database, he or she has 24 hours (or until the next database size check or 05:00 if the default is set) to take corrective actions.

Licensed Database Size Limit

Exchange Server 2003 Standard Edition is limited to a single storage group with a single private information store database and a single public folder database. Prior to SP2, each database was limited to 16 GB of total physical size. SP2 increases the licensed database size limit for Exchange Server 2003 Standard Edition from 16 GB to 75 GB; the default configured database size limit will be 18 GB. Exchange Server 2003 Enterprise Edition storage group and Exchange store options do not change with the application of SP2. However, a configurable Exchange store size limit is added to the Enterprise Edition. Exchange Server 2003 version Standard Edition before SP2 Licensed limit 16 GB Default configuration limit Not applicable

530

Exchange Server 2003 version Standard Edition with SP2 Enterprise Edition before SP2 Enterprise Edition with SP2

Licensed limit 75 GB 8,000 GB (unlimited) 8,000 GB (unlimited)

Default configuration limit 18 GB Not applicable 8,000 GB

Note: The current hard coded limit of the JET database is 8,192 GB, or 8 terabytes (TB).

Disaster Recovery Planning Considerations

If you change the size limit of your Exchange databases, you may want to re-evaluate your Exchange database backup and restore plan. Specifically, if you increase the size limit of the Exchange databases, be sure to test your backup and recovery operations using the new database size limits to make sure that you can still meet your service level agreements. For example, if the previous size of a mailbox store was 15 GB and you were able to meet your service level agreement by recovering the data in less than 8 hours, you may no longer be able to recover the database that quickly if you increase the size of a mailbox store to 20 GB or larger. For information about service level agreements, see "Establishing a Service Level Agreement" in "Setting Availability Goals" in the Exchange 2003 High Availability Guide. For information about how to configure database size limit options, see "Configure Database Size Limits" in the Exchange Server 2003 SP2 online Help.

Extensible Storage Engine Architecture

The Exchange store sits on top of an Extensible Storage Engine (ESE) database. ESE is a multi-user, indexed sequential access method (ISAM) table manager with full data manipulation language (DML) and data definition language (DDL) capability. ESE allows applications to store records and create indexes to access those records in different ways. There are three versions of ESE: ESE97 The database engine in Exchange Server 5.5.

ESENT The database engine for Active Directory and many Microsoft Windows components. Unlike other versions of ESE (which use five MB log files and four KB page

531

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

532

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

533

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.

534

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.

535

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.

536

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

537

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.

538

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.

539 Extensible Storage Engine column data types Column Data Types Bit Unsigned Byte Short Unsigned Short Long Unsigned Long LongLong Currency IEEE Single IEEE Double Date Time GUID Binary Text Long Binary Long Text Description NULL, 0, or non-0 1-byte unsigned integer 2-byte signed integer 2-byte unsigned integer 4-byte signed integer 4-byte unsigned integer 8-byte signed integer 8-byte signed integer 4-byte floating-point number 8-byte floating-point number 8-byte date-time (integral date, fractional time) 16-byte unique identifier Binary string, length <= 255 ANSI or Unicode string, length <= 255 bytes Large value binary string, length < 2 GB 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.

540

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.

541 Services essential to the operations of Exchange Server 2003 Service Name Distributed Transaction Coordinator Description Coordinates transactions that are distributed across multiple databases, message queues, and file systems. Logs event information, warning, and error messages issued by Exchange Server and other applications. Allows you to administer the Exchange HTTP virtual server in the IIS snap-in. Monitors folders and generates events for Exchange Server 5.5 applications. Provides Exchange IMAP4 services. Manages Exchange Information storage. Provides Exchange X.400 services. Provides Exchange POP3 services. Processes Exchange message routing and link state information. Replicates Exchange information in the organization. Monitors Exchange and provides essential services. Transports newsgroup messages across the network. Transfers e-mail messages across a messaging network. 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).

Event Log

IIS Admin Service Microsoft Exchange Event Microsoft Exchange IMAP4 Microsoft Exchange Information Store Microsoft Exchange MTA Stacks Microsoft Exchange POP3 Microsoft Exchange Routing Engine Microsoft Exchange Site Replication Service Microsoft Exchange System Attendant service Network News Transfer Protocol (NNTP) Simple Mail Transfer Protocol (SMTP) World Wide Web Publishing Service

542

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.

543

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 LRUK 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.

544

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

545

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

546

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

547

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 in the following table. Replication message types Message Type Hierarchy replication messages (0x2) Description A hierarchy replication message is a replication message between replicas of a special folder with the ID 1-1 (FID 1-1). Content replication messages replicate content updates between replicas of individual folders. A public folder store only sends a content replication to another public folder store that holds a replica of the folder. When Used Replicates hierarchy changes from one public folder store to all other public folder stores in the same top level hierarchy. Replicates content changes from one replica to all other content replicas of that folder.

Content replication messages (0x4)

548

Message Type Backfill request messages (0x8)

Description Backfilling is the process by which public folder stores that miss replication updates can request a resend 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 responses are 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.

When Used 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 (0x80000002 or 0x80000004)

Backfill response messages send missing data to a public folder store that requested missed updates (CNSets).

549

Message Type Status messages (0x10)

Description 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. 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.

When Used 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).

550

Message Type Status request messages (0x20)

Description 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.

When Used 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

551

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

552

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.

553

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 Initial backfill First backfill retry Subsequent backfill retries Intra Site 6 hours 12 hours 24 hours Inter Site 12 hours 24 hours 48 hours

If the first backfill attempt is unanswered, subsequent backfill attempts wait longer before they are sent. These times are extended to prevent unnecessary backfilling. The replication message might be in transit, delayed, or waiting for a connector's schedule. If the backfill timeout is too short, public folder stores start issuing backfill requests for messages already in transit.

Replication Status
There are two categories of status messages: status requests, and status messages. A status request message is sent from one public folder store to another to request the other public folder store's current state of a particular folder. A status message is sent from one public folder store to another to indicate the current state of a particular folder on the sending server. If the status message indicates that the sending public folder store has more up-to-date information about the folder, then the receiving store writes an entry to its backfill array to request a backfill. If the CNSets are shown to be equal (or the receiving server is more recent) no action is taken. A public folder store generates a status message under the following two circumstances: In response to a status request If a public folder store receives a status request from another public folder store, it returns a status message. This occurs when the replica list of folders is changed (for example, when a folder is removed from a server).

554

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.

555

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

556

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.

557

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 Replication Expiry Replication Send Always Default Timeout 24 hours 15 minutes Comments How often folders are checked for expiry. 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. This is how often the public folder store checks to see whether a hierarchy replication message needs to be sent. This is how often the public folder store checks to see whether a status message for a folder should be sent. This is how often the public folder store checks to see if any backfill entries have timed out. 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.

Replication Send Folder Tree

5 minutes

Replication Send Status Timeout

24 hours

Replication Timeout

5 minutes

Replication New Replica Backfill Request Delay

15 minutes

558

Replication Event Replication Short Backfill Request Delay

Default Timeout 6 hours

Comments This is the time delay used before sending a backfill request when the data is available on the same site. This is the time delay used before sending a backfill request when the data is not available on the same site. This is the timeout value used when retrying to send a backfill request when the data is available on the same site. This is the timeout value used when retrying to send a backfill request when the data is not available on the same site This is the timeout value 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. This is the timeout value 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.

Replication Long Backfill Request Delay

12 hours

Replication Short Backfill Request Timeout

12 hours

Replication Long Backfill Request Timeout

24 hours

Replication Short Backfill Request Timeout Retry

24 hours

Replication Long Backfill Request Timeout Retry

48 hours

Default Replication Values

The following table illustrates some of the other default values used in public folder replication.

559 Default replication values Description Replication Folder Count Limit Replication Deleted Folder Count Limit Value 20 Comments Maximum number of folders to pack in a hierarchy replication message. Maximum number of folder deletes to pack in a hierarchy replication message. Maximum number of messages to pack in a content replication message. 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.

500

Replication Message Count Limit Replication Message Size Limit

100

300 KB

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.

560

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

561

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 PCIbased SCSI connections, SCSI over Fibre Channel, and SCSI bus with multiple

562

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.

563

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 disks and IP addresses. Persistent and volatile information stored in the configuration database tracks the current and desired state of a cluster. Each instance of Database Manager running on each node in the cluster cooperates to maintain consistent configuration information across the cluster and to ensure consistency of the configuration database copies on all nodes. Database Manager also provides an interface for use by other Cluster components, such as Failover Manager and Node Manager. This interface is similar to the registry interface of Microsoft Win32 APIs. However, the Database Manager interface writes changes made to cluster entities in both the registry and in the quorum resource. Database Manager supports transactional updates of the cluster registry hive and only presents interfaces to internal Cluster service components. Failover Manager and Node Manager typically use this transactional support to get replicated transactions. The Cluster API presents all Database Manager functions to clients, with the exception of transactional support functions. For additional information on the Cluster API, see Cluster API on MSDN. Note: The application registry key data and changes are recorded by Checkpoint Manager in quorum log files, in the quorum resource.

564

Event Service Event Service serves as a switchboard, sending events to and from applications, and to the Cluster service components on each node. The Event Processor component of the Event Service helps Cluster service components to disseminate information about important events to all other components. The Event Processor component supports the Cluster API event mechanism. It also performs miscellaneous services, such as delivering signal events to cluster-aware applications and maintaining cluster objects. Event Log Replication Manager The Event Log Replication Manager replicates event log entries from one node to all other nodes in the cluster. By default, the Cluster service interacts with the Windows Event Log service in the cluster to replicate event log entries to all cluster nodes. When the Cluster service starts on the node, it invokes a private API in the local Event Log service and requests that the Event Log service bind to the Cluster service. The Event Log service then binds to the CLUSAPI interface by using local remote procedure calls (RPCs). When the Event Log service receives an event to be logged, it logs it locally, drops the event into a persistent batch queue, and schedules a timer thread to run within the next 20 seconds, if there is no timer thread that is active already. When the timer threads fires, it processes the batch queue and sends the events, as one consolidated buffer, to the Cluster API interface, where the Event Log service was previously bound. The Cluster API interface then sends the event to the Cluster service. After the Cluster service receives batched events from the Event Log service, it drops the events into a local outgoing queue and returns from the RPC. The event broadcaster thread, in the Cluster service, then processes this queue and sends the events, using the intra-cluster RPC, to all active cluster nodes. The server side API then drops the events into an incoming queue. An event log writer thread then processes this queue and requests, through a private RPC, that the local Event Log service write the events locally. The Cluster service uses lightweight remote procedure call (LRPC) to invoke the Event Log service's private RPC interfaces. The Event Log service also uses LRPCs to invoke the Cluster API interface and then request that the Cluster service replicate events. Failover Manager Failover Manager performs resource management and initiates appropriate actions, such as startup, restart, and failover. Failover Manager stops and starts resources, manages resource dependencies, and initiates failover of resource groups. To perform these actions, Failover Manager receives resource and system state information from Resource Monitors and cluster nodes. Failover Manager also decides which nodes in the cluster should own which resource group. When resource group arbitration finishes, nodes that own an individual resource group return control of the resources in the resource group to Node Manager. If a node cannot handle a failure of one of its resource groups, Failover Managers on each node work together to reassign ownership of the resource group. If a resource fails, Failover Manager restarts the resource or takes the resource offline together with its dependent resources. If Failover Manager takes the resource offline, it

565

indicates that the ownership of the resource will be moved to another node. The resource is then restarted, under the ownership of the new node. This is referred to as failover, as explained in the section "Cluster Failover" later in this topic. Global Update Manager Global Update Manager provides the global update service that is used by cluster components. Global Update Manager is used by internal cluster components, such as Failover Manager, Node Manager, and Database Manager, to replicate changes to the cluster database across nodes. Global Update Manager updates are typically initiated as a result of a Cluster API call. When a Global Update Manager update is initiated at a client node, it first requests a locker node to obtain a global lock. If the lock is not available, the client waits for one to become available. When the lock is available, the locker grants the lock to the client, and issues the update locally (on the locker node). The client then issues the update to all other healthy nodes, including itself. If an update succeeds on the locker, but fails on some other node, that node will be removed from the current cluster membership. If the update fails on the locker node itself, the locker merely returns the failure to the client. Log Manager Log Manager writes changes to recovery logs that are stored on the quorum resource. Log Manager, together with Checkpoint Manager, ensures that the recovery log on the quorum resource contains the most recent configuration data and change checkpoints. If one or more cluster nodes are down, configuration changes can still be made to the remaining nodes. While these nodes are down, Database Manager uses Log Manager to log configuration changes to the quorum resource. When failed nodes return to service, they read the location of the quorum resource from their local cluster registry hives. Because the hive data could be stale, mechanisms are in place to detect invalid quorum resources read from a stale cluster configuration database. Database Manager then requests that Log Manager update the local copy of the cluster hive, using the checkpoint file in the quorum resource. The log file is then replayed in the quorum disk, starting from the checkpoint log sequence number. The result is a completely updated cluster hive. Cluster hive snapshots are taken whenever the quorum log is reset and once every four hours. Membership Manager Membership Manager monitors cluster membership and the health of all nodes in the cluster. Membership Manager (also referred to as the Regroup Engine) maintains a consistent view of which cluster nodes are currently up or down. The core of the Membership Manager component is a regroup algorithm that is invoked whenever there is evidence that one or more nodes failed. At the completion of the algorithm, all participating nodes reach identical conclusions on the new cluster membership. Node Manager Node Manager assigns resource group ownership to nodes, based on group preference lists and node availability. Node Manager runs on each node and maintains a local list of nodes that belong to the cluster. Periodically, Node Manager sends messages, named heartbeats, to its counterparts running on other nodes in the

566

cluster to detect node failures. All nodes in the cluster must have exactly the same view of cluster membership. If a cluster node detects a communication failure with another cluster node, it transmits a multicast message to the entire cluster. This regroup event causes all members to verify their view of the current cluster membership. During the regroup event, the Cluster service prevents write operations to any disk devices common to all nodes in the cluster, until the membership stabilizes. If an instance of Node Manager on an individual node does not respond, the node is removed from the cluster, and its active resource groups are moved to another active node. To make this change, Node Manager identifies possible owners (nodes) that may own individual resources and the node on which a resource group prefers to run. Node Manager then selects the node and moves the resource group. In a two-node cluster, Node Manager simply moves resource groups from a failed node to the remaining node. In a cluster comprised of three or more nodes, Node Manager selectively distributes resource groups among the remaining nodes. Node Manager also acts as a gatekeeper, allowing joiner nodes into the cluster and processing requests to add or evict a node. Resource Monitor Resource Monitor verifies the health of each cluster resource by using callbacks to resource DLLs. Resource Monitors run a separate process and communicate with Cluster Server through RPCs. This protects the Cluster service from failures of individual cluster resources. Resource Monitors provide the communication interface between resource DLLs and the Cluster service. When the Cluster service must obtain data from a resource, Resource Monitor receives the request and forwards it to the appropriate resource DLL. Conversely, when a resource DLL must report its status or notify the Cluster service of an event, Resource Monitor forwards the information from the resource to the Cluster service. The Resource Monitor process (RESRCMON.EXE), is a child process of the Cluster service process (CLUSSVC.EXE). Resource Monitor loads resource DLLs that monitor cluster resources in its process space. Loading the resource DLLs in a process separate from the Cluster service process helps to isolate faults. Multiple Resource Monitors can be instantiated at the same time. Each Resource Monitor functions as an LRPC server for the Cluster service process. When the Cluster service receives a Cluster API call that requires talking to a resource DLL, it uses the LRPC interface to invoke the Resource Monitor RPC. To receive responses from Resource Monitor, the Cluster service creates one notification thread per Resource Monitor process. This notification thread invokes an RPC that is located permanently in Resource Monitor. The thread acquires notifications when they are generated. The thread is released only when Resource Monitor fails or when the thread is manually stopped by a shutdown command from the Cluster service. Resource Monitor does not maintain a persistent state on its own. It retains a limited, inmemory state of the resources, but all of its initial state information is supplied by the

567

Cluster service. Resource Monitor communicates with the resource DLLs through welldefined entry points that the DLLs must present. Resource Monitor completes the following operations on its own: It polls resource DLLs through the IsAlive and LooksAlive entry points, alternately checking failure events signaled by resource DLLs. To monitor pending timeouts of resource DLLs, it spawns timer threads that return ERROR_IO_PENDING from the DLL's Online or Offline entry points. It detects crashes of the Cluster service and shuts down the resources.

Its other actions occur as a result of operations requested by the Cluster service through the RPC interface. No hang detection is perfomed by the Cluster service. The Cluster service does, however, monitor crashes, and it restarts a monitor if it detects a process crash. The Cluster service and Resource Monitor process share a memory-mapped section backed by the paging file. The handle to the section is passed to Resource Monitor at Resource Monitor startup. Resource Monitor then duplicates the handle and records the entry point number and resource name into this section immediately before calling a resource DLL entry point. If Resource Monitor crashes, the Cluster service reads the shared section to detect the resource and the entry point that caused the crash. Backup/Restore Manager Backup/Restore Manager works with Failover Manager and Database Manager to back up or restore the quorum log file and all checkpoint files. The Cluster service uses the BackupClusterDatabase API for database backup. First, the BackupClusterDatabase API contacts the Failover Manager layer. The Failover Manager layer forwards the request to the node that currently owns the quorum resource. That node then invokes Database Manager, which makes a backup of the quorum log file and all checkpoint files. The Cluster service also registers itself at startup as a backup writer with Volume Shadow Copy service. When a backup client invokes the Volume Shadow Copy service to perform a system state backup, it also invokes the Cluster service, through a series of entry point calls, to perform the cluster database backup. The server code in the Cluster service invokes the Failover Manager to perform the backup, and the rest of the operation occurs via the BackupClusterDatabase API. The Cluster service uses the RestoreClusterDatabase API to restore the cluster database from a backup path. This API can only be invoked locally from one of the cluster nodes. When the RestoreClusterDatabase API is invoked, it stops the Cluster service, restores the cluster database from the backup, sets a registry value that contains the backup path, and then re-starts the Cluster service. On startup, the Cluster service detects that a restore is requested and restores the cluster database from the backup path to the quorum resource.

568

Cluster Failover
Failover can occur automatically because of an unplanned hardware or software failure, or it can occur as the result of manual initiation by an administrator. The algorithm and behavior in both situations is almost identical. However, in a manually initiated failover, resources are shut down in an orderly way; whereas in unplanned failovers, resources are shut down in a sudden and disruptive way (for example, the power goes out, or a crucial hardware component fails). When an entire node in a cluster fails, its resource groups transfer to one or more available nodes in the cluster. Automatic failover is similar to planned administrative reassignment of resource ownership. However, it is more complicated, because the orderly steps of a planned shutdown might be interrupted or might not have occurred at all. Therefore, extra steps are required to evaluate the state of the cluster at the time of failure. When your network experiences an automatic failover, it is important to determine what groups were running on the failed node and which nodes should take ownership of the various resource groups. All nodes in the cluster that are capable of hosting the resource groups negotiate for ownership. This negotiation is based on node capabilities, current load, application feedback, the node preference list, or the use of the AntiAffinityClassNames property, which is discussed in the Cluster-Specific Configurations. When negotiation of the resource group is completed, all nodes in the cluster update their databases and track which node owns the resource group. In clusters with more than two nodes, the node preference list for each resource group can specify a preferred server, plus one or more prioritized alternatives. This enables cascading failover, in which a resource group can survive multiple server failures, each time cascading, or failing over to the next server on its node preference list. An alternative to automatic failover, is commonly called N+I failover. This method establishes the node preference lists for all cluster groups. The node preference list identifies the standby cluster nodes, to which resources are moved at the first failover. The standby nodes are servers in the cluster that are mostly idle or that have workloads that can be easily preempted if a failed server's workload must be moved to the standby node. Cascading failover assumes that every other server in the cluster has some excess capacity and can absorb a portion of any other failed server's workload. N+I failover assumes, that the +I standby servers are the primary recipients of excess capacity.

Cluster Failback
When a node comes back online, Failover Manager can decide to move one or more resource groups back to the recovered node. This is referred to as failback. The properties of a resource group must have a preferred owner defined to fail back to a recovered or restarted node. Resource groups for which the recovered or restarted node is the preferred owner are moved from the current owner to the recovered or restarted node.

569

Failback properties of a resource group can include the hours of the day during which failback is allowed and a limit on the number of times failback is attempted. This enables the Cluster service to prevent failback of resource groups during peak processing times or to nodes that have not been correctly recovered or restarted.

Cluster Quorum
Each cluster has a special resource referred to as the quorum resource. A quorum resource can be any resource that does the following: Provides a means for arbitration leading to membership and cluster state decisions Provides physical storage to hold configuration information

A quorum log is a configuration database for the entire server cluster. The quorum log contains cluster configuration information, such as the servers that are part of the cluster, the resources that are installed in the cluster, and the state of those resources (for example, online or offline). The quorum is important in a cluster for the following two reasons: Consistency A cluster is made up of multiple physical servers acting as a single virtual server. It is critical that each of the physical servers has a consistent view of the cluster configuration. The quorum acts as the definitive repository for all configuration information relating to the cluster. If the Cluster service is unable to access and read the quorum, it cannot start. Tie-breaking The quorum is used as a tie-breaker to avoid split-cluster scenarios. A split-cluster scenario occurs when all network communication links between two or more cluster nodes fail. If this occurs, the cluster might be split into two or more partitions that cannot communicate with each other. The quorum ensures that cluster resources are brought online on one node only. It does this by allowing the partition that owns the quorum to continue, while the other partitions are evicted from the cluster.

Standard Quorum
As mentioned earlier in this section, the quorum is a configuration database for the Cluster service that is stored in the quorum log file. A standard quorum uses a quorum log file, located on a disk hosted in the shared storage array, which is accessible by all members of the cluster. Each member connects to the shared storage using SCSI or Fibre Channel. Storage is made up of external hard disks (usually configured as RAID disks) or a SAN, in which logical slices of the SAN are presented as physical disks.

570

Note: It is important that the quorum uses a physical disk resource, rather than a disk partition, because the entire physical disk resource is moved during failover. Furthermore, it is possible to configure server clusters to use the local hard disk on a server to store the quorum. This type of implementation, referred to as a lone wolf cluster, is supported only for testing and development purposes. Lone wolf clusters should not be used to cluster Exchange 2003 in a production environment because, being singular, they are incapable of providing failover.

Majority Node Set Quorums

From a server cluster perspective, a majority node set (MNS) quorum is a single quorum resource. The data is stored by default on the local disk of each node in the cluster. The MNS resource makes sure that the cluster configuration data, stored on the MNS resource, is consistent across different disks. The MNS implementation provided in Windows Server 2003 uses a directory on each node's local disk to store the quorum data. If the configuration of the cluster changes, that change is reflected across each node's local disk. The change is considered committed, or made persistent, only if the change is made to: (Number of nodes/2) + 1. The MNS quorum makes sure that most nodes have an up-to-date copy of the data. The Cluster service starts up and brings resources online only if a majority of the nodes that are configured as part of the cluster are up and are running the Cluster service. If the MNS quorum determines that a majority does not exist, the cluster is considered not to have quorum, and the Cluster service waits in a restart loop until more nodes try to join. When a majority or quorum of nodes is available, the Cluster service starts and brings the resources online. Because the up-to-date configuration is written to a majority of the nodes, regardless of node failures, the cluster always guarantees that it has the most current configuration at startup. If a cluster failure occurs, or if the cluster somehow enters a split-cluster scenario, all partitions that do not contain a majority of nodes are taken offline. This ensures that if there is a partition running that contains a majority of the nodes, it can safely start any resources that are not running on that partition, because it is the only partition in the cluster that is running resources. Because of the differences in the way the shared disk quorum clusters behave compared to MNS quorum clusters, you must consider carefully when deciding which model to use. For example, if you have only two nodes in your cluster, the MNS model is not recommended. In this instance, failure of one node leads to failure of the entire cluster, because a majority of nodes is impossible. Majority node set (MNS) quorums are available in Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition clusters. The only benefit that MNS clusters

571

provide for Exchange clusters is to eliminate the need for a dedicated disk in the shared storage array on which to store the quorum resource.

Cluster Resources
The Cluster service manages all resource objects using Resource Monitors and resource DLLs. The Resource Monitor interface provides a standard communication interface that enables the Cluster service to initiate resource management commands and obtain resource status data. The Resource Monitor obtains actual command functions and data through resource DLLs. The cluster Service uses resource DLLs to bring resources online, manage their interaction with other resources in the cluster, and monitor their health. To enable resource management, a resource DLL uses a few simple resource interfaces and properties. Resource Monitor loads a particular resource DLL in its address space, as privileged code running under the SYSTEM account. The SYSTEM account (that is, LocalSystem), is a security principal account that represents the operating system. The Cluster service, which runs under a user security context, uses the SYSTEM account to perform security functions within the operating system. When resources depend on the availability of other resources to function, these dependencies can be defined by the resource DLL. When a resource is dependent on other resources, the Cluster service brings the dependent resource online only after it brings the resources on which it depends online in the correct sequence. Resources are taken offline in a similar manner. The Cluster service takes resources offline only after any dependent resources are taken offline. This prevents introducing circular dependencies when loading resources. Each resource DLL can also define the type of computer and device connection required by the resource. For example, a disk resource may require ownership only by a node that is physically connected to the disk device. Local restart policies and desired actions during failover events can also be defined in the resource DLL.

Cluster Administration
Clusters are managed using Cluster Administrator. Cluster Administrator is a graphical administrator's tool that enables the Cluster.exe command line tool to perform maintenance, monitoring, and failover administration. Server clusters also provide an automation interface. This interface can be used to create custom scripting tools for administering cluster resources, nodes, and the cluster itself. Applications and administration tools, such as Cluster Administrator, can access this interface using RPCs, whether the tool is running on a node in the cluster or on an external computer.

572

Cluster Formation and Operation

When the Cluster service is installed and running on a server, the server can participate in a cluster. Cluster operations reduce single points of failure and enable high availability of clustered resources. The following sections briefly describe node behavior during cluster creation and operation.

Creating a Cluster
Server clusters include a cluster installation utility that is used to install the cluster software on a server and create a new cluster. To create a new cluster, the utility is run on the computer selected as the first member of the cluster. This first step defines the new cluster by establishing a cluster name, and creating the cluster database and initial cluster membership list. The next step in creating a cluster is to add the common data storage devices that will be available to all members of the cluster. This establishes the new cluster with a single node and its own local data storage devices and cluster common resources (generally disk or data storage and connection media resources). The final step in creating a cluster is to run the installation utility on each additional computer that will be a member of the cluster. As each new node is added to the cluster, it automatically receives a copy of the existing cluster database from the original member of the cluster. When a node joins or forms a cluster, the Cluster service updates the node's private copy of the configuration database.

Forming a Cluster
A server can form a cluster if it is running the Cluster service and cannot locate other nodes in the cluster. To form the cluster, a node must be able to acquire exclusive ownership of the quorum resource. When a cluster is formed, the first node in the cluster contains the cluster configuration database. As each additional node joins the cluster, it receives and maintains its own local copy of the cluster configuration database. The quorum resource stores the most current version of the configuration database as recovery logs. The logs contain node-independent cluster configuration and state data. During cluster operations, the Cluster service uses the quorum recovery logs to do the following: Guarantee that only one set of active nodes is allowed to form a cluster Enable a node to form a cluster only if it can gain control of the quorum resource

573

Allow a node to join or remain in an existing cluster only if it can communicate with the node that controls the quorum resource When a cluster is formed, each node in the cluster can be in one of three distinct states. These states are recorded by Event Processor (described below) and replicated by Event Log Manager to other nodes in the cluster. The three Cluster service states are as follows: Offline The node is not an active member of the cluster. The node and its Cluster service might or might not be running. Online The node is an active member of the cluster. It adheres to cluster database updates, contributes input into the quorum algorithm, maintains cluster network and storage heartbeats, and can own and run resource groups. Paused The node is an active member of the cluster. The node adheres to cluster database updates, contributes input into the quorum algorithm, and maintains network and storage heartbeats, but it cannot accept resource groups. It can support only those resource groups that it currently owns. The paused state enables maintenance to be performed. Online and paused states are treated as equivalent states by the majority of the server cluster components.

Joining a Cluster
To join an existing cluster, a server must be running the Cluster service, and it must successfully locate another node in the cluster. After finding another node in the cluster, the joining server must be authenticated for membership in the cluster and must receive a replicated copy of the cluster configuration database. The process of joining an existing cluster begins when Windows Service Control Manager starts the Cluster service on the node. During the startup process, the Cluster service configures and mounts the node's local data devices. It does not attempt to bring the common cluster data devices online as nodes, because the existing cluster might be using the devices. To locate other nodes, a discovery process is started. When the node discovers any member of the cluster, it performs an authentication sequence. The first cluster member authenticates the new node and returns a status of success if the new node is successfully authenticated. If authentication is not successful, as when a joining node is not recognized as a cluster member or has an invalid account password, the request to join the cluster is denied. After successful authentication, the first node online in the cluster checks the copy of the configuration database of the joining node. If it is out-of-date, the cluster node sends the joining server an updated copy of the database. After receiving the replicated database, the node joining the cluster can use it to find shared resources and bring them online as needed.

574

Leaving a Cluster
A node can leave a cluster when it shuts down or when the Cluster service is stopped. However, a node can also be evicted from a cluster when the node fails to perform cluster operations (such as failure to commit an update to the cluster configuration database). When a node leaves a cluster, as in a planned shutdown, it sends a ClusterExit message to all other members of the cluster, notifying them that it is leaving. The node does not wait for any responses and immediately proceeds to shut down resources and close all cluster connections. Because the remaining nodes receive this exit message, they do not perform the regroup process to reestablish cluster membership that occurs when a node unexpectedly fails or network communications stop.

Failure Detection
Failure detection and prevention are key benefits provided by server clusters. When a node or application in a cluster fails, server clusters can respond by restarting the failed application or distributing the work from the failed system to remaining nodes in the cluster. Server cluster failure detection and prevention include bi-directional failover, application failover, parallel recovery, and automatic failback. When the Cluster service detects failures of individual resources or an entire node, it dynamically moves and restarts application, data, and file resources on an available, healthy server in the cluster. This allows resources such as database, file shares, and applications to remain highly available to users and to client applications. Server clusters are designed with two different failure detection mechanisms: Heartbeats for detecting node failures Periodically, each node exchanges user datagram protocol-based messages with other nodes in the cluster over the private cluster network. These messages are referred to as the heartbeat. The heartbeat exchange enables each node to check the availability of other nodes and their resources. If a server fails to respond to a heartbeat exchange, the surviving servers initiate failover processes, including ownership arbitration for resources and applications owned by the failed server. Arbitration is performed using a challenge and defense protocol. The node that appears to have failed is given a time window to demonstrate, in any one of several ways, that it is still running correctly and can communicate with the surviving nodes. If the node is unable to respond, it is removed from the cluster. Failure to respond to a heartbeat message is caused by several events, such as computer failure, network interface failure, network failure, or even periods of unusually high activity. Typically, when all nodes are communicating, the Configuration Database Manager sends global configuration database updates to each node. When a heartbeat exchange failure occurs, Log Manager saves configuration database changes to the quorum resource. This ensures that remaining nodes can access the most recent cluster configuration and local node registry data during the recovery processes.

575

The failure detection algorithm is very conservative. If the cause of the heartbeat response failure is temporary, it is best to avoid the potential disruption a failover might cause. However, there is no way to know whether the node will respond in another millisecond, or if it suffered a catastrophic failure. Therefore, a failover is initiated after a timeout period. Resource Monitor and resource DLLs for detecting resource failures Failover Manager and Resource Monitor work together to detect and recover from resource failures. Resource Monitors keep track of resource status by using the resource DLLs to periodically poll resources. Polling involves two steps, a cursory LooksAlive query and a longer, more definitive, IsAlive query. When Resource Monitor detects a resource failure, it notifies Failover Manager and continues to monitor the resource. Failover Manager maintains resources and resource group status. It also performs recovery when a resource fails and invokes Resource Monitors in response to user actions or failures. After a resource failure is detected, Failover Manager performs recovery actions that include restarting a resource and its dependent resources, or moving the entire resource group to another node. The recovery action that is taken is determined by resource and resource group properties, in addition to node availability. During failover, the resource group is treated as the unit of failover. This ensures that resource dependencies are correctly recovered. When a resource recovers from a failure, Resource Monitor notifies Failover Manager. Failover Manager then performs automatic failback of the resource group, based on the configuration of the resource group failback properties.

Exchange Virtual Servers

Exchange Virtual Server is a clustered Exchange installation. When Exchange is installed on a Windows Server 2003 cluster, it is configured as an Exchange Virtual Server that can be passed between cluster nodes transparently to Exchange clients. When you install Exchange on a cluster node, the Exchange Setup program copies the program files to the local disk of the cluster node. In a cluster with two nodes, such as Node A and Node B, Setup copies the Exchange program files to the hard disk of Node A. You then run Setup a second time to install the Exchange program files on the local hard disk of the second node. After the Exchange program files are copied to the hard disks of each node, you then configure a resource group for the Exchange resources. As mentioned earlier, a resource group is defined as a logical container that holds resources for an instance of Exchange Virtual Server. This Exchange Virtual Server instance has many of the same resources that physical Exchange servers have, such as:

576

A network name An IP address Storage (SCSI or Fibre Channel)

After you create a minimum of the above Exchange Virtual Server resources, you must create a System Attendant resource. System Attendant creates the additional resources that compose an Exchange Virtual Server. These resources can be taken offline, which mimics the stopping of the service, or brought online, which mimics the starting of the service. You can also change the current resource owner (the cluster node). For example, you can configure Node B to own and run this resource instead of Node A. The System Attendant resource is always created manually. Other Exchange service-related resources are automatically created after you create the System Attendant resource. On completion, these changes are written to the Microsoft Active Directory directory service and an object for this Exchange-based server is listed in the Servers container of your administrative group. Note: Exchange Server 2003 introduced several security-related changes that harden the security model compared to that of Exchange 2000 Server. For example, when you create an Exchange Server 2003 virtual server in a cluster environment, IMAP4 and the POP3 cluster resources are not created by default. If you want to use these services on a cluster, you must start the appropriate service on the cluster node, and then manually create the resource. For more information, see Microsoft Knowledge Base article 824127, "HOW TO: Create an IMAP4 or a POP3 Cluster Resource on an Exchange Server 2003 Virtual Server." An Exchange Virtual Server is a collection of Exchange resources. Each resource has properties, such as resource dependencies, possible owners, and retry values. Each resource in an Exchange Virtual Server represents a different component of Exchange.

Exchange Components in a Cluster

Components and virtual servers that run inside a Windows Server 2003 cluster support active/active or active/passive functionality, or both. The Exchange-specific resources available for Windows Server 2003 clusters are listed in the following table.

577 Exchange Server 2003 Components in a Server Cluster Component Microsoft Exchange System Attendant service Functionality Active/Active Notes Multiple virtual servers per node in clusters of 2 or fewer nodes. Clusters with more than 2 nodes only support active/passive System Attendant resources. Maximum of four storage groups per node. One instance per cluster; always owned by first Exchange Virtual Server created in a cluster.

Microsoft Exchange Information Store service Message Transfer Agent

Active/Active Active/Passive

Routing Engine POP3

Active/Active Active/Active Multiple virtual servers per node. Must be manually created by administrator. Multiple virtual servers per node. Must be manually created by administrator. Multiple virtual servers per node. Multiple virtual servers per node.

IMAP4

Active/Active

SMTP HTTP Microsoft Search NNTP

Active/Active Active/Active Active/Active Not Supported

Internet Information Service (IIS) Network News Transfer Protocol (NNTP) component still required for installation of Exchange.

Exchange Connector for Novell GroupWise Exchange Connector for Lotus Notes

Not Supported Not Supported

578

Component Microsoft Exchange Event

Functionality Not Supported

Notes

Active/Active Clusters
Exchange 2003 supports active/active clustering for two-node clusters. Clusters with more than two nodes must use active/passive clustering. In an active/active Exchange cluster, there are multiple Exchange Virtual Servers that can be moved, with certain restrictions, between the different nodes that belong to the cluster and can simultaneously run on one node. In active/active clusters, applications and resources can exist in multiple instances in a cluster. Therefore, both nodes can actively service clients. In Exchange 2003 active/active clusters, the number of Exchange Virtual Servers in a cluster is equal to or greater than the number of physical nodes in the cluster. Active/active Exchange clusters can be created only in clusters comprised of two or fewer nodes. If you have more than two nodes in your cluster, you must use the active/passive cluster model. In most cases, each Exchange Virtual Server in the cluster runs on a separate node. If hardware fails or a node is taken offline, the other node detects the change and takes actions according to configured failover policies. Generally, this means that the remaining node assumes ownership of the Exchange Virtual Server that was running on the first node. In a two-node cluster (for example, Node A and Node B), when Node A is offline, Node B assumes ownership of the Exchange Virtual Server. Node B then has ownership of both shared disk systems, both IP addresses, both network names, and all other Exchange resources in the cluster. When Node A is back online, failback action might or might not be taken, depending on the configured failback policies. Although active/active clusters are supported, you should use active/passive Exchange clusters for the following reasons: Scalability In an active/active Exchange cluster, each physical node cannot have more than 1,900 simultaneous MAPI connections, or consistently use more than 40 percent of the overall available CPU time. VM Fragmentation Active/active clusters are more prone to virtual memory fragmentation than active/passive clusters and non-clustered Exchange servers. This is because in the active/active cluster model, multiple instances of Extensible Storage Engine (ESE) run inside the same STORE.EXE process. Performance When failover occurs in an active/active Exchange cluster, the remaining node owns more than one Exchange Virtual Server. This causes performance degradation for users of both Exchange Virtual Servers until the offline node resumes its workload.

579

For more information about clustering with Windows Server 2003 and Exchange 2003, see Using Clustering with Exchange 2003: An Example.

Active/Passive Clusters
In an active/passive cluster, clients connect to an Exchange Virtual Server that is currently owned by one node of the cluster (for example, Node A). The node has control over the shared disk system that contains the Exchange databases. If Node A experiences a hardware failure or otherwise goes offline, Node B detects this failure and takes ownership of Exchange Virtual Server and all its associated resources. In the active/passive cluster model, applications run as a single instance in a cluster. This means that one node typically sits idle (passive) until a failover occurs. In the context of Exchange 2003 clusters, active/passive clustering indicates that the number of Exchange Virtual Servers in the cluster is fewer than the number of physical nodes in the cluster. An example of the active/passive cluster model is shown in the following figure. Four-node active/passive Exchange 2003 server cluster

Active/passive is the strongly preferred clustering model for Exchange 2003. Active/passive cluster configurations are highly scaleable and have less administrative overhead than active/active clusters for several reasons: Active/active clusters are limited to 1,900 simultaneous MAPI client connections per node.

580

Active/active clusters must be continuously monitored to make sure that the STORE.EXE process does not exceed 40 percent of the overall available CPU time on each node. Active/active clusters are more prone to virtual memory fragmentation because multiple instances of ESE run in the same STORE.EXE process. Active/passive Exchange clusters, regardless of their size, must include at least one passive node. In addition, at any given time, each node must only run one Exchange Virtual Server.

Resource Dependencies
As shown in the figure below, Exchange-related resources are directly dependant on the System Attendant resource. The System Attendant resource is in turn dependent on the Physical Disk, and Network Name resources, and the Network Name resource is dependent on the IP Address resource. In the case where an Exchange Virtual Server includes multiple Physical Disk resources, the System Attendant resource must have a dependency on all of them.

Microsoft Exchange System Attendant Service

The default dependencies shown in the following figure are created when Microsoft Exchange System Attendant service is created. System Attendant is the fundamental resource that controls the creation and deletion of all resources in Exchange Virtual Server. Exchange resource dependencies in Exchange Virtual Server

581

These resources are created when you create the System Attendant resource. To delete the server and its object from Active Directory, you remove Exchange Virtual Server using Cluster Administrator. The IsAlive call to System Attendant checks Service Control Manager to obtain the immediate state of System Attendant.

Microsoft Exchange Information Store Service

When the Microsoft Exchange Information Store service is brought online, the service (STORE.exe) starts and begins to mount the storage groups. When all the storage groups are mounted, and the store has processed the existing transaction logs, the resource is considered to be online. The IsAlive call to the Microsoft Exchange Information Store service sends an RPC call to the STORE.exe process. On the store process side, the check only verifies that the virtual server name exists in the list of active virtual servers.

Message Transfer Agent

The message transfer agent (MTA) resource is an active/passive resource. There can be only one MTA per cluster. The MTA is created in the first Exchange Virtual Server in a cluster and cannot be moved to a different Exchange Virtual Server. For this reason, the first Exchange Virtual Server that you create in a cluster is also the last Exchange Virtual Server that can be removed from the cluster. Although the MTA is an active/passive resource, it serves all virtual servers in the cluster while it is online. The IsAlive call to the message transfer agent checks Service Control Manager to obtain the immediate state of the MTA.

Protocols
The IsAlive call acts the same way for all protocols. EXRES.DLL opens a TCP port to the protocol by using the bindings that are provided from the Internet Information Service (IIS) metabase. It waits for a response in the form of a banner. If the start of the banner matches the expected value, the resource is considered to be online. If the banner is not returned before the time-out period, the Cluster service determines that the protocol virtual server is unavailable, and the IsAlive call is unsuccessful. None of the protocols may be set to reject all connections from all servers, or the protocol virtual server will reject IsAlive calls from itself. Because of this, each protocol virtual server must accept connections from its own IP address. For the HTTP protocol, EXRES.DLL sends a WebDAV Track command to obtain a response. When an Exchange Virtual Server is taken offline, all instances of the SMTP protocol virtual server on the node are briefly stopped and restarted to make sure that the store driver is correctly registered. This means that the SMTP resources of all Exchange Virtual Servers on

582

the node quickly go offline and restart. The SMTP resource does not restart automatically if the do not restart option is selected in its properties.

Microsoft Search
The MSSearch resource provides content indexing for Exchange Virtual Server. The IsAlive call to the MSSearch process returns a pointer to the data structure for the database that is being indexed. If the pointer is valid, the resource is determined to be working correctly. To re-create the MSSearch resource after it is deleted, you must delete and then re-create the Microsoft Exchange Information Store service resource for that Exchange Virtual Server. For more information, see Microsoft Knowledge Base article 830189, "Exchange Server 2003 computer cannot bring the Microsoft Search resource online."

Exchange Cluster Interaction

Exchange 2003 is cluster-aware and provides its own cluster resource DLL, named EXRES.DLL, for communication and interaction with the Windows Cluster service. The Windows Cluster service communicates through Resource Monitor to EXRES.DLL, and EXRES.DLL then communicates with the Exchange components. EXRES.DLL translates the cluster actions into actions for Exchange-related services. EXRES.DLL also monitors the stopping of these resources and notifies the Cluster service if the operation is unsuccessful. The following figure illustrates the relationship between EXRES.DLL and the Cluster service. ExRes.dll interaction with Windows Cluster Service

583

In a cluster, the Cluster service is responsible for starting and stopping Exchange services through EXRES.DLL. Because of this, an administrator should not stop a service from the command-line, the Windows Services snap-in, a Resource Kit tool, or a third-party application. When you stop a service outside of the Cluster, the IsAlive call to that service fails, causing the Cluster service to attempt a restart of the stopped service. The IsAlive function returns the last value that was pooled from the resource health-monitoring thread. The LooksAlive function has the same implementation as IsAlive. The LooksAlive function is not called, because the EXRES.DLL provides resource-failure event handles to the cluster Resource Monitor that indicates when a resource fails. The health-monitoring thread checks resources every ten seconds. This resource check cannot be configured. EXCLUADM.DLL provides the interface associated with Exchange and cluster-specific wizards.

ExchangeOpen/ExchangeClose Functions
The ExchangeOpen and ExchangeClose functions are called whenever the Exchange resources are moved to the current node. Inside the ExchangeOpen functions, memory is initialized or allocated for the basic information of the resource. These functions also handle the loading and unloading of DLL files that are used by the Resource DLL. This process is controlled by reference counters.

ExchangeOnline and ExchangeOffline Functions

The ExchangeOnline and ExchangeOffline functions create new OnlineWrapperThread and OfflineWrapperThread worker threads and immediately return an ERROR_IO_PENDING to the cluster Resource Monitor. When the wrapper thread returns a failure to Resource Monitor, Resource Monitor tries to restart the resource two additional times. During these restart attempts, the ExchangeOnline function determines if the previous online/offline thread is returned. If the online/offline thread is not returned, the ExchangeOnline function restarts. For the OfflineWrapperThread, if the ExchangeOffline thread does not return in the PendingTimeOut limit for the Store, System Attendant, and MTA resources, Resource Monitor ends the corresponding process. To prevent situations in which RPCs hang, these two worker threads create the real online/offline thread. The wrapper threads act as monitors for the online/offline thread and use timers to monitor the operation of the online/offline thread. If the online/offline thread does not return in the PendingTimeOut value that was set in Cluster Administrator, the wrapper thread determines that the operation is unsuccessful, and sets the resource's state as failed. It then returns an error. The only exceptions to this behavior are for upgrade operations or for store resource online operations. In these two cases, the wrapper thread waits for an upgrade to complete or for a store resource to go online without timing out.

584

The ExchangeOnlineThread and ExchangeOfflineThread service the following Exchange resources: Micrsoft Exchange System Attendant service, Microsoft Exchange Information Store service, and Routing Each of these resources starts the service (if it is not already started), and then makes RPC calls to each of the services, instructing them to start or stop the corresponding Exchange Virtual Server. Protocol Resources Protocol resources set the command bit in the IIS metabase, and then start the service, if it has not already started. The corresponding service picks up the command and starts or stops the virtual server. The only exception to this is the SMTP virtual server. In this case, the whole SMTP service must be stopped when a virtual server instance is taken offline. The IsAlive function checks for other virtual servers running on the same physical computer, detects that the underlying SMTP service is stopped, and then restarts the virtual server.

ExchangeIsAlive and ExchangeLooksAlive

The ExchangeOnline function returns an event handle to Resource Monitor, and Resource Monitor then stops calling the ExchangeLooksAlive function. Instead, the Resource Monitor calls the ExchangeIsAlive function at intervals set in the Cluster Administrator Looks Alive polling interval. Whenever a resource is online, EXRES.DLL creates two threads to monitor the status of that resource. The first thread, named ExchangeIsAliveMonitor, checks the status of the resource every ten seconds by waking the second thread, named ExchangeCheckIsAliveWrapper. ExchangeCheckIsAliveWrapper performs the actual IsAlive checking. If the ExchangeCheckIsAliveWrapper thread does not return in the PendingTimeOut limit, or if the IsAlive check is unsuccessful, the ExchangeIsAliveMonitor thread signals a failure event for the particular resource to Resource Monitor. The ExchangeIsAlive function returns the status of the last IsAlive check.

ExchangeTerminate
This function ends the existing ExchangeIsAliveMonitor thread. For the Exchange store, System Attendant, and MTA resources, it also performs the corresponding offline procedure to make sure that the database is dismounted. If the offline procedure does not complete successfully in the PendingTimeOut limit, EXRES.DLL also terminates the corresponding process.

Creating Resources
The user creates a resource first, and then creates a call to EXCLUADM.DLL, prompting for information. EXCLUADM.DLL obtains the required information for the resource and passes it to the Cluster service. Resource Monitor creates a call to the ExchangeResourceControl

585

function in EXRES.DLL. This call contains the information that was passed from EXCLUADM.DLL and Clusctl_Resource_Set_Private_Properties as the control code. ExchangeSetPrivateResProperties is used to handle this control code. It first saves the information to the cluster database under the Parameters registry key for that resource, and then makes a call to EXSETDATA.DLL to have EXSETDATA.DLL create objects in Acitve Directory. In some cases, a problem might occur and some configuration information might be modified in Exchange System Manager, without synchronizing the changes with the cluster database.

Cluster-Specific Configurations
The following sections describe configuration changes that must be made to support operations of certain components when running in an Exchange cluster. When Exchange is installed in a clustered environment, you must perform some common Exchange tasks differently than you would for an Exchange server that is installed in a non-clustered environment.

Exchange MTA
By default, an Exchange 2003 server monitors the MTA service. In a cluster environment, MTA runs only on one of the physical nodes (computers). As a result, the monitoring process will report that any nodes not running the MTA service are in an error state. This, in turn, can cause problems if Exchange 2003 is installed in a cluster with two or more Exchange Virtual Servers. To prevent the monitoring process from incorrectly reporting that Exchange Virtual Servers that are not running the MTA service are in an error state, you should disable MTA monitoring on the second Exchange Virtual Server (and if applicable, any other additional Exchange Virtual Servers) of a cluster. For detailed steps, see How to Disable MTA Monitoring on an Exchange Virtual Server. Note: You do not need to disable MTA monitoring on the first Exchange Virtual Server of a cluster.

IIS SMTP Logging

IIS SMTP protocol virtual servers create and populate log files that are used to gather statistical data on server usage. SMTP logging is not enabled by default, because it reduces Exchange performance. When enabled, IIS creates log files on the system drive of the local

586

computer (such as C:\Windows\System32\Logfiles, where C is the drive letter for your system drive). To reliably configure IIS SMTP logging, you must specify a folder on a shared disk. For detailed instructions, see How to Enable SMTP Logging and Log the Files to a Shared Disk.

AntiAffinityClassNames
One of the limitations of Windows 2000-based server clusters is that they have no mechanism for a conditional failover. For example, you cannot configure an Exchange Virtual Server to move to one node when one failure occurs and to a different node when another failure occurs. Nor can you configure an Exchange Virtual Server to fail over to a second node in the event that the first node is too busy. In Windows Server 2003 clusters, this limitation is addressed with a new cluster group property named AntiAffinityClassNames. The value for this property is any arbitrary string. However, this string is often program-specific. For example, Exchange 2003 sets this value to Microsoft Exchange Virtual Server. AntiAffinityClassNames are used to designate a node as a possible owner for a particular resource group in a cluster containing three or more nodes. In a Windows Server 2003 cluster, if a resource failure occurs that affects the resource group, Failover Manager checks the value for AntiAffinityClassNames. For example, when an Exchange Virtual Server resource fails, the cluster failover manager determines if resource groups on any one of the other nodes, designated as possible owners of the Exchange Virtual Server, have Microsoft Exchange Virtual Server set as the value for the AntiAffinityClassNames property. Only nodes that currently contain an Exchange Virtual Server have this value set. Therefore, a node without this value is the best possible destination for the group with the failed resource. The following scenarios demonstrate how the AntiAffinityClassNames property can be used: The property can be used in an N+1 Exchange server cluster. In this case, Exchange should set up each group that supports a partition with the AntiAffinityClassNames property set to an Exchange-specific value (the same value for each group). If there is a failure, the failover manager can attempt to keep the partitions apart by selecting nodes that do not contain groups with the same AntiAffinityClassNames value of Exchange Virtual Server. The property can be used in a server consolidation in which there are multiple programs that should be kept apart. In these cases, the groups that represent the various programs should be manually modified with the same value in the AntiAffinityClassNames property. This property can only be configured using the CLUSTER.EXE command-line tool. An example of the proper syntax for the example that is listed in the first preceding scenario is:
cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual Server"

587

This command creates the following registry key: Location Value Type Value Data

HKLM\Cluster\Groups\<Guid>\ AntiAffinityClassNames REG_MULTI_SZ Microsoft Exchange Virtual Server

After this property is set, failover and failback policies are configured using the Best Possible option in Cluster Administrator, instead of specifying specific nodes for a policy. For more information, see Microsoft Knowledge Base article 299631, "Failover Behavior on Clusters of Three or More Nodes."

MAPI Public Stores

Prior to Service Pack 1, Exchange 2003 clusters can only accommodate one public MAPI information store, also referred to as a public folder database, per cluster. This design prevents problems if the cluster fails over to another server in an active/active cluster. Because Exchange 2003 must run in an active/passive configuration whenever there are more than two nodes present in the cluster, you cannot encounter a scenario in which a single Store.exe process must cope with multiple public MAPI information stores from the same TLH. Therefore, with Exchange 2003 Service Pack 1, the existing public MAPI information store limitation in the cluster is removed. Installations running SP1 or later are restricted to one public MAPI information store per Exchange Virtual Server (the same restriction that is imposed on stand-alone Exchange 2003 servers).

Eseutil
You must give special consideration when you run the Eseutil database integrity utility with the /CC switch. This switch is used to perform a hard recovery of an Exchange information store. Hard recovery is the process through which you apply transaction logs and database patch files to a database that has been restored from online backup. For more information, see Microsoft Knowledge Base article 266689, "XADM: The 'ESEUTIL /CC' Command Does Not Work on Cluster Server."

Installing Updates
Before installing any updates on your Exchange cluster nodes, read the README file that is included with the service pack, hotfix, or update. In most cases, the passive node of the cluster is updated first. Exchange Virtual Servers are then moved to the passive node, and

588

then the other node is updated. You should never install any update on more than one node at a time.

How to Disable MTA Monitoring on an Exchange Virtual Server

By default, an Exchange 2003 server monitors the MTA service. In a cluster environment, MTA runs only on one of the physical nodes (computers). To prevent the monitoring process from incorrectly reporting that Exchange Virtual Servers that are not running the MTA service are in an error state, disable MTA monitoring on the second Exchange Virtual Server (and if applicable, any other additional Exchange Virtual Servers) of a cluster. You do not have to disable MTA monitoring on the first Exchange Virtual Server of a cluster. This procedure describes how to disable MTA monitoring on an Exchange Virtual Server.

Before You Begin

Before you start managing your Exchange cluster, you may want to review what constitutes an Exchange Virtual Server and its associated Exchange resources. You may also want to become more familiar with Cluster Administratorthe primary tool used to configure and manage clusters. Note: Before performing the cluster administration tasks outlined in this chapter, you must be familiar with the clustering concepts described in "Checklist: Preparation for installing a cluster" in the Microsoft Windows Server 2003 Enterprise Edition Online Help and in the Windows Server 2003 Technical Reference. Also, make sure that you are familiar with "Using Server Clustering" in Planning an Exchange Server 2003 Messaging System and with "Deploying Exchange 2003 in a Cluster" in the Exchange Server 2003 Deployment Guide.

Procedure
To disable MTA monitoring on an Exchange Virtual Server 1. In Exchange System Manager, in the console tree, expand Servers, right-click the appropriate Exchange Virtual Server, and then click Properties. 2. In the <Server Name> Properties dialog box, click the Monitoring tab. 3. On the Monitoring tab, select Default Microsoft Exchange Services from the

589

list of services, and then click Details. 4. In the Default Microsoft Exchange Services dialog box, select Microsoft Exchange MTA Stacks, and then click Remove. 5. Click OK two times.

How to Enable SMTP Logging and Log the Files to a Shared Disk
If you want to gather statistical data about server usage, you can enable logging of the SMTP resource. However, be aware that enabling SMTP logging reduces Exchange performance. Unless you are troubleshooting or need statistical data, disable logging, which is the default setting. This procedure describes how to enable SMTP logging and log the files to a shared disk.

Before You Begin

When enabled, Internet Information Services (IIS) creates SMTP log files on the system drive of the local computer (for example, C:\Winnt\System32\Logfiles, where C is the location of your Windows Server 2003 or Windows 2000 installation). To reliably configure SMTP logging in a clustered environment, you must change the default location of the log files (that is, the local computer) to a folder on a shared disk.

Procedure
To enable SMTP logging and log the files to a shared disk 1. In Exchange System Manager, in the console tree, expand Servers, and then expand the server on which you want to enable IIS logging for SMTP. 2. In the console tree, expand Protocols, and then expand SMTP. 3. In the console tree, right-click Default SMTP Virtual Server, and then click Properties. 4. In the Default SMTP Virtual Server Properties dialog box, on the General tab, click Enable logging, and then click Properties. 5. In the Extended Logging Properties dialog box, on the General Properties tab, in Log file directory, change the SMTP log file location to a folder on a shared

590

disk. 6. Click OK two times.

How to Create an HTTP Virtual Server in Exchange System Manager

When you create an Exchange Virtual Server, during the creation of the Exchange System Attendant resource, Exchange creates an HTTP virtual server resource. This topic explains how to use Exchange System Manager to create an HTTP virtual server.

Before You Begin

The following steps must be repeated for each Exchange Virtual Server in the cluster.

Procedure
To create an HTTP virtual server in Exchange System Manager 1. Open Exchange System Manager. 2. In the console tree, expand Servers, expand the server that you want to configure as a back-end server, and then expand Protocols. 3. Right-click HTTP, point to New, and then click HTTP Virtual Server. 4. In Properties, in the Name box, type the name of your front-end server. 5. Next to the IP Address list, click Advanced. 6. In Advanced, under Identities, select the default entry, and then click Modify. 7. In Identification, in the IP address list, select the IP address of this Exchange Virtual Server (the back-end server). This IP address must match the IP address resource value you previously configured for the back-end server. The Identification dialog box

591

8. In the Host name box, type the host header of the front-end server. This is the name by which the clients access the front-end server. The host header for the Exchange Virtual Server must map to the host header on the front-end server. Note: Client requests to the front-end server use a specific host, such as http://mail.contoso.com. A virtual server on the front-end must have the "mail.contoso.com" host header configured. The front-end server then proxies the request to the back-end server, which must also have the host header configured on a virtual server. 9. Verify that TCP port is set to 80, and then click OK. 10. In Advanced, if you want to add an additional identity, click Add, and perform Steps 6 through 8 again. Note: Consider adding several identities to the virtual server that list all the ways that a user might access the front-end server. For example, if a front-end server is used both internally and externally, consider listing both a host name and a fully qualified domain name, such as "mail" for internal access and "mail.contoso.com" for external access. 11. In Advanced, click OK twice to create the new HTTP virtual server.

592

How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster
When you create an Exchange Virtual Server, during the creation of the Exchange System Attendant resource, Exchange creates an HTTP virtual server resource. This topic explains how to create virtual directories for an Exchange Virtual Server in a Windows Server cluster. Before you can create a virtual directory, you must create an HTTP virtual server in Exchange System Manager. For detailed instructions, see How to Create an HTTP Virtual Server in Exchange System Manager. After you create the HTTP virtual server, you must add virtual directories to the back-end server(s) that match the virtual directories configured on the frontend server. A typical Exchange installation contains virtual directories called Exchange and Public. In Exchange System Manager, virtual directories of HTTP virtual servers appear as child objects of the HTTP virtual server.

Before You Begin

For any virtual directories that point to mailboxes, ensure that the SMTP domain selected on the virtual directory Properties matches the SMTP domain of users who will be using that front-end server. If the correct domain is not selected, users of that domain will not be able to use that virtual server to log on. The list of domains is compiled from the domains of the SMTP addresses in the Exchange organization's recipient policies. If you have more than one recipient policy for the same domain, you will see duplicates. In this case, it does not matter which one you select.

Procedure
To create virtual directories for an Exchange Virtual Server in a Windows Server cluster 1. Open Exchange System Manager 2. In the console tree, expand Servers, expand the server that you want to configure as a back-end server, expand Protocols, and then expand HTTP. 3. Right-click <HTTP Virtual Server Name>, point to New, and then click Virtual Directory. 4. In Properties, in the Name box, type Exchange. 5. Under Exchange Path, the Mailboxes for SMTP domain option is selected by default. Keep this setting, because users use the Exchange virtual directory to

593

access their Exchange mailboxes. Click OK to create the first virtual directory. 6. In the console tree, right-click <HTTP Virtual Server Name> again, point to New, and then click Virtual Directory. 7. In Properties, in the Name box, type Public. 8. Under Exchange Path, click Public folder, and then click Modify. 9. In Public Folder Selection, double-click Public Folders. After a few seconds, Exchange resolves the public folder's server name and appends it to the name of the Public Folders container. The Public Folder Selection dialog box

10. Click OK to close the Public Folder Selection dialog box. 11. In Properties, click OK. 12. If there are additional virtual directories configured on your front-end server, you must also create those virtual directories. To create additional virtual directories, repeat Steps 5 through 10 for each virtual directory.

For More Information

For more information about creating virtual directories, see "Configure the Server's Virtual Directory" in Exchange 2003 Help.

594

How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster
For the Cluster service to manage each HTTP virtual server, you must create a new HTTP server resource for each HTTP virtual server. This topic explains how to create an HTTP virtual server resource for an Exchange Virtual Server in a Windows Server cluster.

Before You Begin

You must perform the following steps for each Exchange Virtual Server to which you have added a new HTTP virtual server.

Procedure
To create an HTTP virtual server resource for an Exchange Virtual Server in a Windows Server cluster 1. Open Cluster Administrator. 2. Right-click the Exchange Virtual Server, point to New, and then click Resource. 3. The New Resource Wizard starts. In the Name box, type Exchange HTTP Virtual Server - (<EVSName>), where EVSName is the name of the front-end server. 4. In the Resource type list, click Microsoft Exchange HTTP Server Instance. Verify that the Group list contains the name of your Exchange Virtual Server, and then click Next. 5. In Possible Owners, under Possible owners, verify that all nodes are displayed, and then click Next. 6. In Dependencies, add the Exchange System Attendant resource to the Resource dependencies box, and then click Next. 7. In Virtual Server Instance, in the Server Instance list, select the newly created HTTP virtual server for the resource, and then click Finish. 8. In Cluster Administrator, right-click the HTTP virtual server instances you just created, and then click Bring Online.

595

Copyright
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. 2006 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync, ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN, Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile, Windows NT, and Windows Server System are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.