XCON: GroupWise Custom Recipients Disappear During Directory Synchronization (316634)



The information in this article applies to:

  • Microsoft Exchange Server 5.5
  • Microsoft Exchange Server 5.5 SP1
  • Microsoft Exchange Server 5.5 SP2
  • Microsoft Exchange Server 5.5 SP3
  • Microsoft Exchange Server 5.5 SP4

This article was previously published under Q316634

SYMPTOMS

Directory synchronization (dirsync) from Novell GroupWise to Exchange Server does not seem to work, and you may experience the following symptoms:
  • All GroupWise custom recipients are automatically removed from the Exchange directory service.
  • You cannot repopulate the Exchange directory service from GroupWise to Exchange Server by clicking Immediate full reload on the Dirsync Schedule tab of the Connector for Novell GroupWise Server_Name Properties dialog box. If you click this option, GroupWise creates an .api file that contains all the objects, but Exchange Server does not recognize the contents of this file.
  • No errors or warnings are logged, even though dirsync is not working as expected.
  • You can use the .api file that was created when you clicked Immediate full reload to create the GroupWise custom recipients on a server that is running Exchange Server and that does not have a directory replication connection to the production environment.
  • After directory replication is established between the production environment and the test system, the custom recipients are replicated, but they disappear after the next import and export cycle.
NOTE: Dirsync from Exchange Server to GroupWise is not affected.

CAUSE

This issue occurs because dirsync from Exchange Server to GroupWise builds a list of GroupWise domains and post offices that are considered GroupWise proxy addresses for Exchange Server sites. DirSync assumes that objects that belong to one of these domains reside in the Exchange directory service and as a result, dirsync does not import the objects from GroupWise to Exchange Server.

To assemble the list of GroupWise domains and post offices, dirsync performs the following steps:
  1. During the export cycle, dirsync scans all recipient containers for objects that are to be exported, including mailboxes and custom recipients. You can configure the recipient containers that are scanned on the Export Containers tab in the Connector for Novell GroupWise Server_Name Properties dialog box.
  2. Dirsync reads the following properties for the objects that are to be exported, and then uses the domain and post office parts of these properties to assemble the list:
    • The primary GroupWise Proxy Address property for Mailbox objects
    • The Target Address property for custom recipients
For example, if the connection between Exchange Server and GroupWise is set up by using default parameters, the GroupWise domain is named "Exchange," and the names of the post offices correspond to the names of the existing Exchange Server sites. For more information, see the Gwconn.rtf file on the Exchange Server 5.5 Service Pack 3 CD-ROM.

The default parameters typically work, but you may have problems if the proxy addresses or target addresses are detected by dirsync. Problems may occur if the following conditions occur:
  • The proxy addresses of Mailbox objects in the Exchange directory service are edited manually.
  • Custom recipients that should be ignored by dirsync are considered (for example, because a Recipients Container is incorrectly added to the list of Export Containers or because the Export custom recipients check box is selected).
If these conditions occur, the domain names and the post office names are added to the list. If any of these names are the same as the names of existing GroupWise domains and post offices, dirsync ignores those objects in the incoming .api files.

Because the list of GroupWise custom recipients is re-created during each dirsync cycle, all the objects that are listed in the .api file and ignored by dirsync are removed from the Exchange directory service during the next dirsync cycle.

NOTE: The decision about which domains and post offices are considered proxies for Exchange Server objects is made for each domain, not for each post office. Therefore, a proxy address that is not correct for a Mailbox object can stop the dirsync process from GroupWise to Exchange Server.

RESOLUTION

This behavior is by design. Exchange Server uses this process to avoid importing objects from GroupWise that is has already exported from the Exchange directory service.

MORE INFORMATION

The information that is used to determine which domains and post offices are considered Exchange Server proxies is stored in the "Targets" section of the <exchroot>\connect\exchconn\dxagwise\gwpcta.tbl file. The "Targets" section typically contains entries for the domain name that GroupWise uses to identify the Exchange Server organization. For example, if default values were used, the "Targets" section might contain "Exchange" as the domain name that GroupWise uses.

If the "Targets" section contains other domain names, especially the names of existing GroupWise domains, there is a problem with the objects that are being exported from Exchange Server to GroupWise. This problem must be identified and resolved, but removing the domain names from the file does not resolve the issue because the file is rewritten during each outgoing dirsync cycle. There are two known causes of this problem:
  • One or more Mailbox objects that are exported from Exchange Server to GroupWise do not have the correct primary GroupWise proxy address. You must correct the proxy address to resolve the issue.
  • Custom recipients that should be ignored by dirsync are exported. This issue occurs because Recipient Containers are incorrectly marked as Export Containers or because the Export custom recipients check box is selected.

Modification Type:MinorLast Reviewed:4/25/2005
Keywords:kbprb KB316634