Duplicate SMTP Addresses Through the Exchange LDAP MA (302757)

SYMPTOMS

When you create new user objects through LDAP, the SMTP uniqueness check in Exchange 5.5 is bypassed. When you try to edit an object in Exchange 5.5 after you create new user objects by using LDAP, you may receive an error message that indicates that a duplicate address exists even though you may not be changing any e-mail addresses.

CAUSE

In Exchange, a duplicate SMTP address has been created by LDAP that bypasses the normal checks for uniqueness. The duplicate address may be in either the primary SMTP reply address (MAIL), or in one of the proxy addresses (OTHERMAILBOX) of another user object. This often occurs when you create user objects in Exchange 5.5 through MMS. MMS does not generate an error message when the duplicate SMTP address is created.

MMS enforces the uniqueness of the SMTP address within its own database. However, when objects are sent to Exchange 5.5 through the Exchange LDAP MA, duplicate SMTP addresses may be created within Exchange. This is because MMS does not contain all of the objects from the Exchange GAL or because changes have been made to an Exchange object and these changes have not been updated in MMS.

As an example, if the discovery phase excluded containers of user objects from being updated into MMS, then objects that are created by MMS in Exchange have the potential for address duplication.

WORKAROUND

To work around this problem for the primary SMTP reply address, discover everything in the Exchange GAL so that all addresses are represented within MMS. This means you do not apply exclusion rules to the DISCOVER phase. Any users that you don't want to appear in the MMS Metaverse can be stored in the connector space. To do this:

Remove any Exclusion rules for Exchange containers that you want discovered.
In Design MA, Control Metadirectory, Construction Templates, Metaverse, add an IF statement to store the MAIL attribute in the Connector Space for those objects that you would have excluded from discovery. Consider the following example for user objects from the BAD RECIPIENTS container:
```
IF $EMBEDDED("BAD RECIPIENTS",$v_dn)=T
THEN
    $csp.mail=$cd.mail
ENDIF
							
```
This code stores the MAIL attribute in the connector space so that MMS can process a uniqueness check.
Discover the BAD RECIPIENTS container (if you choose not to have it appear in the Metaverse, run the MA in Association mode for this specific run). Everything from this run remains only in the connector space.

This stores the MAIL attribute in the connector space so that MMS can process uniqueness checks. Be sure to only insert the MAIL attribute in the connector space for those objects that will not be part of the metaverse. If you attempt to add the MAIL attribute in both the connector space and the metaverse for the same object, the additions will not work.