Understanding Interoperability Between Exchange Server 2003 and Non-Exchange Messaging Systems

 

Microsoft provides several components for integrating Exchange 2003 into a non-Exchange messaging infrastructure and for migrating users to Exchange 2003:

• SMTP connector and X.400 connector   For seamless interoperability, you must deploy a reliable bidirectional message transfer path. All modern messaging systems support SMTP, so you can use an SMTP connector to connect the systems. Or if the legacy messaging system relies on X.400, you can use an X.400 connector. This messaging connectivity might be temporary (for example, the systems might need to coexist only while you migrate users from the legacy system to Exchange Server 2003). In other cases, long-term coexistence might be required (for example, the messaging system of a department that is not moving to Exchange Server 2003 might require a permanent connection).

• Active Directory tools and application programming interfaces   You must synchronize the Active Directory® directory service and the directory of the legacy messaging system to establish a consistent global address list across both messaging systems. However, neither an SMTP connector nor an X.400 connector supports automatic directory synchronization. As mentioned in Understanding Interoperability and Migration in Exchange Server 2003 you can use Active Directory tools such as Ldifde.exe and Csvde.exe to perform manual directory synchronization or bulk export and import operations. With basic Microsoft Visual Basic® Scripting Edition (VBScript) programming skills, it is also possible to implement a more sophisticated, semi-automatic directory synchronization solution based on Active Directory Service Interfaces (ADSI) and Collaboration Data Objects for Exchange Management (CDOEXM). For more information about ADSI and CDOEXM, see the Exchange Software Development Kit (SDK) (https://go.microsoft.com/fwlink/?LinkId=25925).

• Exchange Server programming interfaces for accessing free/busy information   Cross-platform access to free/busy information is useful for scheduling meetings and conferences across different messaging systems. However, a calendar connector is not available for non-Exchange messaging systems other than Lotus Notes or Novell GroupWise when connected to the Exchange 2003 organization through Connector for Lotus Notes or Connector for Novell GroupWise. Although it is not possible to synchronize free/busy information between systems that are connected with each other through an SMTP connector or an X.400 connector, you can use Outlook to publish free/busy information in a shared location, or use Collaboration Data Objects for Exchange (CDOEX) to implement a custom solution that displays the free/busy status of Exchange 2003 users in an ASP.NET page. For more information about CDOEX, see the Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).

• Exchange Migration Wizard   The Exchange Migration Wizard is a tool that you can use to migrate users from a supported messaging system, such as Microsoft Mail for PC Networks, Microsoft Mail for AppleTalk Networks, or Lotus cc:Mail, to Exchange 2003. The Exchange Migration Wizard also supports LDAP and IMAP4, which is very useful if you must migrate from HP OpenMail, Sun ONE (formerly known as Netscape iPlanet), Openwave Email Mx, Alt-n MDaemon, or any other e-mail system that supports LDAP and IMAP4. The Exchange Migration Wizard supports migration by copying existing directory information, mailboxes, and messages and importing that information into Exchange Server 2003, as explained in Understanding Interoperability and Migration in Exchange Server 2003.

• Stand-alone source extractors   The Exchange Migration Wizard does not support legacy messaging systems directly, such as Dec All-in-One, Verimation MEMO, or IBM Professional Office System (PROFS) and OfficeVision/VM. However, stand-alone source extractors, available from both Microsoft and non-Microsoft vendors, can be used to extract existing data from mailboxes in the legacy messaging system into migration files that the Exchange Migration Wizard can import into Exchange Server 2003. To obtain a stand-alone source extractor for your legacy messaging system, contact Microsoft Product Support Services. For information about Product Support Services, including how to contact them, go to https://support.microsoft.com.

Message Transfer and Conversion

Exchange Server 2003 supports two general messaging standards to connect to any type of messaging system: SMTP and X.400. SMTP is the native message transfer protocol of Exchange 2003, and therefore it is recommended that you choose SMTP over X.400. Also, an SMTP connector is more straightforward to configure than an X.400 connector. However, X.400 is a good choice if you are working in an environment that relies on an X.400 backbone or will not support SMTP unless you deploy additional components in the legacy infrastructure.

SMTP-based Message Transfer

Exchange Server 2003 relies on the Windows 2003 SMTP service, extended with Exchange-specific transport components and modules, for communication with remote SMTP hosts. The SMTP service is represented in Exchange 2003 by virtual servers. For message transfer to work, SMTP virtual servers must be able to resolve SMTP domain names into IP addresses. This is typically accomplished through Domain Name System (DNS) queries. The SMTP hosts must be registered in mail exchanger (MX) records. It is also possible to forward all outbound SMTP messages to a single SMTP host for further delivery. This SMTP host is called a smart host. Internet service providers (ISPs) often provide their customers with a central smart host that handles message transfer across the Internet.

SMTP message transfer to internal SMTP hosts is best accomplished through dedicated SMTP connectors, because SMTP connectors provide greater control over the configuration than SMTP virtual servers do. Connector settings have higher priority for message transfer than the settings for virtual servers. For example, you can use an SMTP connector to implement a central messaging bridgehead server that is responsible for all message transfer between the legacy messaging system and the Exchange 2003 organization. Figure 1 illustrates such an environment with a single bridgehead server. For fault tolerance and load balancing, you can define multiple bridgehead servers in the SMTP connector configuration.

Figure 1   Connecting an Exchange 2003 organization to a non-Exchange messaging system through an SMTP connector

When you configure an SMTP connector, you can specify whether to use DNS and MX records for message transfer or to forward all messages to a smart host. Using a smart host is usually the better option when transferring messages to another SMTP host in the internal network, because internal destinations are often not registered as MX records in DNS. To forward messages for a particular SMTP domain across an SMTP connector, you must identify the connector as responsible for the domain. You do this by defining an address space of type SMTP in the connector configuration that corresponds to the SMTP domain name of the target system. In Figure 1, this address space is: SMTP: legacy.contoso.com. Because the target system is identified by means of an SMTP domain name, the legacy messaging system and the Exchange 2003 organization cannot share the same SMTP domain name. For more information about how to deal with SMTP domain names in migration scenarios, see Understanding Interoperability and Migration in Exchange Server 2003.

Exchange to SMTP Message Transfer

Figure 2 shows the process for sending messages from Exchange 2003 to a non-Exchange messaging system through an SMTP connector.

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

The transfer of messages from Exchange 2003 to a non-Exchange messaging system through SMTP proceeds as follows:

1. All messages sent to local or remote users must pass through the Exchange 2003 transport engine. The pre-submission queue is the entry point into the advanced queuing engine.

2. The advanced queuing engine transfers the message from the pre-submission queue into the pre-categorization queue so that the categorizer can process it. The categorizer checks restrictions, applies per-sender and per-recipient limits, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine.

   Note

   The categorizer expands distribution lists, resolves recipient and sender names, determines home servers, determines what format messages must be converted to, and bifurcates messages. Bifurcation is the process of creating multiple copies of a message, which is required, for example, when recipients require different message formats.

3. The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into the pre-routing queue and calls the routing engine. The routing engine maintains next-hop information in the link state table. Based on the user's target address, the routing engine determines that the recipient is a user on a non-Exchange messaging system and moves the message to the link queue for the SMTP connector. The queue manager component manages the link queues. The name of the queue matches the remote delivery destination.

4. The SMTP protocol service picks up the message, determines the destination host from the SMTP connector configuration or through a DNS query based on the recipient's SMTP domain, establishes a TCP/IP connection to the destination host on TCP port 25, and transfers the message.

5. The destination host delivers the message to its final destination.

SMTP to Exchange Message Transfer

An SMTP connector is used only for outbound message transfer from Exchange 2003. SMTP connectors are configuration objects that contain parameters that determine how the SMTP service establishes connections and transfers messages. Non-Exchange messaging systems, however, do not recognize these objects and parameters. Remote SMTP hosts simply establish a TCP/IP connection to the SMTP service on the Exchange 2003 server through TCP port 25 and transfer their messages.

Figure 3 shows the process for receiving messages from a remote SMTP host.

Figure 3   Receiving messages from a remote SMTP host

The transfer of messages from a remote SMTP host to Exchange 2003 can be divided into four steps:

1. The remote SMTP host establishes a TCP/IP connection to the Exchange 2003 server on TCP port 25, and transfers the message. The local SMTP protocol service places the message in the pre-submission queue of the advanced queuing engine.

2. The advanced queuing engine transfers the message from the pre-submission queue into the pre-categorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine.

3. The advanced queuing engine transfers messages for local recipients from the post-categorization queue into the local delivery queue.

4. The Exchange store driver picks up the message and places it in the Inbox of the local recipient.

Exchange/SMTP Message Conversion

SMTP, as its name Simple Mail Transfer Protocol implies, does not define complex message types, such as delivery receipt requests, read receipt requests, meeting requests, or task requests. In fact, SMTP handles only one message type: a simple text message. An SMTP message consists of a sequence of seven-bit ASCII characters. The message header, which contains, among other things, sender and recipient information, subject, and date, is separated from the body by a null line, that is, a line with nothing preceding the carriage return/line feed character. As shown in Figure 4, the SMTP message format, defined in RFC 822, is indeed simple.

Figure 4   A basic SMTP message

The basic SMTP message format can be used only for text-based e-mail messages. To support attachments, the original files must be encoded using UUENCODE or Multipurpose Internet Mail Extensions (MIME). Your decision about whether to use UUENCODE or MIME to encode message attachments will depend on the features that are supported by the receiving messaging client.

UUENCODE is an encoding mechanism that converts binary data into printable ASCII characters so that the data can be included in the message body without violating SMTP conventions. The message shown in Figure 4 contains the seven-bit character stream of an attached uuencoded file.

MIME provides another way for non-text information to be encoded as text. MIME, defined in RFC 1341 and successors, is a very flexible format. It describes a way to include multiple parts of various content types into an e-mail message, both textual and non-textual. Parts of a message can be text, images, audio, video, or other application-specific data.

When you connect an Exchange 2003 organization to a non-Exchange messaging system through an SMTP connector, all of the message content must be encapsulated using UUENCODE or MIME to avoid losing formatting in Rich Text Format (RTF) and extended characters. The encapsulated message can be inserted into the message in the form of printable characters.

By default, messages are encapsulated using MIME. However, you can specify the message format for each SMTP domain in the Exchange System Manager tool. Under Global Settings, display the properties for the Internet Message Format object, and switch to the Message Format tab. Among other things, you can choose to provide the message body as HTML, which is a good choice if the recipient's e-mail client supports HTML-formatted messages. Formatting messages in HTML preserves most rich-text features that would be lost if you sent the message body as plain text.

Table 1 shows which Exchange rich-text features convert correctly to HTML and which do not.

Table 1   E-mail message conversion between RTF and HTML

Rich Text Format (Exchange)	HTML (MIME/SMTP)
Size	Converts correctly
Color	Converts correctly
Bold	Converts correctly
Underline	Converts correctly
Italic	Converts correctly
Strikethrough	Converts correctly
Tables	Do not convert correctly
Embedded OLE objects, including graphics	Ignored
Double strikethrough	Converts to single strikethrough
Superscript	Converts correctly
Subscript	Converts correctly
Shadow	Ignored
Outline	Ignored
Emboss	Ignored
Engrave	Ignored
Small caps	Ignored
All caps	Ignored
Bullets	Convert, but line spacing is ignored
Numbered list	Converts correctly

To avoid losing formatting information when converting from RTF to HTML, Outlook users can configure their clients to compose messages in HTML format by default. Also, if users choose to use Microsoft Word as their e-mail editor, they can use the full HTML editing set available with Word when composing e-mail messages. For example, they compose a message in HTML format and insert a table into the message. The table is preserved during message transmission, because it is a native HTML structure. In contrast, a table that is inserted into a rich-text message will be lost during conversion from RTF to HTML. The issue is not whether an HTML-formatted message can have a table (or other specific rich-text feature), but whether the conversion from RTF to HTML supports this rich-text element.

Another option is to send RTF information to the remote recipient encapsulated in TNEF format. This is a good choice if you know that the recipient works with a client that supports MAPI, such as Outlook with the IMAP4 transport driver. By sending messages in RTF, you can ensure maximum interoperability between Outlook users in different messaging systems, because all message properties are preserved. For example, calendar information requires rich-text formatting. Users can send special message types, such as meeting requests or task requests, to each other in RTF. Users can decide individually whether to send messages in RTF, but you can also enable this feature in Exchange System Manager for each SMTP domain. In the properties for the Internet Message Format object, switch to the Advanced tab, and under Exchange rich-text format select the option Always use.

X.400-based Message Transfer

Before SMTP established itself as one of the leading standards for message transfer, commercial e-mail service providers and large corporations deployed X.400 backbones to connect different messaging systems. Today, SMTP is more popular than X.400 because it is simple and is established on the Internet. However, X.400 continues to be a common messaging standard in law firms and legal departments, financial institutions, insurance companies, and other organizations for which message transfer must be secure and traceable. In an SMTP-based backbone, it is difficult to find misrouted messages or determine the origin of an e-mail message with offensive text. In an X.400 backbone, however, every connection requires authentication. All message transfer agents (MTAs) must identify themselves as authorized MTAs before they can transfer messages. Now that the Internet is flooded with spam and e-mail-borne viruses, X.400 is regaining its popularity.

Exchange Server 2003 supports X.400 through the Microsoft Exchange Message Transfer Agent (MTA) Stacks service. The Exchange MTA supports X.400 according to the 1988 conformance year and can communicate with remote X.400 1984 and 1988 systems through TCP/IP or X.25. X.400 systems of later conformance years (such as 1992) must reduce their feature sets to the standard of 1988 when communicating with Exchange 2003. The X.400 standard demands that X.400 systems scale back to the capabilities of their communication partners.

Exchange to X.400 Message Transfer

Figure 5 shows the process of sending messages from Exchange 2003 to a remote X.400 system.

Figure 5   Sending messages from Exchange 2003 to a remote X.400 MTA

The transfer of messages from Exchange 2003 to a non-Exchange messaging system through X.400 proceeds as follows:

1. The user sends a new message, which the Exchange store driver places into the pre-submission queue to pass it to the Exchange 2003 transport engine. In Exchange 2003, all messages for local or remote recipients must pass through the transport engine.

2. The advanced queuing engine transfers the message from the pre-submission queue into the pre-categorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to pass it back to the advanced queuing engine.

3. The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into the pre-routing queue and calls the routing engine. The routing engine determines that the recipient is a user on an X.400 messaging system (based on the user's target address and the address space associated with the X.400 connector) and moves the message to the link queue for the Exchange MTA. The queue manager component manages the link queues.

4. The Exchange store driver informs the Exchange MTA that a new message awaits transfer. The MTA obtains the message from the link queue, converts recipient information and message bodies from message database encoding format (MDBEF) into an appropriate X.400 format according to the conformance year and character set of the remote MTA as specified in the X.400 connector properties, and places the message in an MTA internal queue on the file system.

5. The Exchange MTA establishes a connection to the remote MTA, identifies itself, and when the connection is accepted, transfers the message. The remote MTA then delivers the message to the final destination.

X.400 to Exchange Message Transfer

Figure 6 shows the process for receiving messages from a remote X.400 MTA.

Figure 6   Receiving messages from a remote X.400 MTA

The transfer of messages from a remote X.400 MTA to Exchange 2003 can be divided into several steps:

1. The remote X.400 MTA establishes a connection to the local Exchange MTA, identifies itself as an authorized MTA, and, after the Exchange MTA accepts the connection and the association is established successfully, transfers the message. The Exchange MTA stores the incoming message in its message database on the file system.

2. The Exchange MTA converts the recipient information and message body into Exchange format and places the message into the SMTP mailbox store to pass it to the SMTP transport engine for delivery. In Exchange 2003, all messages must pass through the SMTP transport engine.

3. The Exchange store driver places the message in the pre-submission queue of the advanced queuing engine.

4. The advanced queuing engine transfers the message from the pre-submission queue into the pre-categorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine.

5. The advanced queuing engine transfers messages for local recipients from the post-categorization queue into the local delivery queue.

6. The Exchange store driver picks up the message and places it into the Inbox of the local recipient.

Exchange/X.400 Message Conversion

X.400 connectors support a variety of content types and character sets. X.400 content types include P2 (1984 conformance year), P22 (1988 conformance year), Body Part 14 or Body Part 15 for binary data. When the Exchange MTA communicates with an X.400-84 MTA, the message body is sent using the P2 content type, and attachments are sent using Body Part 14. When communicating according to the 1988 conformance year, text is sent using the P22 content type, and you can configure the server to send attachments using either Body Part 14 or Body Part 15 formatted as a File Transfer Body Part (FTBP).

The Exchange MTA supports the following X.400 body parts for message text:

• International Alphabet 5 (IA5)   A character set that is similar to US-ASCII and includes western European characters.

• International Organization for Standardization (ISO) 6937   A character set that includes 333 characters from the Latin script plus non-spacing diacritical marks. To support other languages, character set switching is required as defined in ISO 2022. ISO 6937 is a superset of the Teletex character set definition.

• ISO 8859   A family of eight-bit single-coded character sets. Most languages that are based on single-byte characters can be supported in one of the ISO 8859 alphabets.

• Teletex 61 (T.61)   A subset of ASCII, plus international eight-bit characters.

None of the character sets in the P2 or P22 content types can represent RTF information or even OLE objects. Support for RTF is available only if the receiving side can understand MAPI message formats. Many X.400-based messaging systems, such as HP OpenMail, support Outlook and therefore MAPI.

The Exchange MTA can encapsulate the entire message in TNEF and send it an additional file attachment. The principle is the same as discussed earlier for the SMTP connector. If the receiving system can process the TNEF attachment (for example, if the recipient is using Microsoft Outlook), the message is displayed with all RTF information. However, if the receiving system cannot process TNEF, the message text and attachments might not be readable. You must ensure that the X.400 connector configuration corresponds to the capabilities of the non-Exchange messaging system.

Directory Synchronization

Directory synchronization is the process of propagating directory information about Exchange 2003 users from Active Directory to the directory of a non-Exchange messaging system, while propagating information about users from the non-Exchange messaging system to Active Directory to be used by Exchange 2003. When directory synchronization is complete, each system has a complete copy of the directory data (users, groups, and so on) for the combined messaging organization.

Directory synchronization consists of two sequential processes:

• Synchronizing recipients from Active Directory to a non-Exchange messaging system

• Synchronizing recipients from a non-Exchange messaging system to Active Directory

Unfortunately, you cannot use an SMTP connector or an X.400 connector to enable automatic, scheduled directory synchronization between Exchange 2003 and a non-Exchange messaging system, so you must implement a manual or semi-automated solution. When you implement a custom solution for directory synchronization, remember that you must implement a bidirectional process, because recipient attributes must be updated in both directories. For information about how to work programmatically with directory information in a non-Exchange messaging system, contact the vendor of the messaging system. This section explains how to work with Active Directory using standard Active Directory tools.

Synchronizing Directory Entries from a Non-Exchange Messaging System to Active Directory

Directory synchronization from a non-Exchange messaging system to Active Directory includes the following processes:

1. Extracting directory information from the non-Exchange messaging system   You can use a variety of tools to obtain the source directory information, including application programming interfaces (APIs) or LDAP. If the non-Exchange messaging system supports LDAP, you can use the Exchange Migration Wizard to extract directory information from the non-Exchange messaging system. For LDAP directories, ensure that you select the option Migrate from Internet Directory (LDAP via ADSI), and on the next wizard page select the option Extract migration files only. The Exchange Migration Wizard places the extracted directory information into a primary migration file called directory.pri, which is a comma-separated value (.csv) text file that you can use as the basis for further processing, such as for a directory import. For more information about migration files and the Exchange Migration Wizard, see Understanding Interoperability and Migration in Exchange Server 2003.

   Note

   LDAP-conforming directories typically provide SMTP address information, so you should use an SMTP connector if you are using LDAP-conforming directories to connect the messaging systems. If you use an X.400 connector instead, ensure that you obtain the address information in X.400 format. Most messaging systems provide proprietary directory export features that you can use. Ask the administrator who is responsible for the legacy messaging system to provide you with exported directory information in the format that corresponds to the connector that you deploy between Exchange 2003 and the non-Exchange messaging system.

2. Preparing the directory information for an import into Active Directory   The tool that you use to import directory information into Active Directory determines how you must structure the data so that the import can be completed successfully. For example, if you are using Ldifde.exe, you must provide the source data in LDAP Data Interchange Format (LDIF). LDIF is defined in RFC 2849. However, if you are familiar with programming with ADSI or CDOEXM, you can develop a custom solution to import the data. The format of the source data depends on the parsing routines that you implement in your custom solution. Ideally, you use a tool that can parse the input file without requiring format conversions. For example, you might want to parse the .csv-based structure of a directory.pri file directly, in the format in which it was exported from an LDAP directory, to import recipient information into Active Directory. For more information about programming with ADSI or CDOEXM, see the Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).

3. Importing the directory information into Active Directory   You cannot use the Exchange Migration Wizard to perform the actual directory synchronization because the Exchange Migration Wizard is designed to create mailboxes in Exchange 2003. Directory synchronization is based on the assumption that the recipients are still in the legacy system. To perform directory synchronization correctly, your solution must create mail-enabled user accounts or mail-enabled contacts instead of mailbox-enabled user accounts. It is recommended that you create a designated organizational unit for all non-Exchange users in Active Directory for use during the migration process.

   For non-Exchange users, you can create the following types of user accounts in Active Directory:

   • Disabled Windows user accounts   Create disabled Windows user accounts if your non-Exchange users are not in your Active Directory environment yet, but will be after migration to Exchange 2003.

   • New Windows user accounts   Create enabled Windows accounts for non-Exchange users who work in your Active Directory environment prior to migration.

   • Windows contacts   Create Windows contacts for non-Exchange users who are not in your Active Directory environment. The Exchange Migration Wizard can convert these contact objects to user accounts during the migration process.

   An interesting question arises regarding distribution lists in the legacy messaging system. You can synchronize distribution lists as contact objects, which has the advantage that you do not need to maintain distribution list membership information in Active Directory. However, if you synchronize distribution lists as contact objects, messages that are sent to a distribution list must 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 2003 organization, messages must return to the Exchange 2003 organization after the distribution list is expanded. To avoid this unnecessary message transfer, you can create mail-enabled groups in Active Directory and specify the individual members directly. If you do this, Exchange 2003 can expand the distribution list 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 (for example, user accounts, contacts, or other groups). After you create mail-enabled user accounts or mail-enabled contacts in Active Directory that correspond to the recipients in the legacy system, you can mirror the distribution lists from the legacy system and add the required recipient objects as members. When you migrate users later using the Exchange Migration Wizard, the wizard will find existing mail-enabled objects by matching the e-mail address of the account to be migrated to the e-mail address of the target object in Active Directory. During the migration process, the Exchange Migration Wizard converts those recipient objects into mailbox-enabled user accounts and preserves the distribution group membership information. However, if you do not use the Exchange Migration Wizard, you must take extra steps to add the mailbox-enabled user accounts back to all of their distribution groups after migration. It is possible to perform this step programmatically.

   Note

   The Exchange Migration Wizard does not export directory information about distribution lists from the legacy messaging system. You must use a different directory export method or create the distribution lists manually in Active Directory.

4. Updating the directory information in Active Directory   After directory information is imported into Active Directory, you must ensure that directory information is kept up-to-date in both directories. For example, if you change or delete a user in the legacy system, the corresponding recipient object must also be updated or deleted in Active Directory. Changing or deleting an existing recipient object requires that you find the existing object in Active Directory and then perform the update.

   To find recipient objects in Active Directory that correspond to:

   • Changed recipient objects in the non-Exchange messaging system   You can use the e-mail address of the recipient object to locate its counterpart in Active Directory, because the primary e-mail address of the Active Directory object is the SMTP or X.400 address of the recipient in the legacy messaging system. However, you must account for situations in which e-mail addresses do not match. A user might have a user account in Active Directory that has not been mail-enabled yet or the user's original e-mail address might have changed (for example, a user is given a new SMTP address in the legacy messaging system). In such situations, matching e-mail addresses does not work, and you must use additional attributes to find the matching recipient object. You can use the display name or alias of the user in the legacy system, or any other attribute that allows you to establish a reliable association between the source and target recipient objects.

   • Deleted recipient objects in the non-Exchange messaging system   Finding a target object in Active Directory when the source object has been deleted from the legacy non-Exchange messaging system is complicated. The deleted source object no longer exists, so it cannot be used as a reference to locate the corresponding recipient object in Active Directory. In this situation, you can either delete the corresponding recipient object manually from Active Directory, or compare the complete address list from the non-Exchange messaging system with the complete list of corresponding recipient objects in Active Directory to determine which objects exist only in Active Directory. Mail-enabled Active Directory accounts without a counterpart in the source messaging system indicate that the source objects have been deleted.

     To compare address lists, you must associate the recipient objects that you create in Active Directory with their counterparts in the non-Exchange messaging system. You might be able to use the SMTP domain name of the legacy messaging system to establish this association. Another option is to use an organizational unit exclusively for the recipient objects that belong to a specific legacy messaging system. You can then compare the objects in that organizational unit to the list of recipients in the legacy system. A third, and perhaps the most reliable way to compare address lists, is to write specific information about the messaging system that the recipients reside in into an attribute of the recipient objects in Active Directory. You can then use this attribute as the basis for an LDAP query. You can either use an extension attribute or the attribute called importedFrom to register your specific synchronization information.

Figure 7 shows the general process for transferring directory information from a non-Exchange messaging system to Active Directory based on LDAP, the Exchange Migration Wizard, and a custom script that processes the directory.pri file. If you prefer a solution without a custom script, you can replace the custom script with Ldifde.exe, but remember that you must then convert the directory.pri file format into an LDF format to support Ldifde.exe.

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

Synchronizing Directory Entries from Active Directory to a Non-Exchange Messaging System

Directory synchronization from Active Directory to a non-Exchange messaging system is based on the same principles as directory synchronization from a non-Exchange messaging system to Active Directory. You must extract information about mailbox-enabled user accounts from Active Directory, process the information, and then import, update, or delete the information in the legacy directory. You can use tools such as Ldifde.exe, Csvde.exe, or ADSI to extract Active Directory data. You can also use the Exchange Migration Wizard, because Active Directory is a supported LDAP-conforming directory. The advantage of using the Exchange Migration Wizard to extract Active Directory data is that the extracted directory information is placed in a directory.pri file in exactly the same way as the directory information from any other LDAP directory. Therefore, you can re-use the file-parsing routines that you used for non-Exchange to Active Directory directory synchronization. Only the APIs or tools for importing the directory information into the legacy directory will differ. For details about how to import directory information into the legacy messaging system, contact the messaging system vendor.

Figure 8 shows the general process for transferring directory information from Active Directory to a non-Exchange messaging system using the Exchange Migration Wizard and a custom script that uses non-Microsoft APIs or import tools to place the recipient objects into the legacy directory.

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

One disadvantage of using the Exchange Migration Wizard to extract directory information from Active Directory is that you cannot extract information for mail-enabled user accounts, contacts, or distribution groups from Active Directory. If your Exchange 2003 organization is connected to multiple non-Exchange messaging systems, or if you created mail-enabled objects for recipients on the Internet, you might want to include these mail-enabled objects in your custom directory synchronization process so that users in the non-Exchange messaging systems can communicate conveniently with all users in your messaging environment using the Exchange 2003 organization as a backbone. You must use tools such as Ldifde.exe, Csvde.exe, or ADSI to extract mail-enabled objects from Active Directory. The best way to synchronize mail-enabled distribution groups is as contact objects, so that you can bypass the group membership synchronization. You can address distribution group issues in various ways, as discussed in Understanding Interoperability and Migration in Exchange Server 2003.

Directory Synchronization Alternatives

Implementing a custom solution for directory synchronization is a good choice for system administrators who prefer to work with command-line tools and APIs. If you prefer to implement a more readily available solution, however, you might want to consider the following options:

• Messaging connectors available in Exchange Server 5.5 or Exchange 2000 Server   If you are running a mixed Exchange organization, you might be able to use messaging connectors for message transfer and directory synchronization that were included with Exchange 5.5 or Exchange 2000 but are not available in Exchange 2003. For example, you can use Exchange 2000 to connect seamlessly to Microsoft Mail for PC Networks or Lotus cc:Mail, and Exchange 5.5 to connect to Microsoft Mail for PC Networks, Lotus cc:Mail, IBM PROFS, and IBM Systems Network Architecture Distribution Services (SNADS) with a direct gateway connector.

• Microsoft Metadirectory Services (MMS)   You can use MMS to integrate multiple directories with each other. MMS supports a broad range of directory services, including Active Directory, the Exchange 5.5 directory, Microsoft Windows NT® domains, Lotus Notes/Domino, Lotus cc:Mail, Novell NetWare Directory (NDS) or Novell NetWare Bindery, Novell GroupWise, Banyan Systems BeyondMail and Intelligent Messaging, Structured Query Language (SQL)/Open DataBase Connectivity (ODBC) and LDAP-based directory servers such as Netscape, Sun ONE (formerly known as Netscape iPlanet), and X.500-based directories. MMS is a good choice if your Exchange 2003 organization must permanently coexist with a non-Exchange messaging system. However, if you are planning to replace the legacy infrastructure by migrating to Active Directory and Exchange 2003 in the foreseeable future, an investment in MMS might not be warranted.

• Connector for Lotus Notes   If you are connecting Exchange 2003 to Lotus Notes/Domino, but want to send e-mail messages through SMTP instead of using Connector for Lotus Notes, you can keep the directories synchronized using the directory synchronization features that Connector for Lotus Notes provides. You only have to modify the mapping tables for the directory attributes so that Exchange recipients appear as SMTP recipients in Lotus Notes, and Lotus Notes recipients appear as SMTP contacts in Active Directory. For detailed information about how to edit the mapping tables, see Microsoft Knowledge Base Article 303724 "Directory Synchronization Between Notes and Exchange with SMTP Addresses" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=303724).

Calendar Integration

Exchange 2003 maintains free/busy information in a hidden system public folder called SCHEDULE+ FREE BUSY, and it requires a Calendar Connector instance to place free/busy information for non-Exchange users into this system folder. Unfortunately, Calendar Connector is not available when you connect Exchange 2003 to a non-Exchange messaging system through an SMTP connector or an X.400 connector.

You can work around this limitation by using Outlook Internet Free/Busy (IFB) publishing. Outlook users can use this feature to publish free/busy information in a shared location so that other users, who otherwise would not have access to the information, can retrieve it. Outlook users can publish their free/busy times using the Microsoft Office Internet Free/Busy service or at a location in the internal network. When using the Free/Busy service, you can limit access to the published information so that only service members that you specifically authorize can view your information. By default, Outlook updates the free/busy information on the Free/Busy service every 15 minutes, so that it reflects your latest schedule. When other users schedule a meeting with you, the free/busy times that you published to the Free/Busy service are automatically displayed as shaded bars on the Scheduling tab in their meeting request, so that they know at which times you are not available. For more information about the Free/Busy service, go to https://go.microsoft.com/fwlink/?LinkId=25927.

Alternatively, you can publish your free/busy information on an internal server. The advantage of this option is that no service memberships are required. You can use a Web server on the intranet, an internal File Transfer Protocol (FTP) server, or a file server to provide the shared repository. The only difference among these options is the Uniform Resource Locator (URL) that you must specify in your Outlook configuration for the location where free/busy information should be published. You can use any valid URL format, such as: https://, file://\, or ftp://.

Figure 9 shows one possibility for implementing free/busy information sharing in an environment with a non-Exchange messaging system.

Figure 9   Sharing free/busy information between Outlook users in different messaging systems

Publishing free/busy information over the Internet or intranet works well if all users have Outlook. However, IFB publishing is supported only if you use Outlook with the Internet Mail Only option. For information about how to configure Outlook with the Internet Mail Only option, see your Outlook product documentation.

Other messaging clients might also support publishing free/busy information over the Internet or intranet, because IFB publishing is based on an Internet Engineering Task Force (IETF) standard called iCal. IFB publishing is based on the vCalendar standard that is part of iCal and an emerging standard for the format and storage of free/busy information.

If you enable IFB publishing in an Exchange organization where users typically access their mailboxes through the MAPI transport service for Exchange, Outlook will continue to use the SCHEDULE+ FREE BUSY system public folder for all Exchange recipients that are in the server-based address lists. It will not check the Free/Busy service or a shared repository for these server-based accounts in addition. These server-based accounts include all Exchange users and also all non-Exchange recipients that you synchronized with Active Directory.

In other words, IFB publishing works well until you perform directory synchronization. This is because, as far as Outlook is concerned, mail-enabled user accounts and mail-enabled contacts in Active Directory are both recipients in the Exchange 2003 organization for which Outlook does not expect to find free/busy information published at a shared location in the corporate network. IFB publishing does not work because Outlook checks only the SCHEDULE+ FREE BUSY system public folder for non-Exchange users with synchronized recipient objects, but the free/busy information does not exist at this location.

To work around the fact that IFB publishing does not work with Outlook, except with the Internet Mail Only option, you have the following choices:

• Do not perform directory synchronization   If sharing calendar information is more important than providing consistent address lists across all messaging systems, you can choose not to synchronize the directories. However, synchronizing directories is usually required for seamless interoperability, and it is a higher priority than IFB publishing. If you want to provide consistent server-based address lists, you must look for a different solution to provide cross-platform access to free/busy information.

• Save calendar information as a Web page   If you do not want to use the IFB publishing feature, you can publish a one-month snapshot of your calendar with all appointments and meetings to a Web page. However, it is important to note that this method discloses all details about your meetings and other appointments. You are publishing more than free/busy times in this scenario. In addition, the Web page does not automatically update as you add, remove, or revise appointments in your Calendar folder, so you need to save your calendar each time you want to update the Web version.

• Provide access to calendar information through an ASP.NET page   Instead of saving calendar snapshots as Web pages, you can choose to implement a custom solution for free/busy lookups using Exchange programming APIs, such as CDOEX. CDOEX provides a GetFreeBusy method through the IAddressee interface that you can call programmatically in an ASP.NET page or a Visual Basic program. You can also use other programming languages, such as C++ or Microsoft C#. As the name implies, the GetFreeBusy method gets the free/busy information of a valid Exchange 2003 user.

  Note

  CDOEX can only be used directly on a server running Exchange 2000 or Exchange 2003. For this reason, it is best to use the GetFreeBusy method in an ASP.NET page published through Microsoft Internet Information Services (IIS) on an Exchange 2003 server.

  The following Visual Basic .NET code example, taken from the Exchange SDK, demonstrates how to obtain free/busy information for a specified user. You can use this code to provide non-Exchange users with a Web-based solution to access free/busy information of Exchange users. For more information about the GetFreeBusy method, see "Checking Free/Busy Status" (https://go.microsoft.com/fwlink/?LinkId=25928).

  ' Reference to Microsoft ActiveX Data Objects 2.5 Library
  ' Reference to Microsoft CDO for Exchange 2000 Library
  ' Reference to Active DS Type Library
  Function GetFreeBusyString(ByVal strUserUPN As String, _
                             ByVal dtStartDate As Date, _
                             ByVal dtEndDate As Date, _
                             ByVal Interval As Integer) As String
  
     Try
        ' Variables.
        Dim iAddr As New CDO.Addressee()
        Dim freebusy As String
        Dim Info As New ActiveDs.ADSystemInfo()
  
        iAddr.EmailAddress = strUserUPN
        If Not iAddr.CheckName("LDAP://" & Info.DomainDNSName) Then
           Throw New System.Exception("Error occurred!")
        End If
  
       ' Get the free/busy status in Interval minute intervals
       ' from dtStartDate to dtEndDate.
       freebusy = iAddr.GetFreeBusy(dtStartDate, dtEndDate, Interval)
       GetFreeBusyString = freebusy
  
     Catch err As Exception
        Console.WriteLine(err.ToString())
        GetFreeBusyString = ""
     End Try
  End Function
  

  The GetFreeBusy method can be used only to obtain Exchange free/busy information. However, many messaging systems provide Web interfaces for accessing data in mailboxes and public repositories. Check with the vendor of your legacy system to see if a similar API is available, so that you can provide Exchange users with access to calendaring information through a custom Web-based solution as well.

• Configure Outlook to use IFB publishing, but use another solution to access published free/busy information   Another, and perhaps better, option for providing both non-Exchange and Exchange users with access to each other's free/busy information in an ASP.NET solution is to parse the vCalendar files that the Outlook clients can write to a shared directory when IFB publishing is enabled. Publishing free/busy information always works; only the lookup of free/busy information for synchronized recipient objects is a problem for Exchange users. An ASP.NET solution can solve this problem. Exchange and non-Exchange users can configure their Outlook clients to publish free/busy information on a Web server and then use the ASP.NET-based solution as a tool when they book meetings and conferences. Implementing an ASP.NET solution to parse vCalendar files is beyond the scope of this book. For more information, see the Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).

• **Ignore the issue   **Another option is to avoid free/busy integration altogether. If it is possible to migrate teams and departments as one unit, users may not need cross-platform free/busy information. If you migrate all likely meeting candidates to Exchange 2003 at the same time, users can use the standard Outlook feature for free/busy lookups when they plan meetings.