How the Recipient Update Service applies system policies

The Recipient Update Service has three system policies that are installed by default when you install Exchange 2000. They are the Mail-Enabled Recipient, Mailbox-Enabled User, and Hidden DL Membership. All have the same purpose of updating a few attributes on each entry under certain circumstances.

The idea behind the system policies is to let people write their own tool to add and edit Users, Groups, Contacts, and so on. To make the creation of these tools more simple, the Recipient Update Service takes part of the responsibility, filling gaps where a tool might have missed creating something, which would cause other services to not work properly.

For a mail-enabled recipient, there is a minimum set of attributes that is required to make all Exchange components work properly. For example, a mail-enabled entry (user, contact, group, public-folder, and so on) needs to have at least these attributes: mailNickname, legacyExchangeDN, and displayName. Without the mailNickname attribute, an object is not considered mail-enabled. After you have a mailNickname attribute, the other two attributes must be set.

Mail-Enabled Recipient Policy

If the Recipient Update Service identifies that a new entry was added or modified that does have the mailNickname attribute, but that does not have the legacyExchangeDN or displayName attributes, it tries to create those attributes.

The displayName attribute is copied from the mailNickname attribute as is, and the legacyExchangeDN attribute goes through an algorithm that identifies the organization and administration group for this entry, and then creates a value in the following format:

Mailbox-Enabled User Policy

For a Mailbox-Enabled User, two attributes need to be present. The first is the mailNickname attribute, and second is one of the following three attributes:

• msExchHomeServerName
• homeMDB
• homeMTA

If any of these three attributes is present and the user has a mailNickname attribute, it is considered to be a Mailbox-Enabled User. However, this is true only when you have not changed the purportedSearch attribute of a Mailbox-Enabled User. If you have changed the purportedSearch attribute to "(&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))", the Recipient Update Service will consider an object a mailbox-enabled object if the mailNickname and homeMDB attributes are stamped on a user. Based on the mailNickname and homeMDB attributes, the Recipient Update Service will try to populate other attributes. For more information, click the following article number to view the article in the Microsoft Knowledge Base: In this case, the Recipient Update Service tries to populate some attributes if they are not present. They are:

• msExchHomeServerName
• homeMDB
• homeMTA
• legacyExchangeDN
• displayName
• msExchMailboxGuid

These are populated in the following order:

1. If the msExchHomeServerName attribute is not present, it will be created based on the homeMDB or homeMTA attribute, depending which one is present. If it cannot be created, the process stops.
2. After the msExchHomeServerName attribute is set, the homeMDB and homeMTA attributes are populated if either is missing. If you have multiple messaging databases (MDBs) or message transfer agents (MTAs) on your server, it picks the first one that it finds doing an Active Directory search, so it can be considered a random choice.
3. To create the legacyExchangeDN and displayName attributes, it follows the same steps that are used for a Mail-Enabled Recipient.
4. Finally, if the msExchMailboxGuid attribute is not present, it will be created by generating a random globally unique identifier (GUID).

Hidden DL Membership Policy

For the "Hidden DL Membership" system policy, it runs not only when a new entry, such as a Security or Distribution Group, is created, but when you modify the status of the hideDLMembership attribute.

If this attribute is set to TRUE, the Recipient Update Service adds a non-canonical part to the security descriptor, which prevents anyone from viewing the "member" attribute for that entry. This will apply to any type of client searching the directory, through Messaging Application Programming Interface (MAPI) or Lightweight Directory Access Protocol (LDAP).

If the attribute is set to FALSE, it removes the non-canonical security descriptor, exposing the "member" attribute again.

For additional information about hiding group membership, click the article number below to view the article in the Microsoft Knowledge Base: