11.3 Recipient update services

---

The Recipient Update Service (RUS) runs as part of the System Attendant process and, among other functions, is responsible for ensuring that mail- enabled objects appear in the correct address books, including the GAL. The RUS performs this function by populating the necessary AD attributes for mail-enabled objects following initial creation or after modification.

The RUS is very important to Exchange, because you cannot send messages to a newly mail-enabled account until RUS completes the process by stamping the necessary attributes on the object. In some cases, organizations choose not to use the RUS, because they have their own provisioning software that is capable of populating the attributes through an interface such as ADSI. Use of provisioning software is common in ASP environments where you may need to populate even more attributes than normal. For example, you can control access to the GAL for OWA users by setting the msExchQueryBaseDN with the value of the root DN where you want to begin searches (in this case, we assume that the AD contains entries from multiple companies, so you want to restrict access to the entries for a user's own company). Microsoft Knowledge Base article 296479 describes the processing that a provisioning tool must do to replace the RUS.

Two types of RUS operate in an Exchange organization. The first (the enterprise RUS) processes Exchange system objects (such as servers) in the Microsoft Exchange configuration container and permissions for the container as set by the Delegation Wizard; the other (a domain RUS) takes care of recipients in each domain spanned by the organization. Because all servers share a single configuration container across the organization, only one RUS is required to process system-wide objects. However, you need at least one RUS to process recipients per domain, and you may need multiple services if the domain is very large or distributed. During migration periods, when you need to create mailboxes in bulk, it is a good idea to set up multiple recipient update services in the domains that host the mailboxes to spread the load and ensure that the RUS can speedily enable mailboxes.

Figure 11.9 shows an organization with six recipient update services defined. Exchange servers are installed in three separate domains (HPQAP, HPQEU, and HPQNET), and a RUS is configured for each domain, with two additional RUS configured in the HPEU domain, possibly because of the number of accounts that the domain manages. The other RUS (the first in the list) is "Enterprise Configuration" and takes care of the system objects. The properties of the RUS (Figure 11.10) show the domain that it is responsible for, the name of the Exchange server that performs RUS processing, and the name of the domain controller that the RUS uses when it needs to read and write AD data.

Figure 11.9: Recipient Update Services.

Figure 11.10: Properties of a RUS.

RUS operates according to a schedule. It is most common to leave this as "always run," meaning that RUS processes changes to objects as soon as they are available. Other values include run every hour, every two hours, every four hours, never, or according to a preset schedule. The "Never run" option is usually only selected if you need to move RUS processing from one server to another. The "Update Now" option forces the RUS to run immediately to update any waiting objects for the domain. In some cases on Exchange 2000 servers, administrators report that the RUS mysteriously stops stamping new objects, which then means that they cannot begin to process email. The solution to this problem is to restart the System Attendant process.

The Exchange installation procedure creates the RUS for a domain when you install the first Exchange server in the domain. That server automatically hosts RUS processing and starts to maintain the address lists for mail-enabled objects in the domain. At the same time, Exchange selects an available DC to act as the source of AD data for the new RUS. The selected DC must be a GC server. You can move RUS processing to another Exchange server or select another DC by using the "Browse" buttons shown in Figure 11.10. The Exchange help text recommends that you select an Exchange server running on a DC to minimize network overhead. While it is true that such a selection will reduce network demand, best practice for enterprise installations is to avoid running Exchange on a DC, especially GC servers, so an adjusted version of the advice is to select a GC server that is in close network proximity to the Exchange server that hosts the RUS for a domain.

If multiple DCs and Exchange servers exist in a domain, you can divide RUS processing by creating multiple RUS for the domain. For example, if you operate a single worldwide domain with Windows sites in Australia and the United States, you may decide to create separate update services in Australia and the United States to avoid any possibility that RUS is unable to fully activate a newly created account in either location because it is unable to communicate with a remote DC. However, remember that this approach only spreads the processing load across multiple RUS threads: Exchange does not fully create a mailbox until a RUS thread has processed it. If you want a specific RUS to execute immediately, select it from ESM, right-click, and select the "Update Now" option. On the basis that simplicity is better than complexity, do not rush to create multiple RUS for a domain unless this is necessary. AD replication is often complex enough without introducing an increased number of "contributors."

11.3.1 Mail-enabling objects

In concept, the role of the RUS is simple, but in fact a lot of background work goes on to properly process different objects after you add them to the AD. By default, a newly created AD object that you want to be mail enabled does not possess the full set of attributes to allow the user, contact, or group to participate fully in email activities. Some additional processing is required to add the necessary attributes, such as add the object to address lists, add email addresses, and so on. Indeed, the owner of a new mailbox cannot log on and connect to his or her mailbox until RUS completes its work. The exact interval between the time when an administrator creates an account and when a user is able to access his or her mailbox and receive mail depends on AD replication and the interval set for RUS processing; this can take up to 15 minutes. (See Figure 11.11.)

Figure 11.11: Default global address list.

The set of attributes created by the RUS for all mail-enabled objects includes the legacyExchangeDN, all of the different email addresses for the object (SMTP, X.400, etc.) held in the proxyAddresses attribute, the primary SMTP and X.400 addresses, display names, and the mail nickname or alias. The RUS populates a set of additional attributes for mailbox-enabled accounts, including the distinguished names for the home server and Store and the security method to use when checking access to the mailbox. The RUS also defines the server responsible to expand the contents of a distribution group, if required. Table 11.2 lists the different AD attributes that the RUS maintains.

Table 11.2: AD Attributes Maintained by the RUS

Attribute	Use	Mail-Enabled Objects	Mailboxes
LegacyExchangeDN	Connection back to older Exchange objects	X	X
proxyAddresses	SMTP and other proxy addresses such as Lotus Notes (LN), GroupWise (GWISE), and so on. Addresses are stated in the form "prefix:address." The primary SMTP address is prefixed with "SMTP:"; secondary addresses have "smtp:".	X	X
textEncodedORAddress	Primary X.400 address	X	X
Mail	The primary SMTP address	X	X
MailNickname	Object alias. The alias forms part of the URL to point to a user's mailbox.	X	X
DisplayName	Display name (for GAL)	X	X
targetAddress	SMTP address	X (only contacts)	-
msExchHomeServerName	DN for home Exchange server	-	X
homeMDB	DN for home Mailbox Store	-	X
msExchUserAccountControl	Flag to indicate what SID to use when setting or reading permissions	-	X
msExchMasterAccountSID	Master SID for the account	-	X
msExchMailboxGuid	GUID pointing to user mailbox	-	X

Additional attributes are required for mail-enabled groups. For example, you must set the msExchExpansionServerName attribute with the DN of the server that is responsible for expanding group membership. The show- InAddressBook attribute is also required to ensure that objects appear in address lists. This multivalued attribute contains a list of the DNs for all the address lists that include the object. Assuming that you leave the RUS to complete the process of mail-enabling objects, it applies address list policies to determine which address lists an object should be in. The default address list policy ensures that a new mail-enabled object appears in the GAL, but organizations that host multiple companies can create a separate address list for each company that is restricted to the users within the company.

You do not need to change the default Global Address List to hide mailboxes unless you have good reason to exclude a whole set of mailboxes (which you can isolate with an LDAP filter) from the GAL. Instead, you can hide individual objects, including query-based distribution groups, by setting the "Hide from Exchange address lists" property (showInAddress- Book) in the AD, as shown in Figure 11.12. The RUS also takes care of hiding or revealing the membership of distribution groups in the GAL, controlled by the hideDLmembership AD property. If hideDLmembership is set, the RUS sets a security descriptor on the group to allow Exchange servers to be able to expand the contents of the group (and so be able to deliver messages to all the group's members) while the membership remains hidden to clients. Once you create address lists, the RUS ensures that objects appear in the correct lists after they are added, modified, or deleted. Because they are more user friendly and easier to create and configure, the advent of query-based distribution groups in Windows 2003 and Exchange 2003 means that there is now less reason to create additional address lists.

Figure 11.12: Hiding mailboxes and distribution groups from the GAL.

11.3.2 Processing server details

The Exchange Domain Servers and Exchange Enterprise Servers security groups help secure information on Exchange servers. The Exchange Domain Servers group contains all of the Exchange servers in the domain, while the Exchange Enterprise Servers group contains the Exchange Domain Servers group for every domain where an Exchange server is present. These groups are local to each domain and are created by the Exchange installation program when the /DomainPrep process is run. RUS is responsible for the maintenance of the groups afterward. If you run Exchange 2000, you should use the EDSLOCK script (available from Microsoft) to ensure that servers are properly secured against unauthorized access. See Microsoft Knowledge Base article 309718 for further information.

---