XADM: Adding/Removing Recipient Containers to MSMail Dir-Sync

Last reviewed: April 21, 1997
Article ID: Q152935

The information in this article applies to:
  • Microsoft Exchange Server, version 4.0

SYMPTOM

When a Microsoft Exchange Server is participating as a requestor in the Microsoft Mail directory synchronization (dir-sync), entire Microsoft Mail postoffice lists may be removed from the Global Address List (GAL).

CAUSE

When a Microsoft Exchange Server is participating as a requestor in the Microsoft Mail dir-sync, inappropriately adding and removing recipient containers into and out of the dir-sync stream can generate large numbers of dir-sync transactions and potentially result in the accidental removal of entire Microsoft Mail postoffice lists from the Global Address List (GAL).

MORE INFORMATION

This article details how to avoid generating these excess dir-sync transactions in three situations: when exporting Microsoft Exchange users into the dir-sync stream, with Microsoft Mail, and with a link monitor.

Generally, Exchange Server participates as a requestor to the Microsoft Mail dir-sync for the purpose of exporting:

  • Exchange users into the dir-sync stream.
  • Custom recipients (non-Microsoft Mail) into the shared file system (SFS) dir-sync stream.

For administrative and organizational purposes, various recipients may be grouped into specific recipient containers. For instance, all Exchange users within a site may be grouped into one or more recipient containers. Likewise, custom recipients can be logically grouped into recipient containers--for instance, all external SMTP recipient addresses may be grouped into one or more recipient containers.

These recipient containers are added to, or removed from, the Microsoft Mail directory synchronization (dir-sync) stream as follows:

  1. Start the Microsoft Exchange Administrator program, and expand the Site, Configuration, and Connections containers.

  2. Double-click the dir-sync-requestor object, click the Export Containers tab, and modify the Export these Recipients field.

The act of adding these recipient containers to, or removing them from, the Microsoft Mail dir-sync stream results in a large number of dir-sync transactions. Dir-sync messages containing Add, Modify, Delete, or Replace transactions are sent to the dir-sync server (DSS). These messages contain the standard dir-sync transactions, but the transactions can combine in ways that are unexpected.

Exchange Recipient Containers:

By default, new Exchange mailboxes are created in the site’s recipients container. However, an alternate container can specified on the Advanced property page.

Microsoft Mail Custom Recipients Containers:

When a Microsoft Exchange Server system is functioning as a requestor to SFS dir-sync, do not allow custom recipients for users on Microsoft Mail postoffices to be exported from Exchange to the SFS DSS. Only SFS postoffices hosting these users should be sending updates or modifications about their users to the DSS.

If you create custom recipients for Microsoft Mail postoffice users within Microsoft Exchange Server, create these recipients in containers that are not exported (for dir-sync). Additionally, the custom recipients may be hidden or the trust level raised to 100 to prevent them from exporting.

Exporting these custom recipients and/or removing their container(s) from the list of exported recipients can result in Replace transactions for the SFS users' postoffices added to the list of pending dir-sync transactions. This can result in unnecessary dir-sync processing and in the temporary loss of PCMail address information from Global Address Lists (GALS). Subsequent recovery can require large numbers of dir-sync transactions.

Exchange Link Monitor:

When configuring a link monitor to a Microsoft Mail postoffice, the administrator must configure a bogus custom recipient so that the postoffice will be monitored. The link monitor then sends messages to this bogus custom recipient. When the Microsoft Mail message transfer agent (MTA) determines that the user does not exist, a non-delivery report (NDR) is sent back to the link monitor. Reception of the NDR by the link monitor confirms that the link is up and working properly. If no NDR is received within the configured time frame, the link monitor signals that the link is down.

Adding or removing this custom recipient to or from the dir-sync stream can result in a Replace for this user’s postoffice being added to the list of pending dir-sync transactions. During the next T2 cycle, the DSS will process this transaction, effectively instructing all other postoffices participating in dir-sync to remove this postoffice’s entire list from their GALs. This can be resolved by doing a full export from the postoffice that is not currently in the GAL and completing the manual dir-sync process. After performing a full export from the missing postoffice(s), the normal dir-sync cycle should restore the missing addresses.

To avoid this problem, create link monitor recipients in their own container and do not export them into the dir-sync process. Another suggestion is to set the trust level of the custom recipient container to 100 to prevent the recipients from exporting to Microsoft Mail. For more information on link monitors, review Chapter 16 of the Exchange Administrator's Guide. For more information on directory synchronization with other systems (such as Microsoft Mail), review Chapter 14 of the "Microsoft Exchange Server Administrator's Guide."


Additional query words: addresses missing disappear lost link monitor
gone
Keywords : kbinterop XADM
Version : 4.0
Platform : WINDOWS


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 21, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.