Reliable RUS

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.

End of Article

   Previous  1  [2]  Next