The following are guidelines and tasks that are usually handled by the RUS. If you choose to set the schedule of the Domain RUS to Never, your process must perform all of these functions.
Do Not Disable the Enterprise RUS
There are two types of Recipient Update Services. One is responsible for processing Exchange 2000 system objects in the Configuration container, and the other is responsible for processing recipients in each domain. There is only one of the first type in the entire Microsoft Windows 2000 forest because there is only one Configuration container. This is the Enterprise RUS, and it should not be disabled. This also means that you should not delete the default recipient policy, because the Enterprise RUS needs it to process objects in the Configuration container.
Applying Recipient Policies
All mailbox-enabled and mail-enabled objects must have a minimum set of attributes properly set to enable all Exchange 2000 components to function properly. Some of these attributes are common to both mailbox-enabled and mail-enabled objects, and some are specific to either mailbox-enabled or mail-enabled objects.
Attributes Required on All Mailbox-enabled and Mail-enabled Objects
It is important to understand the difference between a mailbox-enabled user and a mail-enabled user or contact. A mailbox-enabled user actually stores messages on the Exchange 2000 server in the Exchange 2000 information Store. A mail-enabled user or contact is a reference to an address that is outside of the Exchange 2000 organization. Mail-enabled users do not have any storage space on the Exchange 2000 server; they are an easy way to send mail to a destination outside of the local Exchange 2000 organization. A user can be either mailbox-enabled or mail-enabled, but not both. Contacts can only be mail-enabled; they cannot be mailbox-enabled.
You must set the following attributes on all mail-enabled or mailbox-enabled objects:
The following is a brief explanation of the proper formatting of these attributes. It is not intended to be a complete specification for the correct formatting of the attributes.legacyExchangeDN
: single-valued case-insensitive string
is the Exchange 2000-style distinguished name for the object. For example:
Although the Lightweight Directory Access Protocol (LDAP) syntax of this attribute is a case-insensitive string, it is recommended that you use lowercase letters for the delimiters such as "o," "ou," and "cn", and that you preserve the case of the organization and administrative groups. The organization and administrative group names should match the values of your organization and administrative group that are held in Active Directory. If this is a mixed Exchange 2000 and Microsoft Exchange Server 5.5 organization, make sure that the values you set are consistent with the existing objects from the Exchange Server 5.5 directory.
: multi-valued Unicode string
attribute holds all the e-mail addresses that may be used to send mail to this recipient. The format for this attribute is PREFIX:proxy
, where PREFIX
is either SMTP, X400, GWISE, NOTES, or another address type. At a minimum, a mail object must contain an address of type X400 and SMTP. Additional secondary proxy SMTP addresses or other address types may also be included, if the system attendant can generate the proper address type. A generic and specific example of a valid SMTP and X400 entry are:
Only the primary SMTP address should have the all uppercase "SMTP" address type. Any additional SMTP proxy addresses should begin in lowercase: smtp.
Attribute Syntax: single-valued Unicode stringmail
The textEncodedORAddress attribute contains the primary X.400 address, which is also contained in the proxyAddresses field. The format of the X.400 address is the same as the format used in proxyAddresses.
: single-valued Unicode string
attribute contains the object's primary SMTP address. This attribute does not have an address prefix and only contains the SMTP address. For example:
: single-valued Unicode string
attribute is similar to the Alias
, or UID
, field in Exchange Server 5.5. The attribute has a maximum length of 64 characters. If the object is mailbox-enabled, the mailNickname
attribute is also used to generate the URL to access the mailbox. For example, a URL would be in the format of:
Attribute Syntax: single-valued Unicode string
The displayName attribute contains the display name of the object as it appears in the Global Address List and any other address lists that the object is a member of.
Additional Attributes Required on Mailbox-enabled Users
In addition to the preceding attributes, all mailbox-enabled users must have the following attributes properly set:
The following is a brief explanation of the proper formatting of these attributes. It is not intended to be a complete specification for the correct formatting of the attributes.msExchHomeServerName
: single-valued Unicode string
attribute contains the Exchange 2000-style distinguished name of the server that contains the user's mailbox. For example:
: distinguished name
attribute contains a distinguished name link to the Mailbox Store that contains the user's mailbox. The value of this attribute must exactly match the distinguished of the Mailbox Store object in Active Directory. For example:
CN=MailboxStoreCN=StorageGroup,CN=InformationStore,CN=ServerName,CN=Servers,CN=AdministrativeGroup,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Attribute SyntaxmsExchUserAccountControlAttribute Syntax
: distinguished name
attribute contains a distinguished name link to the message transfer agent (MTA) on the server that contains the user's mailbox. The value of this attribute must exactly match the distinguished name of the MTA object in Active Directory. For example:
CN=Microsoft MTA,CN=ServerName,CN=Servers,CN=AdministrativeGroup,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
: single-valued integer
attribute is used by the information store to determine whether to use the objectSid
or the msExchMasterAccountSid
when setting or reading information store permissions. This attribute has two possible values:
- 0: This is an enabled user
- 2: This is a disabled user
The terms "enabled user" and "disabled user" only refer to whether the Microsoft Windows NT user account can be used to log on to the domain or not. The RUS is responsible for automatically updating this value whenever a user account is created, enabled, or disabled. You also need to ensure that the value of msExchUserAccountControl
is set when the user is mailbox-enabled, and updated if a user is enabled or disabled. The RUS determines this value by checking the second bit (0x2) of the userAccountControl
value. If the 0x2 bit is not set, the account is enabled. If the 0x2 bit is set, the account is disabled.
is set to 0, this is an enabled user account, and the information store references the objectSid
of the user when it is reading or setting information store permissions. If msExchUserAccountControl
is set to 2, this is a disabled user, and the information store references the security ID (SID) set in msExchMasterAccountSid
when it is reading or setting information store permissions.msExchMasterAccountSidAttribute Syntax
: single-valued SIDNOTE
: The RUS does not set msExchMasterAccountSid. This attribute is populated by either the Active Directory Connector (ADC), or when an administrator grants a user the Associated External Account right in the Mailbox Rights of a user. This article mentions the msExchMasterAccountSid attribute because of its relationship to other attributes that the RUS populates.
If the user account is a disabled user, and hence msExchUserAccountControl
is set to 2, the msExchMasterAccountSid
attribute must be populated. If msExchUserAccountControl
is set to 0, the msExchMasterAccountSid
value must not be populated. This attribute has two possible categories of values, depending on how the mailbox associated with this user will be used.
- If the mailbox is a resource mailbox, msExchMasterAccountSid should contain the well-known Microsoft Windows 2000 SID, "Self," also called "Principal Self."
- The definition of a resource account is a disabled user account that is not used to actually log on to the domain, but is instead a placeholder for a mailbox to which other users within your Exchange 2000 organization have delegated rights.
- You cannot grant a resource account permission to access other resources.
- The Self SID can be set as the msExchMasterAccountSid on multiple resource accounts because the Self is not an actual SID, but a way to reference the objectSid for the object on which it is set, which will always be unique.
- The hexadecimal value of the Self SID is:
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x05 0x0a 0x00 0x00 0x00For additional information about well-known SIDs, click the following article number to view the article in the Microsoft Knowledge Base:
Well known security identifiers in Windows Server operating systems
- If the mailbox is owned by a user that is outside of the local Windows 2000 forest, msExchMasterAccountSid should contain the SID of that external user account.
- In this case, the disabled user account is also not used to log on directly, but instead this configuration allows a user outside of the forest to own an Exchange 2000 mailbox within your organization.
- The foreign user account may be either a Windows 2000 user from a separate forest, or a Windows NT 4.0 user account.
- If the value of msExchMasterAccountSid is the SID of an external account, the value must be unique. You may not have more than one disabled user account with the same SID in msExchMasterAccountSid in the entire forest.
- The msExchMasterAccountSid attribute should not point to a security principal (User or group) that is in the local forest, with the exception of foreign security principals.
- The external account specified in the msExchMasterAccountSid attribute should also have "Full Mailbox Access" rights granted in the Mailbox Security Descriptor.
- The SID must be written in a binary format, not security descriptor definition language (SDDL) format.
Attribute Syntax: single-valued octet stringNOTE
When you create a mailbox-enabled user, you must set the msExchMailboxGuid value to a globally unique ID (GUID) in binary format. The GUID in msExchMailboxGuid will be set as the GUID of the mailbox object within the Exchange 2000 information store. After the information store object is created, this value is how the system determines that the information store object is linked to the directory object. The msExchMailboxGuid should not be changed after you initially set it. Changing the msExchMailboxGuid on an existing mailbox-enabled user disassociates that user with the mailbox object in the Exchange 2000 information store.
: The targetAddress
attribute should not be set on a mailbox-enabled user.
Additional Attributes Required on Mail-enabled Users and Contacts
In addition to the preceding attributes, all mail-enabled users and contacts must have the targetAddress
attribute properly set.
The following is a brief explanation of the proper formatting of this attribute. It is not intended to be a complete specification for the correct formatting of the attribute.targetAddress
: single-valued Unicode string
The value of the targetAddress
attribute is the address of the user that is outside of the local Exchange 2000 organization that mail should be sent to. When mail is sent to the mail-enabled user or contact, the mail is redirected to the address held in the targetAddress
field. The format of the field is similar to the format used in the proxyAddresses
field. The following are general and specific examples of targetAddress
Additional Attributes Required on Mail-enabled Groups
Mail-enabled groups only need the attributes required on all mailbox-enabled and mail-enabled objects. There are two optional attributes that you can use to set the expansion server for the group if you so choose. However, the RUS is not responsible for setting these, nor will the RUS update one if the other is already set.msExchExpansionServerName
Attribute Syntax: single-valued Unicode stringhomeMTA
The msExchExpansionServerName attribute contains the Exchange 2000-style distinguished name of the server that is responsible for expanding the group membership of this mail-enabled group for mail delivery. The syntax of this attribute is similar to msExchHomeServerName above.
Attribute Syntax: Distinguished Name
The homeMTA attribute contains a distinguished name link to the MTA on the server that is responsible for the expansion of this group's membership. The syntax of this attribute is the same as the homeMTA.
Attributes Required on Mail-enabled Public Folders
When a public folder is created using a client or Exchange System Manager, the homeMDB
, and targetAddress
attributes are already set.
You may need to properly set the following attributes on the public folder object to send mail directly to the public folder:
Applying Address List Policies
For mailbox-enabled and mail-enabled objects to appear in the Global Address List and any other address lists, the RUS usually applies each address list policy to each object to determine which address lists an object should be a member of. When the RUS determines that a user should be a member of a Global Address List or address list, it adds the distinguished name of that Global Address or address list to the showInAddressBook
attribute on the mailbox-enabled or mail-enabled object. If the RUS is disabled, you must manually set the showInAddressBook
attribute on your mailbox-enabled and mail-enabled objects.showInAddressBook
: multi-valued distinguished name
value is a link to each Global Address List or address list that the mailbox-enabled or mail-enabled object is a member of. This is a multi-valued attribute, so an object can be a member of more than one address list. However, an object is usually only a member of one Global Address List. The following is an example of a possible value for showInAddressBook
CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Hidden Group Membership
The RUS is responsible for handling the hiding and revealing of group membership when the viewing the properties of a mail-enabled group from a mail client. If the Boolean attribute hideDLMembership
is set to TRUE, the RUS stamps a special non-canonical security descriptor on the group object in Active Directory to ensure that the Exchange 2000 servers can access all attributes of the group, but normal users will not be able to view the membership of the group.
If the RUS is disabled, and you plan on using the hideDLMembership
attribute, you must manually set the security descriptors on groups depending on whether hideDLMembership
is TRUE or FALSE. You must also update the security descriptor if the value of the hideDLMembership
attribute on the group changes.
For additional information concerning the format of the security descriptors on groups with hidden membership, click the following article number to view the article in the Microsoft Knowledge Base:
XADM: How Exchange hides group membership in Active Directory
Hiding Objects from Address Lists
The RUS is responsible for monitoring the value of the Boolean attribute mxExchHideFromAddressLists
, and if the value is TRUE, it removes all address lists from the showInAddressBook
attribute on the mailbox-enabled or mail-enabled object. Subsequently, if the value of msExchHideFromAddressLists
later changes, the RUS repopulates the showInAddressBook
attribute for the object.
If you plan to use the msExchHideFromAddressLists
attribute, you must manually populate or clear the showInAddressBook
attribute on the object depending on the state of the msExchHideFromAddressLists
Maintaining the Membership of the Exchange 2000 Enterprise Servers Groups
The RUS is responsible for maintaining the membership of all of the Exchange 2000 Enterprise Servers groups in the forest.
When you run setup /domainprep
in a domain or install the first Exchange 2000 server in a domain, two groups are created:
- Exchange Domain Servers
This group contains all of the Exchange 2000 servers in the local domain.
- Exchange Enterprise Servers
This group contains the Exchange 2000 Domain Servers group for every domain that has an Exchange 2000 server installed, or for which setup /domainprep has been run in the domain
Whenever new Exchange Domain Servers and Exchange Enterprise Servers groups are created in a new domain, the RUS is responsible for performing the following tasks:
- Add the all of the existing Exchange Domain Servers groups to the Exchange Enterprise Servers group in the new domain.
- Add the Exchange Domain Servers groups from the new domain to all the existing Exchange Enterprise Servers groups in the forest.
You must maintain the Exchange Enterprise Servers group membership manually for all domains when you disable the domain Recipient Update Services.
For additional information about the Recipient Update Service, click the following article numbers to view the articles in the Microsoft Knowledge Base:
XADM: How the Recipient Update Service applies system policies
XADM: How the Recipient Update Service populates address lists
XADM: How Exchange hides group membership in Active Directory
XADM: Tasks performed by the Recipient Update Service