After helping someone on the problem related to this not that long ago - I decided it might be good to blog about this a bit more; there might be more people that are running into this problem and it is not one of most obvious ones either!
During ADC replication, sometimes ADC needs to write an attribute that is a link to another attribute in the directory. These are called DN-linked attributes. You cannot write a value to a DN-linked attribute unless the object to which you are linking exists.
Suppose that a user is a member of a distribution list in Exchange Server 5.5. When you set up ADC, if the user replicates after the distribution list, ADC is unable to set the member attribute on the group before the user exists. ADC uses two attributes, unmergedAttributes and msExchUnMergedAttsPT, to store the unresolvable link on the group until it is able to resolve the user and add it to the member attribute.
That tells us that essentially - if ADC has problems populating the attribute with the specific value (let's say HomeMDB or HomeMTA) - because it can not find that object in the directory (in this case - the database or the MTA server object) - the values will be written into the unmergedAttributes and msExchUnMergedAttsPT attributes instead (which attribute will depend on which directory the values are being written into). In order to see if you have those attributes, you would need to get the Admin dump of the object from the 5.5 directory or the LDP dump of the object and check there.
In order to see the actual attribute value in LDP tool, you should connect and bind to your DC and then go to Options > General and then under "Value parsing" choose "Binary" rather than "String". Then get the LDP dump of the object that has the unmerged attribute again, and you will be able to see what the attribute contains. Do not forget to switch back to "String" parsing or you will be looking at strange looking dumps from that point on. :)
Why would this happen?
Two cases for this we see mostly in Support Services are:
Config_CA replication problems - the Config_CA connection agreement is what replicates configuration objects (servers, stores, connectors etc) back and forth between SRS and AD. If your Config_CA does not replicate correctly, you can have a situation where let's say Exchange 5.5 directory does not know of the new Exchange 2003 server's mailbox store and MTA object. So then - if recipient CA tries to replicate a new Exchange 2003 mailbox to 5.5 directory, the ADC will not be able to link the HomeMDB and HomeMTA attributes to anything on the 5.5 side as - 5.5 directory simply does not know about them. You will then have unmergedAttributes and mailflow or other problems.
Permissions problems - the permissions issues can be there in both directories, 5.5 or AD. The accounts that are used to connect to 5.5 and AD directories should have adequate permissions to read objects from the target directory. For Exchange 5.5, this means permissions on the site usually. For Active Directory, this means having both permissions on the domain/OU where the accounts need to be created or modified AND having Exchange View Only permissions on the administrative group that the user we are replicating is from. If this is not there - the account will have rights to deal with most of the attributes on the AD object but not necessarily mailbox-related attributes too!
Okay! I figured it out and fixed the underlying problem - now what?
ADC tries to re-resolve the links periodically. ADC will try to resolve the links under the following circumstances:
- MsExchDoFullReplication=True (the "Replicate the entire directory the next time the agreement is run" checkbox on the connection agreement's Schedule tab is checked)
- msExchReplicateNow=True (you force the connection agreement to "Replicate now" by right-clicking on it and choosing that option)
- Every 12 hours during a connection agreement uptime
ADC uses the msExchADCGlobalNames attribute to resolve links. For example, to add User1, whose Exchange 5.5 distinguished name is "cn=user1,cn=Recipients,ou=Site,o=Org", a group in Active Directory, ADC uses an LDAP query to find the matching object. The query is: (msExchADCGlobalNames=EX5: cn=user1,cn=Recipients,ou=Site,o=Org*).
If the user does not have msExchADCGlobalNames in the target directory, ADC cannot resolve the link.
Hope this was helpful and made sense! If you are an Exchange 5.5 administrator and are now looking for a more basic "primer" on ADC or even AD - please check this out.