Exchange Server TechCenter

MAPI-based connectors consist of a variety of components that enable seamless integration with Exchange Server 2003. These include configuration objects in Active Directory that hold connector-specific settings and the actual connector applications that perform message conversion and transfer. MAPI-based connectors also come with Microsoft Management Console (MMC) snap-ins, which integrate with Exchange System Manager so that you can perform system configuration tasks using a unified user interface.

MAPI-based connectors consist of the following components:

• Connector service   Typically, MAPI-based connectors are implemented as Microsoft Windows services that are running directly on the Exchange Server 2003 bridgehead server. Therefore, they start automatically when the server starts and run in their own security context. In Exchange Server 2003, all services, including the services of MAPI-based connectors, use the LocalSystem account, as discussed in Exchange Server 2003 Services Dependencies.
  

  Note:

  Connector components can run directly on a server running Exchange Server 2003 or on a separate computer that communicates with Exchange Server 2003 over the network. The non-Exchange messaging system is usually accessed over the computer network, although it might improve connector performance if the non-Exchange messaging system is local to the connector server. For example, it is possible to run both Exchange Server 2003 and Lotus Domino on the same server.

• Conversion DLLs   MAPI-based connectors can register conversion DLLs with the Exchange Server 2003 framework for message translation, so that the appropriate translation code is called when the connector converts inbound or outbound messages. These DLLs must be registered in the registry, under the HKEY_LOCAL_MACHINE\Software\Classes\MAPI Conversions key. A subkey must then exist for each conversion DLL. The DLL subkey name must be the name of the DLL file. These DLLs must be installed in the \System32 directory of the bridgehead server. Each DLL key contains a subkey for each entry point in a conversion DLL, which the conversion engine uses to perform the conversion.
  

  Note:
  Conversion DLLs are optional components. The code to perform message conversions can also be embedded directly in a MAPI-based connector, in which case conversion DLLs are not used. For example, Connector for Lotus Notes and Connector for Novell GroupWise do not rely on conversion DLLs. The mechanisms that these connectors rely on to perform message conversions are covered in later sections.

• Proxy address generation DLL   Proxy addresses are non-Exchange addresses that the recipient update service assigns to Exchange recipient objects in Active Directory. This enables non-Exchange users to send Exchange users e-mail messages and vice versa. For example, the Exchange user Ted Bremer might have a NOTES proxy e-mail address of Ted@Exchange. A Lotus Notes user can then use this e-mail address to send Ted a message. In a Lotus Notes environment, Ted appears to be a user in a Lotus Notes foreign domain called Exchange, which is associated with Connector for Lotus Notes. Accordingly, Lotus Notes routes the message addressed to Ted@Exchange to Connector for Lotus Notes. When Connector for Lotus Notes retrieves the message, the connector performs address translation and replaces the Lotus Notes (proxy) address of the Exchange user with the actual Exchange address (the X.500 address of the user, as specified in the legacyExchangeDN attribute). Similarly, Connector for Lotus Notes replaces Ted's Exchange address information with his Lotus Notes proxy address information in all outbound messages to Lotus Notes. The native Exchange Server 2003 address format is SMTP.
  

  Note:
  Exchange users typically appear in non-Exchange messaging systems as regular recipients who exist in the non-Exchange messaging systems.

  To enable recipient update service to generate proxy addresses in the correct format, MAPI-based connectors must install an appropriate proxy address generation DLL on the server running Exchange Server 2003. Proxy address DLLs reside in subdirectories that correspond to address types and computer processor types, under \Program Files\Exchsrvr\Address. This subdirectory is shared for network access (share name: \\<server name>\Address), so that the recipient update service can access the DLLs, even if the messaging connector is installed on another server running Exchange Server. You can read more about the recipient update service in Exchange Server 2003 and Active Directory.
  The following figure illustrates an example of proxy addresses that the recipient update service assigned to an Exchange user.
  

  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 organization. For example, there cannot be two Exchange recipients with a NOTES proxy address of Ted@Contoso.

• addrType object   Placing a proxy address generation DLL in a subdirectory under \Program Files\Exchsrvr\Address on a server running Exchange Server 2003 does not cause recipient update service to generate proxy addresses for a particular address type. To enable an address type, the connector must also register the address type it supports in an addrType object in Active Directory. All addrType objects reside in the configuration directory partition of Active Directory, in the Address-Types container. You can view the content of this container using ADSI Edit. You can also view this container in Active Directory Sites and Services when you select the option Show Services Node on the View menu to display the services node. The path to the Address-Types container is \Services\Microsoft Exchange\<name of Exchange organization>\Addressing\Address-Types. By default, addrType objects exist for CCMAIL, GWISE, MS, NOTES, SMTP, and X400.
  The following table lists the important attributes of addrType objects.
  

  Attributes of addrType objects

  Attributes	Description
  Common-Name	The common name of the Address-Type that is used to build the distinguished name of the object in Active Directory.
  File-Version	The version number of the proxy address generator DLL file.
  proxyGeneratorDLL	The name of the proxy address generator DLL used for this address type. For example, the addrType object with the common name NOTES:i386 specifies a proxy address generator DLL called Ntspxgen.dll in this attribute.
  name	The name of the address type, such as NOTES:i386.

• Address templates   In conjunction with the addrType object, MAPI-based connectors might also install address templates and options templates to provide a friendly interface that a user can use to create custom recipients for the non-Exchange messaging system. These templates describe the settings on a dialog box with which to enter custom addresses. Address templates work with an address syntax program to convert the data entered by the user to a proxy address string. You can customize the address templates in Exchange System Manager (in the Address Templates container, under Recipients).
  

  Note:
  Address templates and address syntax programs are optional connector components. Connector for Lotus Notes and Connector for Novell GroupWise do not install these components.

• msExchConnector object   More important than address templates is the actual connector object that each MAPI-based connector must have in Active Directory. At server startup, the routing engine enumerates and reads all msExchConnector objects from all routing groups to initialize the link state table. This is explained in Message Routing Architecture.
  Connector objects reside in the Connectors container under their routing groups in Exchange System Manager. A corresponding administrative snap-in is required to configure the settings of the msExchConnector object. Settings include connector type-specific attributes, in addition to general attributes.
  

  Note:
  In addition to the msExchConnector object in Active Directory, configuration information can also be stored in the registry database on the bridgehead server.

  The following table lists important general attributes that all MAPI-based connectors have in common.
  

  Important general attributes of msExchConnector objects

  Attributes	Description
  Common name	Represents the name of the connector object in Active Directory relative to its parent container.
  computerName	Points to the bridgehead server that is running the MAPI-based connector. This attribute must match exactly the network basic input/output system (NetBIOS) name for the bridgehead server, otherwise the Queue Viewer snap-in in Exchange System Manager cannot display the connector's message queues.
  deliveryMechanism	Identifies the delivery mechanism that is used by Exchange Server 2003 to pass messages to the MAPI-based connector.
  distinguishedName	Represents the distinguished name of the connector object in Active Directory.
  homeMDB	Identifies the private store that holds the connector mailbox.
  homeMTA	Identifies the Exchange MTA that is responsible for message routing to the MAPI-based connector.
  legacyExchangeDN	Represents the distinguished name of the connector object in the earlier Exchange Server 5.5 directory format. This attribute must be set on the connector object for the Queue Viewer snap-in to work.
  msExchConnectorType	Identifies the connector type. For example, the connector type for Connector for Lotus Notes is NOTES and the connector type for Connector for Novell GroupWise is GWISE.
  name	Represents the name of the connector object. Exchange System Manager uses this name as the display name of the connector object.
  objectClass	Identifies the connector as an msExchConnector and a mailGateway. In addition, a specific object class is registered to identify the actual type of the connector. For example, msExchNotesConnector is the object class for Connector for Lotus Notes and msExchGroupWiseConnector is the object class of the gateway object for Connector for Novell GroupWise. Note: To support connector-specific attributes, MAPI-based connectors from non-Microsoft vendors must extend the schema of Active Directory to create a new object class. You should represent MAPI-based connectors in Active Directory by objects of a class that inherits from the mailGateway class. The mailGateway object, in turn, is a sub-class of msExchConnector.
  routingList	Identifies the address spaces associated with this connector. Each connector has at least one associated address space. The routing engine uses this information to determine possible connectors for a particular message by comparing the recipient addresses with available address space information.

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

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.

Connector queues in the Exchange store

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

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.
   

Similar to typical MAPI clients, such as Microsoft Office Outlook, MAPI-based connectors require a MAPI profile to access their connector mailboxes. The MAPI profile defines the settings that the MAPI subsystem uses to communicate with the Exchange store. MAPI-based connectors use the MAPILogonEx function to create the required profile dynamically and without the need for a MAPI client on the server. For detailed information how to create MAPI profiles dynamically, see Microsoft Knowledge Base article 306962, "How to Create MAPI Profiles Without Installing Outlook."

MAPI profiles are stored in the registry under the HKEY_USERS hive. Several subkeys exist on a bridgehead server, according to the security identifiers (SIDs) of system accounts and user accounts that the active server processes and administrators use to log on to the system. In Exchange Server 2003, MAPI-based connectors should run in the context of the LocalSystem account, which has an SID of S-1-5-18. Accordingly, you can find the MAPI profile of a MAPI-based connector at the following location: HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles. For example, if you installed and started Connector for Novell GroupWise on a bridgehead server named Server01, you can find a subkey named SERVER01-LME-GWISE V5.5 under the Profiles key.

It is possible to copy the connector profile to the subkey of the administrator who is currently logged on and then use a low-level MAPI tool to open the connector mailbox. Mdbvu32.exe is such a low-level MAPI tool, available for download from the Downloads for Exchange Server 2003 Web site.

The Information Store Viewer.doc file that comes with the tool contains detailed information about how to use the Mdbvu32.exe tool. The following figure shows the Mdbvu32.exe tool in action. You can see all the system folders in the connector mailbox.

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.

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

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.
  

  Properties of the message transfer envelope

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

Address translation for message sender and recipients is based on proxy addresses. All Exchange users must have a proxy address of the required type, so that the MAPI-based connector can perform a lookup in Active Directory and insert the correct non-Exchange address in the message envelope of the outbound message. For inbound messages, the translation is performed in the opposite direction.

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.

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.
  

Exchange Server 2003 uses message classes to define which properties a message contains, the type of information the message conveys, and how the message can be handled. Each message class has an associated set of properties, and because different MAPI message classes support different sets of properties, multiple algorithms must be used to convert a MAPI message to the message format of the non-Exchange messaging system. Similarly, if the message format of the non-Exchange messaging system supports its own message classes, separate translation algorithms are necessary to handle these message classes.

To handle a message class, the connector converts outgoing messages to an appropriate format (when the non-Exchange messaging system has an analogous message class) and converts incoming messages to an appropriate MAPI message class. The connector also generates the various REPORT message classes when an incoming or outgoing message requires them. In addition to handling a message class, the connector also converts message attachments.

The following table lists the message classes that MAPI-based connectors must handle.

Message classes that MAPI-based connectors must handle

Message Class	Description
ENVELOPE.{Message Class}	The MTE that contains the message. The standard message class that is enclosed in the MTE is IPM.NOTE. This message object can be opened with the MAPI IMessage interface. Note: In addition to the ENVELOPE message class, MAPI-based connectors must handle the standard message classes, such as IPM.NOTE, which are enclosed in the MTE to perform message conversions.
REPORT.{Message Class}.NDR	The NDR. The MAPI-based connector generates an NDR when message delivery fails. For example, the connector might be unable to determine addresses for message sender or required recipients or might be unable to connect to the non-Exchange messaging system. Or, the non-Exchange messaging system might return an NDR, because a specified recipient does not exist. The NDR is returned to the original sender, and the original message and its recipient list are included in the NDR as an embedded message attachment.
REPORT.{Message Class}.DR	The delivery report. Delivery reports are optional reports that provide various amounts of information about the delivery of the original message, depending on the non-Exchange messaging system. If the non-Exchange messaging system does not support delivery reports, the MAPI-based connector can generate a delivery report when it successfully transfers a message to the non-Exchange messaging system. This type of report indicates to the sender only that the non-Exchange messaging system accepted the message.
REPORT.{Message Class}.IPNRN	The interpersonal note receipt notification. Read receipts are optional report messages, similar to delivery reports. Read receipts inform a sender that a recipient has read a message. Read receipts are generated by the messaging client of the recipient. Not all non-Exchange messaging systems support these reports.
REPORT.{Message Class}.IPNNRN	The interpersonal note non-receipt notification. Non-read receipts are similar to read receipts, only they inform a sender that a recipient deleted a message without opening it. Non-read receipts are generated by the messaging client of the recipient. Not all non-Exchange messaging systems support non-read receipts.

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

Directory synchronization is made up of two separate, sequential processes:

1. Synchronizing recipients from a non-Exchange messaging system to Active Directory.
   
2. Synchronizing recipients from Active Directory to a non-Exchange messaging system.
   

Directory synchronization from a non-Exchange messaging system to an Exchange organization involves the following sequential processes:

1. Extracting directory information from the non-Exchange messaging system   MAPI-based connectors use the programming interfaces that the non-Exchange messaging system provides to extract the directory information from the non-Exchange messaging system. For example, Connector for Lotus Notes uses the Lotus Notes Client API to accomplish this step, and Connector for Novell GroupWise uses administrator messages, which it passes to Novell GroupWise API Gateway.
   
2. Preparing the directory information for an import to Active Directory   MAPI-based connectors create the following types of recipient objects for non-Exchange users in Active Directory:
   
   • Disabled mail-enabled user accounts   This is a good choice if the non-Exchange users are not yet in the Active Directory environment, but will be in the environment after migration to Exchange Server 2003.
     
   • Enabled mail-enabled user accounts   This is a good choice for non-Exchange users who work in your Active Directory environment, even though they do not have an Exchange mailbox.
     
   • Mail-enabled contacts   This is a good choice for non-Exchange users who are not, and never will be, in the Active Directory environment. Internet users in external messaging systems are an example.
     
   A MAPI-based connector can synchronize distribution lists as contact objects. This is an advantage because the connector does not need to maintain distribution list membership information in Active Directory. However, messages sent to a distribution list must then first be transferred to the legacy messaging system for distribution list expansion, before the messages can be delivered to the individual recipients. If the distribution list contains recipients that refer back to users in the Exchange Server 2003 organization, messages must travel back to the Exchange Server 2003 organization after the distribution list expansion. To avoid this unnecessary message transfer, you might choose not to synchronize distribution lists. If the number of distribution lists is manageable, you can create mail-enabled groups in Active Directory and specify the individual members directly. In this case, Exchange Server 2003 can perform the distribution list expansion immediately and without the overhead of additional message transfer to the legacy messaging system. Groups in Active Directory can contain any type of recipient objects, such as user accounts, contacts, or other groups.
   
3. Importing the directory information to Active Directory   MAPI-based connectors use ADSI to create mail-enabled user accounts or mail-enabled contacts. Both Connector for Lotus Notes and Connector for Novell GroupWise import recipient information to a single target organizational unit in Active Directory. The target organizational unit, where the MAPI-based connector places the recipient objects that are created during directory synchronization for non-Exchange users, is also named the import container. There can be only one import container.
   

   Note:
   The computer account of the Exchange Server 2003 bridgehead server running the MAPI-based connector requires permissions to create and modify recipients in the selected import container.

The following figure illustrates the general process for transferring directory information from a non-Exchange messaging system to an Exchange organization.

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

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

Note:
The computer account of the Exchange Server 2003 bridgehead server running the MAPI-based connector requires permissions to access and read recipient information in the selected export container.

The following figure illustrates the general process for transferring directory information from Active Directory to a non-Exchange messaging system, based on ADSI and non-Microsoft APIs or import tools, which place the recipient objects in the non-Exchange directory. The APIs and tools that a MAPI-based connector uses to import directory information to a non-Exchange directory depend on the non-Exchange messaging system. For example, Connector for Lotus Notes accomplishes directory imports into Lotus Notes using the Lotus Notes Client API, while Connector for Novell GroupWise uses administrator messages, which it passes to Novell GroupWise API Gateway.

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