The Microsoft Exchange Server Recipient Update Service (RUS) is responsible for generating mail proxy addresses for mail-enabled objects inside an Exchange organization. Typically, this service requires little or no changes to its default settings. Still, there are situations in which a tweak or two might benefit your implementation, and if you know how the RUS does its magic, you'll be ready for action.
Getting the Mail Through
Exchange 2000 Server and later depend on Active Directory (AD). To mail-enable a user, contact, public folder, message store (i.e., database), or group (including Exchange Server 2003's query-based Distribution Groups—DGs), you must create new attributes for the corresponding AD object. Windows populates some of these attributes (e.g., the attribute that specifies the distinguished name—DN—of the mailbox store that houses the user's mailbox) when you create or edit a mail-enabled object through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. But an object doesn't become a fully mail-enabled Exchange object until the RUS detects that you've created or updated the object in AD. The RUS examines the new or changed object and applies the appropriate recipient policy to populate any missing attributes and to ensure that the object has at least one valid email address.
Currently, the most basic email address for an Exchange object is the SMTP address, which the mailbox uses to communicate over the Internet. Users might need other addresses, called proxy addresses, to connect to IBM Lotus Notes or X.400 systems or to send and receive faxes. To generate proxy addresses for mail-enabled objects, the RUS refers to recipient policies, which determine the type and format of addresses that the mail-enabled object needs. In Exchange Server 5.5 and earlier, the closest functional component to the RUS was site addressing defaults. The big difference between these components is that site addressing defaults is limited to objects belonging to the site, whereas the RUS and the recipient policies that it processes apply throughout the organization and are much more flexible in terms of the objects to which the policies can apply.
AD holds a mail-enabled object's addresses in a multi-valued string attribute called proxyAddresses, in the format type:address (e.g., SMTP:[email protected]). Figure 1 shows the properties of a mail-enabled AD object. Note that some entries in the Type column are in uppercase. When an address entry's Type is in uppercase, Exchange regards that address as the primary address for that type. There can only be one primary address per type; Exchange uses that address as the default reply address for outgoing messages. Entries with lowercase Type values are deemed to be secondary addresses, which Exchange checks when it resolves the header on an incoming message to determine whether the message can be delivered to a mailbox within the organization. You can create a secondary address only when the object already contains a primary address of the same type. In addition, every user object must have a primary SMTP address (similar to the Exchange 5.5 requirement that every object have an X.400 address).
Companies that have been through a merger or a renaming or rebranding process often need to preserve old email addresses as secondary SMTP addresses so that external correspondents can continue using the old addresses. Over time, you might end up removing these old addresses (if only to reduce spam), but leaving them in the AD object's properties does no harm. You might also see secondary addresses used for special purposes. Exchange Mailbox Manager uses the MBX address type to track the mailboxes that it processes; Exchange uses the X500 address type to track old email addresses that might still exist in user mailboxes but that are no longer used inside the organization. For example, the Exchange 5.5 Move Server Wizard changes the DN of mailboxes as servers move between sites or organizations. The AD (through the Active Directory Connector— ADC) preserves these addresses so that users can reply to old messages that hold old addresses in their headers.
Apart from generating the correct addresses for mail-enabled objects, the RUS also ensures that the objects appear in the correct address lists. You want user objects, contacts, and groups to appear in the Global Address List (GAL), but you probably don't want public folders or message stores to appear there. The RUS hides the latter objects unless you specifically mark their properties to instruct the RUS to include them in the GAL. (A hidden object's msExchHideFromAddressList attribute is set to TRUE.) The RUS also populates a certain set of AD attributes, which Table 1 lists, that must be set if mail-enabled objects are to function correctly. As I mentioned earlier, some of these attributes are populated automatically when you create a mail-enabled object through the Active Directory Users and Computers snap-in. The RUS fills in any missing or incomplete attributes to ensure that all the necessary data exists to allow mail to flow smoothly. In addition, when the RUS finds a group that has hidden membership, the RUS adds non-canonical access control entries (ACEs) to the group object's ACL. These entries let Exchange servers expand the group membership for mail delivery, while preventing users from viewing the expanded data.
Each email address must be unique across the entire Exchange organization. When you create an address through the Email Addresses tab of a user object's Properties dialog box, Active Directory Users and Computers calls the appropriate proxy-generation DLL for the address's type, to ensure that the address is properly formatted. At the same time, the DLL generates an LDAP query that determines whether the proposed address is unique. (This process accounts for why creating new user-object email addresses can sometimes be slow within large deployments.) The policies that the RUS applies ensure that the addresses that it generates are properly formatted. The RUS also performs checks for address uniqueness.
Behind the Scenes
Because of its association with mail-enabled objects and address lists, the RUS used to be called the Address List Service. This old name is reflected in the name of the component that the RUS uses for debugging and diagnostics: MSExchangeAL. The RUS runs this component as part of the Exchange System Attendant process (the RUS code is included in the WLDAP32.dll component). By default, the RUS wakes up once a minute to check its schedule. If the schedule permits, the RUS queries AD for changes that might affect address lists. The most basic example of such a change is the addition of a new mail-enabled user object; another example is a change that affects a mail-enabled object's address-list membership. The RUS detects such changes by running an LDAP query that discovers any updates to mail-enabled objects. The RUS then applies the applicable recipient policies to populate any missing required attributes and to incorporate the change into the necessary address lists.
The RUS identifies mail-enabled objects by looking for AD objects that have a value in the mailNickname attribute (aka the alias, in Exchange 5.5 terms). The AD keeps track of all changes made to the directory and allocates to each a unique change number, which it writes into the object's USNchanged attribute, as Figure 2 shows. The LDAP query to find updates is straightforward: Find all objects that have a completed mail nickname with a USNchanged value greater than the USNchanged value that existed the last time the RUS ran its check. If you want to see this query in action, increase diagnostics logging for the MSExchangeAL object to maximum and look for event ID 8011 in the Application log. This event reports the LDAP query that the RUS generates, including the USNchanged values.
One way to measure the RUS's update speed within any environment is to use Active Directory Users and Computers to create a mail-enabled object, then see how long it takes for email addresses to appear in the object's properties. In most cases, the addresses should appear in less than 5 minutes (2 minutes if your organization spans only a few servers). A longer period is an indication that the RUS isn't functioning smoothly.
From a user's perspective, the net effect of RUS activity is the appearance of a new object in the GAL. The length of time it takes for a new object to appear in the GAL depends on the organization's AD replication topology because AD must replicate updated attributes to the Global Catalog (GC) server to which a client connects before the client can use the new data. Of course, if a user uses Microsoft Office Outlook 2003 in Cached Exchange Mode, he or she won't see the new mail-enabled objects in the Outlook Address Book (OAB) until Exchange has had a chance to generate a new version of the OAB and until the user downloads the necessary changes to the OAB's local copy.
Configuring the RUS
When you install the first Exchange 2000 or later server in an organization, Exchange creates two default RUS instances in the Exchange\Recipients\Recipient Update Services configuration container. The first instance, Recipient Update Service ( Enterprise Configuration), has an organization-wide scope. This RUS instance takes care of objects that appear in the Exchange organization's configuration (e.g., message stores). The second instant has a domain-wide scope and takes care of mail-enabled user, contact, group, and public folder objects that belong to the domain in which the Exchange server resides. As you install additional Exchange servers in other domains within the forest, Exchange automatically creates new domain RUS instances for those domains (if they don't already exist). If a domain contains no Exchange server but includes objects that are mail-enabled (e.g., user objects with mailboxes on Exchange servers in another domain), you'll have to run the Exchange Setup /domainprep option on a domain controller (DC) in that domain to prepare the domain to host mail-enabled objects, then manually create a RUS for the domain.
You can create multiple RUS instances for a domain as long as each service is associated with a different DC, which the service uses as the source for AD updates. Spreading update activity across multiple RUS instances is a good idea when a domain is widely distributed and you're unsure of the speed of AD replication. Of course, no Exchange deployment can function effectively if AD replication is unreliable, so if you run into this situation, first fix the problems with AD replication, then centralize RUS activity as much as possible. Figure 3 shows the RUS instances for HP, one of the world's largest Exchange 2003 deployments (the GAL contains well over 250,000 entries). As you can see, apart from the default Enterprise Configuration service, there is only one service for each of the three geographically-oriented domains that contain Exchange servers.
Figure 4 shows the properties of an individual RUS. These properties are straightforward. The Domain field contains the name of the AD domain that this service processes. The Exchange server field specifies the host Exchange server on which the service runs, and the Windows Domain Controller field specifies the DC to which the service connects. Logically, it makes sense for the Exchange server and the DC to be as close to each other as possible (in network terms) so that they can always connect. If you select an Exchange server and a DC that aren't well connected, the LDAP queries that the RUS depends on might time out or suffer other network glitches—a situation that can cause the RUS to become unpredictable and have a subsequent ill effect on the accuracy of the directory.
The final piece of information on the RUS's Properties dialog box is the Update interval. This field's value defaults to Always run. At this setting, the RUS checks the nominated DC every minute. Typically, this default value is appropriate and sufficient to handle the number of changes that occur within an average organization. If you want to control updates more tightly, you can customize the update interval so that the RUS runs every 15 minutes, every hour, or whichever interval you choose. Note that the Update interval setting controls the RUS's wakeup interval. As soon as the RUS wakes up, it processes any outstanding changes. If your company doesn't use the RUS to update email addresses, you can create a schedule for each domain RUS instance such that those instances never run. However, you should maintain the schedule for the Enterprise Configuration to let the RUS take care of system objects' attributes.
As I mentioned earlier, if users run Outlook 2003 in Cached Exchange Mode, they won't see updates until they download an updated OAB, which Exchange typically generates once a day. If this is true of all your users, running the RUS (for each domain that hosts an Exchange server) every 2 hours or so might be sufficient. If you need to force a domain RUS to check for changes immediately, you can open ESM, right-click the RUS, then click Update Now. This option sets the value of the RUS object's msExchReplicateNow attribute to TRUE. When the RUS wakes up to see whether it should run, it finds the attribute is set and starts. After running, the RUS resets the attribute to FALSE.
Ready for RUS
The RUS doesn't take much care and feeding, especially in small organizations. Even left alone with its default settings, the service will plug along nicely, generating and maintaining email addresses for mail-enabled objects. Still, you can make adjustments to the service's configuration to tweak the RUS for your environment. Just be sure you understand how the service works before you begin.
