The Exchange Recipient Update Service

The Exchange Server Recipient Update Service (RUS) is important to the overall health of your messaging environment. In small organizations, the RUS often stays in the background. However, if you work with large or complex deployments, you're likely to find yourself trying to cope with multiple recipient policies or wishing you understood why the RUS doesn't do quite what you'd expect it to do. Whatever your situation, understanding how recipient policies work, whether to force the RUS to perform a rebuild, and which problems you're likely to run into can help you keep things running smoothly.

Recipient Policies
The RUS searches for Active Directory (AD) updates on a scheduled basis, then takes action to ensure that the objects it finds can receive email. When you edit a mail-enabled object's properties and select the Automatically update e-mail addresses based on recipient policy check box (on the E-mail Addresses tab of the object's Properties dialog box), as Figure 1 shows, the RUS determines which recipient policy to apply to the object, then carries out the instructions that the policy contains. Some deployments, such as hosted application service provider (ASP) or ISP installations, opt not to use the RUS to generate email addresses. Instead, these organizations, which often have a multiplatform directory-provisioning and -synchronization process in place, might choose to use a third-party program or utility. This approach is acceptable as long as the chosen program updates AD with the information necessary to let Exchange route and deliver messages.

Exchange creates a default recipient policy when you install the first server in an organization. Because SMTP is the basic routing mechanism for Exchange, this default policy ensures that every mail-enabled object has an SMTP address and uses the format [email protected] (where domain.com is derived from the AD forest that contains the Exchange organization). The value of the mailNickname attribute is unique within an organization, so this policy is sufficient to generate unique email addresses. Small organizations might decide to leave the default policy in place, but most large organizations prefer to follow the generally accepted first_name.last_name@domain format for SMTP addresses. You can easily create a new recipient policy to instruct the RUS to create addresses in that format, then give the new policy precedence over the default policy so that the RUS processes the new policy's instructions first. Note that Microsoft recommends that you create a new policy rather than change the default policy (for reasons mentioned in the Microsoft article "How to customize the SMTP e-mail address generators through recipient policies" at http://support.microsoft.com/?kbid=285136). This is good advice: Clearly separating organization-specific settings from default values is always a wise approach.

To create a new recipient policy, open Exchange System Manager (ESM), right-click the Recipient Policies container (under Recipients), then select New from the context menu. An effective recipient policy will include a Lightweight Directory Access Protocol (LDAP) filter that the RUS will use to identify the objects that the policy affects and will specify the format of the proxy email addresses that the RUS will create for these objects.

To create the LDAP filter, go to the General tab of the policy's Properties dialog box and click Modify. You can then build a suitable filter, selecting the type of objects you want to target and the attributes you want to use for the filter. Figure 2 shows a completed LDAP filter. In this example, the RUS will look for objects with a nonblank mailNickname attribute and will consider all object categories; note the filter rules that reference the objectClass types such as user and contact, and the objectCategory type msExchDynamicDistributionList (a query-based distribution list—DL). This new policy is similar to the default policy, which also selects any object of any class so long as the object has a nonblank mailNickname attribute. The difference between the new policy and the default policy can be seen in the new policy's final filter rule, which includes department=HQ: The new filter is applicable only to objects that have a value of HQ in the department attribute. Note that for best performance, you should always use exact matches for LDAP filters. If you create a filter that forces the RUS to execute a search across many attributes for values that begin with text strings, server performance will suffer.

To specify the proxy email address formats that the RUS will create, go to the E-Mail Addresses (Policy) tab. As Figure 3 shows, this tab lists the different formats that are available within the organization. In this example, I've elected not to create proxy addresses for CCMAIL (i.e., Lotus cc:Mail), MS (i.e., Microsoft Mail), or NOTES (i.e., Lotus Notes) because the users affected by the policy don't use those email systems. The two remaining formats—SMTP and X400 (i.e., X.400)—are essential within an Exchange organization. (SMTP is now the default messaging protocol for Exchange, but X.400 is still deeply embedded in the product.) You can see from the figure that the SMTP format will create addresses using the first_name.last_name@domain format. Once an object has a valid proxy address, you can always send email to the object by using that address. For example, if you know that a new user object has an SMTP address of [email protected], you can send email to that address and Exchange will route it correctly—even if the object doesn't appear in the GAL (because AD replication isn't complete or because you haven't downloaded a new Offline Address Book—OAB). This is useful because unless an object is hidden, it must appear in at least one address list for Messaging API (MAPI) clients such as Outlook to locate it. You can even send messages to recipients that have been hidden in the Global Address List (GAL), as long as those recipients have a valid SMTP proxy address. Many administrators use this technique to send messages to recipients that they know are hidden.

A large organization might necessitate many recipient policies. However, try to manage with as few as possible, to avoid complexity and confusion. Each recipient policy has a priority within the Recipient Policies container: The RUS processes the policies in order from highest to lowest priority. To alter the policy order, right-click a policy in ESM, select All Tasks, then select Move Up or Move Down. The default policy should always have the lowest priority and function as a catch-all policy to instruct the RUS how to process objects that no other policy covers.

When active, the RUS looks for AD updates (by comparing AD objects' USNchanged values to find those that have changed since its previous run) and ignores objects that haven't changed. Therefore, when you create a new policy or modify an existing policy, you might assume that the RUS is intelligent enough to automatically revalidate email addresses across the organization to ensure that every address complies with the new policy. Don't make that mistake! To immediately activate a new or changed policy, you must right-click the policy in ESM and select Apply this policy now from the context menu. (When you create or edit a policy, ESM will remind you to take this step, as Figure 4 shows.) Note that you'll need to apply not only the new or edited policy but all the policies that might be affected by the changes you've made. Because recipient policies reside in a container at the organization level, you need Exchange Administrator permission for the organization to apply the policies.

Rebuilds
Rather than apply individual policies or wait for the RUS to process updates, some administrators might consider forcing the RUS to rebuild the address lists for a domain. However, you should approach this action cautiously, especially if your organization uses an external program to generate email addresses and resynchronize them with AD. Because the RUS knows nothing about the processing that external programs perform, the RUS could end up allocating addresses that are under the control of the external program, leading to duplicate email addresses and message delivery failure.

When you tell the RUS to rebuild the address lists for a domain, you force it to reset the value of the USNchanged attribute to 1; this action then causes the RUS to process every mail-enabled object in the domain. Processing will start at the next scheduled interval unless you follow the Rebuild command with the Update Now command, in which case the processing will begin immediately. As you can imagine, executing the necessary LDAP queries and other required processing can take some time on domains that have tens of thousands of mail-enabled objects. In some deployments, a rebuild can take well over a day to finish, even when the Exchange server and domain controller (DC) involved in the operation are tightly coupled. Rebuild operations also generate a lot of work for the servers that are involved and keep the network busy accommodating the LDAP queries and AD replication traffic that results from the rebuild. All in all, I don't recommend performing a rebuild unless you are certain that doing so is the only way to fix a problem with an address list, such as a persistent failure to flush invalid or obsolete information from the GAL or to show new and updated information in the GAL.

During the rebuild process, Exchange sets the RUS object's msExchDoFullReplication attribute to TRUE, then resets this attribute to FALSE after all processing is completed. This step prevents administrators from attempting to start several concurrent rebuild operations (possibly because they don't see any obvious evidence that the rebuild is in progress). If a RUS rebuild would cripple your organization, you can restrict permissions on this attribute to prevent anyone other than an enterprise administrator from updating its value.

Problems
In general, if you take the precautions I've explained to create effective recipient policies, the RUS will hum along nicely with no intervention on your part. Now and then, however, you might run into problems. Knowing ahead of time what to watch out for can make solving these problems less painful.

The most basic problem you're likely to encounter is that new mail-enabled objects don't appear in the GAL or other address lists. This problem indicates that the RUS hasn't been able to process the objects. One likely cause is an erroneous recipient policy. Another is that the DC specified in the RUS is unavailable for some reason (e.g., network problems, temporary downtime). Lags in AD replication are another potential cause, especially if updates appear in some but not all places within the organization. Investigate all these possibilities and fix any underlying problems before rushing to perform a rebuild.

The Microsoft article "Proxy addresses are not removed when the recipient policy is removed in Exchange Server" (http://support.microsoft.com/?kbid=286302) describes an interesting problem: When you remove a recipient policy, the RUS doesn't remove proxy addresses that it created under the policy. This problem is probably because Microsoft never included scan-and-remove functionality in the RUS specifications. You must manually remove these addresses from AD; the article tells you how to do so.

Lack of knowledge about the RUS can cause problems, too. For example, if an administrator experiments with and inadvertently applies a recipient policy, user email addresses can wind up being changed. Exchange doesn't warn you of a new policy's potential impact, nor does it show you the difference between the current policy and a new policy, so you must depend on your knowledge of the organization to assess the effect a new policy will have. Again, be especially careful of any change to recipient policies if your organization doesn't rely on the RUS to generate email addresses automatically; in such a situation, a change to a recipient policy is likely to conflict with whatever process you use to generate addresses.

Lastly, if you want to go through event logs to understand how the RUS works in your organization, be forwarned: Debugging and diagnostics for the RUS are a complex business. You'll find a copious amount of relevant information in the event logs, but this information can be difficult to interpret. Fortunately, you can find a great three-part article on the subject on the Microsoft Exchange Team Blog "You Had Me at EHLO" (http://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx).

Prioritize and Prepare
An administrator's art is often boiled down to prioritization: knowing which tasks you need to spend time on and which you typically can leave alone. With a little initial attention, the RUS will usually fall into the latter category, managing nicely on its own. But preparation—knowing what the RUS does and how—is also invaluable, just in case trouble (e.g., problems with email addresses, message delivery, or new objects that don't appear in the GAL) comes knocking.