Knowledge Base

XADM: Requirements for Disabling the Recipient Update Service

Article ID: 296479

Article Last Modified on 10/28/2006

APPLIES TO

Microsoft Exchange 2000 Server Standard Edition

This article was previously published under Q296479

SUMMARY

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:

Do Not Disable the Enterprise RUS
Applying Recipient Policies
Attributes Required on All Mailbox-Enabled and Mail-Enabled Objects
Additional Attributes Required on Mailbox-Enabled Users
Additional Attributes Required on Mail-Enabled Users and Contacts
Additional Attributes Required on Mail-Enabled Groups
Attributes Required on Mail-Enabled Public Folders
Applying Address List Policies
Hidden Group Membership
Hiding Objects from Address Lists
Maintaining the Membership of the Exchange 2000 Enterprise Servers Groups
References

MORE INFORMATION

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:

legacyExchangeDN
proxyAddresses
textEncodedORAddress
mail
mailNickname
displayName

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

Attribute Syntax: single-valued case-insensitive string

The legacyExchangeDN is the Exchange 2000-style distinguished name for the object. For example:

/o=Organization/ou=AdministrativeGroup/cn=RecipientContainer/cn=mailNickname

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.

proxyAddresses

Attribute Syntax: multi-valued Unicode string

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:user@company.com
X400:c=US;a= ;p=Organization;o=AdministrativeGroup;s=Surname;g=GivenName

SMTP:user@microsoft.com
X400:c=US;a= ;p=Organization;o=Exchange;s=LastName;g=FirstName

Only the primary SMTP address should have the all uppercase "SMTP" address type. Any additional SMTP proxy addresses should begin in lowercase: smtp.

textEncodedORAddress

Attribute Syntax: single-valued Unicode string

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.

mail

Attribute Syntax: single-valued Unicode string

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:

user@microsoft.com

mailNickname

Attribute Syntax: single-valued Unicode string

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:

http://servername/exchange/mailnickname

displayName

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:

msExchHomeServerName
homeMDB
homeMTA
msExchUserAccountControl
msExchMasterAccountSid
msExchMailboxGuid

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

Attribute Syntax: single-valued Unicode string

The msExchHomeServerName attribute contains the Exchange 2000-style distinguished name of the server that contains the user's mailbox. For example:

/o=Organization/ou=AdministrativeGroup/cn=Configuration/cn=Servers/cn=ServerName

homeMDB

Attribute Syntax: distinguished name

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

homeMTA

Attribute Syntax: distinguished name

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

msExchUserAccountControlAttribute Syntax: single-valued integer

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:

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.

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.

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 0x00
  
  For additional information about well-known SIDs, click the following article number to view the article in the Microsoft Knowledge Base:
  
  243330 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.

msExchMailboxGuid

Attribute Syntax: single-valued octet string

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.

NOTE: 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

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:

PREFIX:Address

SMTP:user@externalcompany.com

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 string

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.

homeMTA

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, 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:

mail
proxyAddresses
textEncodedORAddress

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

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 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:

253827 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 attribute.

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:

253838 XADM: How the Recipient Update Service applies system policies

253828 XADM: How the Recipient Update Service populates address lists