Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
XADM: Requirements for Disabling the Recipient Update Service
Article ID: 296479 - View products that this article applies to.
This article was previously published under Q296479
In certain situations, such as particular hosting scenarios, you may want to disable the Recipient Update Service (RUS), and use scripts or other methods to handle the tasks that are usually performed by the RUS. The purpose of this article is to document the guidelines you must follow, as well as what tasks you must manually perform if you decide to use a custom method in place of the RUS for updating Active Directory objects.
This article covers the following topics:
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 RUSThere 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 PoliciesAll 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 ObjectsIt 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:
Attribute Syntax: single-valued case-insensitive stringproxyAddresses
The legacyExchangeDN is the Exchange 2000-style distinguished name for the object. For example:
/o=Organization/ou=AdministrativeGroup/cn=RecipientContainer/cn=mailNicknameAlthough 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.
Attribute Syntax: multi-valued Unicode stringtextEncodedORAddress
The proxyAddresses 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:
SMTP:email@example.comOnly 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.
Attribute Syntax: single-valued Unicode stringmailNickname
The mail attribute contains the object's primary SMTP address. This attribute does not have an address prefix and only contains the SMTP address. For example:
Attribute Syntax: single-valued Unicode stringdisplayName
The mailNickname 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 UsersIn addition to the preceding attributes, all mailbox-enabled users must have the following attributes properly set:
Attribute Syntax: single-valued Unicode stringhomeMDB
The msExchHomeServerName attribute contains the Exchange 2000-style distinguished name of the server that contains the user's mailbox. For example:
Attribute Syntax: distinguished namehomeMTA
The homeMDB 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 Syntax: distinguished namemsExchUserAccountControlAttribute Syntax: single-valued integer
The homeMTA 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
The msExchUserAccountControl 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:
If msExchUserAccountControl 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 SID
NOTE: 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.
Attribute Syntax: single-valued octet stringNOTE: The targetAddress attribute should not be set on a mailbox-enabled user.
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.
Additional Attributes Required on Mail-enabled Users and ContactsIn 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.
Attribute Syntax: 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 GroupsMail-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.
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 FoldersWhen a public folder is created using a client or Exchange System Manager, the homeMDB, displayName, legacyExchangeDN, mailNickname, 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 PoliciesFor 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.
Attribute Syntax: multi-valued distinguished name
The showInAddressBook 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 MembershipThe 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:
(http://support.microsoft.com/kb/253827/ )XADM: How Exchange hides group membership in Active Directory
Hiding Objects from Address ListsThe 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 attribute.
Maintaining the Membership of the Exchange 2000 Enterprise Servers GroupsThe 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:
For additional information about the Recipient Update Service, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/253838/ )XADM: How the Recipient Update Service applies system policies
(http://support.microsoft.com/kb/253828/ )XADM: How the Recipient Update Service populates address lists
(http://support.microsoft.com/kb/253827/ )XADM: How Exchange hides group membership in Active Directory
(http://support.microsoft.com/kb/253770/ )XADM: Tasks performed by the Recipient Update Service