XFOR: DXA appends 001 only when needed

Last reviewed: September 2, 1997
Article ID: Q166545
The information in this article applies to:
  • Microsoft Exchange Server, version 5.0
  • Microsoft Exchange Server, version 4.0

SYMPTOMS

After including Microsoft Exchange Server in the Directory Synchronization process of your MSMail environment, some Display Names are appended with 001. This behavior can be seen whether your Microsoft Exchange Server is acting as the DirSync Server or a DirSync Requester.

CAUSE

In any one given MSMail postoffice, all display names (friendly names) must be unique. An MSMail postoffice may have multiple display names the same in its Global Address List (GAL). For example:

   Bob SmithNET1/PO1/BSMITH
   Bob SmithNET2/PO2/BSMITH

The above would be perfectly legal in one MSMail postoffice but the following would not:

   Bob SmithNET1/PO1/BSMITH
   Bob SmithNET1/PO1/BSMITH2

The above is illegal. Neither ADMIN.EXE nor IMPORT.EXE would allow the second Bob Smith to be created.

Microsoft Exchange Server on the other hand will allow multiple objects to have the same display name. Due to this, the Microsoft Exchange Directory Synchronization Service (DXA) must ensure that it does not send the same display name to any one MSMail postoffice.

WORKAROUND

A new registry value is now available that will change this behavior as described in the MORE INFORMATION section below. The registry value to set is:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

  1. Run the Registry Editor(Regedt32.exe).

  2. Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey:

          \SYSTEM\CurrentControlSet\Services\MSExchangeDX
    

  3. Add the following case-sensitive DWORD value of 0:

          Unique Display Names
    

  4. Quit Registry Editor.

After setting the registry parameter above, the following steps MUST be performed.

  1. Stop the Microsoft Exchange Directory Synchronization Service

  2. Delete the contents of the DXADATA subdirectory. Do not delete the directory, only the contents of the directory.

  3. If the DXA is acting as the DirSync Server, using the Microsoft Exchange Admin utility, choose each Remote Requester object one by one and check the 'Export on next cycle' checkbox on the general tab. This will force a full DirSync export to be sent to each Remote Requester.

    If the DXA is acting as a DirSync Requester, using the Microsoft Exchange Admin utility, choose the DirSync Requester object and check the 'Export on next cycle' checkbox on the settings tab. this will force a full DirSync export to be sent to the DirSync Server.

  4. Start the Microsoft Exchange Directory Synchronization Service

STATUS

For Microsoft Exchange Server version 4.0 servers:

A supported fix is now available, but has not been fully regression-tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next Service Pack that contains this fix. Contact Microsoft Technical Support for more information.

For Microsoft Exchange Server version 5.0 servers:

This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

MORE INFORMATION

How does the DXA keep track of what it has sent to the MSMail postofffices?

The DXA keeps what we call a mappings database (XDIR.EDB) in the DXADATA directory of the Microsoft Exchange Server. Within this mappings database is kept a list of all transactions that have been sent by the DXA. The four values kept for each transaction sent are the objects:

   USN-Changed
   Display Name
   Email-Addresss (the one that was sent)
   Obj-Dist-Name

Behavior with registry parameter listed above set to 1 or non existant:

When a new DirSync transaction is about to be sent, the XDIR.EDB is checked to see if it has sent this friendly name before. If so, the Obj-Dist-Name of both objects are compared to see if this is the same object being sent again. If so, we update the USN-Changed value and send the transaction as is else we append the 001 to the friendly name.

Behavior with registry parameter listed above set to 0.

When a new DirSync transaction is about to be sent, the XDIR.EDB is checked to see if it has sent this friendly name before. If so, is this the same address type (IE, X.400, MS, SMTP etc.) If so, is the address type MS (MSMail). If not, append the 001. If so, is it the same NETWORK/PO name. If so, append the 001 else do not append the 001.


KBCategory: kbbug kbhotfix kbusage
KBSubcategory: Exchange XFOR
Keywords : kbbug5.00 kbfix5.00.sp1 XFOR kbusage
Version : 5.0 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: September 2, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.