Exchange LDAP MA Continually Deletes and Re-Adds Objects with Commas in the Relative Distinguished Name (318157)

SYMPTOMS

If the following two conditions exist, objects may be continually deleted and re-added in later runs by the Cdir_ldp.exe tool and the Microsoft Exchange LDAP Management Agent (MA):

The Object has a comma in the relative distinguished name (also known as RDN) portion of the Distinguished Name in Exchange. This will occur if a comma is added to the directory name for newly created mailboxes on the Exchange Server.
The MA is running in Delta mode.

The following example is an example of an Import Delete Delta Transaction in the Import File for an object that meets these conditions:

-LDAPOBJECTDEL: DEL
-dn: cn=CA\,Farmer,cn=Recipients,ou=PSS,o=Microsoft,ma=MA Exchange,DsaName=MMSServer,ou=Applications,dc=microsoft,dc=com

RESOLUTION

To resolve this problem, make a change in the metaverse construction template file (Imp.st) from this

$CSP.dn = cn=$v_rdn(,$parent("$v_dn"))(,$MA))

to this:

$CSP.dn = $v_dn(,$MA())

How to Change the Code in the Metaverse Construction Template

Use Compass, and log on as an administrator.
View the appropriate MA.
On the left side of the screen, click Design MA.
Click the Control Metadirectory tab.
Click the Construction Template tab.
Click the Metaverse tab.
Locate the following text in the template at line 256, and note that this is for the default template:
$CSP.dn = cn=$v_rdn(,$parent("$v_dn"))(,$MA))
Modify that line of code to:
$CSP.dn = $v_dn(,$MA())
Click OK to save the changes.

MORE INFORMATION

Microsoft does not typically recommend that you modify the default code. For additional information about this topic, click the article number below to view the article in the Microsoft Knowledge Base:

318227 Continual Deletions and Additions Occur With Exchange Server LDAP Management Agent

However, for the special case of relative distinguished names that contain a comma, you can modify the default code.

To cope with the comma in the relative distinguished name portion of the object's Distinguished Name (DN), Cdir.ldp runs a denormalizing function and adds an escape character "\" to the object's connector space DN for the object in MMS. When Exchange Deltas are then used to update the metadirectory, Cdir_ldp.exe reads the Exchange server and the corresponding Exchange MA's connector space to make a comparison between the objects. If the $CS.DN and the $CD.DN do not exactly match, Cdir_ldp.exe believes that the object has been deleted, and a delete transaction is then written to the import file. On the next delta run, the object is discovered by Cdir_ldp.exe, and an Add transaction for the same object is written to the import file. The template code change that is listed earlier in this article resolves this problem.

As an example, this problem is explained by showing how the DN exists in connector space and how the DN exists in Exchange.

Example of the Connector Space Record

cn=CA\,Parmar,cn=Recipients,ou=Bamanbor,o=Microsoft,ma=MA Exchange Pepsi,DsaName=MMSServer1,ou=Applications,dc=microsoft,dc=com

Using Ldp.exe Against the Exchange Server

Expanding base 'cn="CA,Parmar",cn=Recipients,ou=PSS,o=Microsoft'... 
Result <0>: (null) 
Matched DNs: 
Getting 1 entries: 
>> Dn: cn="CA,Farmar",cn=Recipients,ou=PSS,o=Microsoft
objectClass: organizationalPerson; person; Top;
rdn: CA,Farmar;
cn: Farmar,CA; 
distinguishedName: cn="CA,Farmar",cn=Recipients,ou=PSS,o=Microsoft; 
Hide-From-Address-Book: FALSE; 
rfc822Mailbox: CA.Farmar@intl.microsoft.com; 
mail: CA.Farmar@intl.microsoft.com; 
textEncodedORaddress: c=US;a= ;p=microsoft;o=PSS;s=Farmar;g=CA;; 
otherMailbox: MS$PSS/MMS/CAFARMAR; 
x500$/o=Microsoft/ou=PSS/cn=ROW/cn=CA.Farmar; 
Company: Microsoft; 
mailPreferenceOption: 0; 
department: PSS; 
givenName: CA; 
Home-MTA: cn=Microsoft