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 mailNickname@domain.com (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 user@abc1.net, 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.
Prev. page
[1]
2
next page 
