Another great post on the MS team blog…
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: http://www.microsoft.com/technet/prodtechnol/excha...7.mspx . 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: http://www.microsoft.com/technet/prodtechnol/excha...7.mspx .
I hope this clears up any confusion on the use of homeMDB in recipient policies. If you have any questions, post ’em in Comments!
Source: http://blogs.technet.com/exchange/archive/2006/03/...8.aspx
) If you can say yes to this you might want to have a closer look a 
