The Recipient Update Service and Linked Value Replication

Lately I’ve seen a lot of questions regarding the use of homeMDB in policy filters. I want to use this post to explain the reason that ExBPA warns about this, and hopefully clear up the confusion about how to address this.


Linked Value Replication is a feature that was added to Active Directory in Windows 2003. The point of LVR is that when a DN-linked attribute is changed, only the changes need to be replicated. For instance, instead of replicating a list of all members every time group membership is changed, it can replicate only the DNs that are added or deleted. LVR is also used for certain single-valued attributes, including homeMDB.


A quirk of LVR is that a replication packet contains two separate lists of changes – one list of regular attributes and then a separate list of linked attributes. When a DC receives such a replication packet, the non-linked attributes are applied first, with all non-linked attributes on the same object being applied in the same transaction. Once all non-linked attributes for all objects in the packet have been applied, it moves on to processing the linked attributes. This means that in a large replication packet, there can be a delay between the time the non-linked values are updated and the time the linked values are updated for the same object. This delay is what causes unexpected RUS behavior for the system policies and, possibly, recipient policies.


Let’s cover the system policies first. The point of the system policies are to stamp certain required attributes, such as homeMDB, on objects that are missing those attributes. There’s a particular system policy which is affected by this problem, and that’s the Mailbox Enable User policy. The filter that is placed on this policy by Exchange setup will match any user who has both mailnickname and any one of either homeMDB, homeMTA, or msExchHomeServerName.


If you consider this for a moment, you begin to understand the problem. Let’s say a user is mailbox-enabled on a DC other than the one the RUS points to. The user object will have to be replicated over for the RUS to evaluate it. When the RUS DC receives the incoming replication packet, the AD replication engine is going to write non-linked values to the object before writing homeMDB to the object. In a large replication packet on a heavily loaded DC, there can be a significant delay (10-20 seconds or more) after mailnickname and msExchHomeServerName get committed to the object before homeMDB is committed.


So let’s say there’s a 20-second window during which the object only has the non-linked values that were just committed. What happens if the RUS evaluates the object during this time? Well, it has a mailnickname and msExchHomeServerName, so it matches the Mailbox Enable User policy. But at this time the object appears to be missing the required homeMDB attribute. So the RUS stamps homeMDB with the first mailbox store it finds for that server, overwriting the homeMDB value that replicated in with the object.


This is why LVR can result in mailboxes being inadvertently rehomed to different stores than the ones on which they were created. The fix is to change the filter on the Mailbox Enable User policy so that this policy only matches user objects that already have a homeMDB value. This is explained in the following ExBPA article: . This is also discussed in KB903291.


LVR is only a problem for recipient policies when you have policy filters based on LVR attributes such as homeMDB. All the values that are not subject to Linked Value Replication (like mailnickname or msExchHomeServerName) replicate together. You don’t have to worry about stamping something wrong if you base your filters on those types of values. Sure, you might stamp a user with proxyAddresses before the homeMDB value comes over, but who cares? When you base filters on LVR values like homeMDB, that’s the situation where you end up making wrong decisions.


Consider this situation. I have a user with the following attributes:


Dn: newUser

Mailnickname: newuser

HomeMDB: CN=Mailbox1,…

extensionAttribute1: special value


I have two recipient policies with the following filters:


Policy1: (&(mailnickname=*)(extensionAttribute1=special value))

Default Policy: (&(mailnickname=*))


Now, newUser replicates over to the DC the RUS points to. The RUS happens to look at the user before he has fully replicated, so we only have values that are not subject to LVR. But it doesn’t matter. Mailnickname is there, and extensionAttribute1 is there, so we make the right decision. Now change it to where you have these two policies:


Policy1: (&(mailnickname=*)(homeMDB=CN=Mailbox1,…))

Default Policy: (&(mailnickname=*))


NewUser replicates over to the DC the RUS points to. The RUS happens to look at the user before he has fully replicated, so we only have values that are not subject to LVR. So the first time the RUS looks at the user, he matches the Default Policy (because we only have mailnickname). So boom, he gets stamped with the wrong policy.


Because the Default policy matches any object with mailnickname, the Default policy is always going to match a partially-replicated object. Since a filter based on LVR attributes will not be able to match a partially-replicated object, you run the risk of getting objects stamped with the Default policy when you base the other policy filters on LVR attributes.


The fix for this problem is, of course, to change the recipient policies to not use homeMDB or other attributes that are subject to LVR. This is described in the following ExBPA article: .


I hope this clears up any confusion on the use of homeMDB in recipient policies. If you have any questions, post ’em in Comments!


Bill Long

Comments (10)
  1. Thanks Bill – excellent blog entry! I only have one question about this: why ist homeMDB a linked value? What’s the advantage?

  2. Bill Long says:

    Hi Christian,

    HomeMDB and certain other attributes are linked values so that their corresponding backlink values can be automatically generated by the AD. That is, HomeMDB is a linked value so that HomeMDBBL on the mailbox stores can be calculated automatically by the AD and reflect all the users who point to that store. It’s similar to the type of relationship that exists between the Member and MemberOf attributes, except for homeMDB it’s a one-to-many relationship instead of many-to-many. This is in contrast to other DN-valued attributes such as HomeMTA. If you look at the MTA object which is referred to by a HomeMTA attribute, you’ll notice that there’s no backlink for all the users that point to it, because HomeMTA is not a linked value.

    From a replication standpoint, there’s no real benefit to having a single-valued linked attribute replicated via LVR. It’s just that the design of LVR is such that the AD does not distinguish between single-valued and multi-valued linked attributes. They are all replicated by the same mechanism.

  3. Bill,

    thanks for bringing "light into the dark…"! :-)

  4. Xavblog says:

    Thank you Bill for your very good article.

  5. Anonymous says:

    Today this list is longer, since I hadn’t the time to post it last week. Sorry…

    Exchange on NAS:…

  6. Anonymous says:


    Recipient Update Service en Exchange 2000 y Exchange 2003

    Parte II – Seguimiento de problemas…

  7. Iona says:


    What about policies that come over from 5.5, where the legacyExchangeDN attribute is used?  Is that attribute affected by all of this as well?

  8. Bill Long says:

    Hi Iona,

    legacyExchangeDN is a string-valued attribute, so using it in filters is fine. Only DN-valued attributes can be affected by this, and only those DN-valued attributes that are linked – that is, where a backlink attribute exists on the associated object.

Comments are closed.