The address list or the recipient policy filter is not applied when it is based on group membership or an attribute that the Recipient Update Service is responsible for

Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 let administrators create and associate address lists and recipient policies with specific accounts, based on specific criteria. For example, if you are an administrator, you can create and associate an address list based on the Company attribute of an object so that only objects that have a company name "Microsoft" are displayed in the address list.

If you specify the criteria by using a filter that is based on group membership or that is based on attributes that the Recipient Update Service is responsible for, the behavior of the address list or of the recipient policy may be inconsistent. For example, if a user is added to a group after the address list or the recipient policy is created, that user may not be displayed in the address list or have the recipient policy applied to it.

The Recipient Update Service is responsible for populating address lists and applying recipient policies. The Recipient Update Service accomplishes this task by processing mail-enabled objects and comparing them against the filter criteria to see if they should be associated with an address list or a recipient policy.

If an object matches the criteria for a particular address list, the distinguished name of the address list is added to the showInAddressBook attribute on the object. The showInAddressBook attribute is a multiple-valued attribute on the mail-enabled object that has links to the distinguished name of each global address list (GAL) and address list that the object is a member of. If an object matches the criteria for a particular recipient policy, other attributes are updated.
For additional information about the attributes that are updated when address lists or recipient policies are associated with objects, click the following article numbers to view the articles in the Microsoft Knowledge Base: The Recipient Update Service processes the updates to the object attributes. The Recipient Update Service only processes objects in the following cases:

• The object changes.
• The recipient policy or address list that applies to the user changes.
• An administrator right-clicks a Recipient Update Service, and then clicks Rebuild.

When you add a user to a group, the user object does not change. Only the group object changes. Therefore, the Recipient Update Service does not process the user object again after it is added to a group. This behavior occurs because the memberOf attribute on the user is a backlink. A backlink attribute is not actually stored in the Active Directory directory service. It is instead calculated "on-the-fly," based on its corresponding forward-link attribute. When you query Active Directory for a backlink on object X, Active Directory does a query for (forward-link=X). In this case, memberOf is the backlink, and the Member attribute on the group object is the forward link. Therefore, when you query Active Directory for the memberOf attribute for user X, Active Directory actually searches for (member=X).

If the memberOf attribute on a user is changed, the object is not actually changed. Additionally, the memberOf attribute on a domain controller that is not a global catalog does not report memberships that are not in the local domain. For the memberOf attribute to report all group membership for that user, you must query against a global catalog.

To avoid this behavior, use one of the following procedures:

• Do not use backlink attributes, such as memberOf, to define the filter for address lists or recipient policies. Instead, use non-calculated attributes, such as Company.
  
  If you do use a backlinked attribute in the filter for an address list or for a recipient policy, you must either modify a non-calculated attribute on the user, or you must force a rebuild of the Recipient Update Service. This forces the service to process the object.
• In the filter, do not use attributes that the Recipient Update Service is responsible for stamping. For example, do not use proxyAddresses, mail, and textEncodedORAddress in a recipient policy or address list filter. If you use these attributes, the Recipient Update Service is prevented from correctly processing objects because the attribute it filters on to process the object is also an attribute that it is responsible for stamping. Unless you force a rebuild of the Recipient Update Service, it may never process the objects.
  
  To test for this condition, view the filter property of the address list. Determine if the filter contains one of the attributes that the Recipient Update Service is responsible for stamping, such as the "E-mail Address Field" (proxyAddresses=*) field. If this is the case, you can remove it by using one of the following methods:
  • Delete any address list that contains such a filter. Then,re-create it with the same name but use a different filter criteria. If you use this option, make sure that the deletion has replicated to all Domain Controllers before you re-create the object.
  • Use the Active Directory Service Interfaces (ADSI) Edit tool to access the address list object's properties. Under "Select a property to view," click "purportedSearch." You can change the filter by just removing the attributes that you do not want to filter on.

This behavior is by design.