Recipe3.7.Installing Additional Recipient Update Service Instances

Recipe 3.7. Installing Additional Recipient Update Service Instances

Problem

You need to ensure that additions, deletions, and changes to mail-enabled objects are updated in the GAL in a timely fashion, even in domains with no Exchange servers or where large numbers of directory changes are common.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the Recipients container, then the Recipient Update Services container.
Check the list of existing RUS instances. There should be one labeled Enterprise Configuration, as well as at least one for each domain in the forest in which an Exchange server has been located.
Right-click on the Recipient Update Services folder or in the Detail pane and select New Recipient Update Service.
Select the domain in your forest you wish this RUS instance to service and click Next.
Select the Exchange server you want this RUS instance to be hosted on. It does not need to be in the same domain and click Next.
Review the information. A DC in the domain will be selected for this RUS instance to connect to. If you are satisfied, click Finish to create the RUS instance.
Ensure that the new instance shows up in the listing.

Discussion

The RUS is the component of Exchange that watches over changes to the various mail-enabled objects, recipient policies, and address lists in the domain to make sure that all changes are visible in a timely fashion. By default, there is one Enterprise Configuration instance for the entire organization, as well as one for each domain in which an Exchange server has been installed. If there is no RUS instance corresponding to a domain (as would be the case in certain Exchange deployments) then no recipients can be created in that domain unless you stamp the attributes yourself.

Each instance is tied both to a specific DC and a specific Exchange server. There can only be one RUS per DC (with the sole exception of the Enterprise Configuration instance), but an Exchange server can host multiple RUS instances (each of which will take a small amount of processor and memory resources). In a mixed Exchange 2000/2003 organization, instances may be hosted on either version of Exchange.

Normally, Exchange will add RUS instances as needed. However, if you have a large AD domain that spans multiple sites and network latency is an issue, you might consider installing additional instances so that there is at least one per site. This ensures that updates, no matter where they are generated, are quickly reflected in the organization address lists. However, in some environments this introduces problems with duplication of proxy addresses; a better general approach is probably to reduce the replication latency between sites first, and if that doesn't work, add more RUS instances.

Another case that requires the manual configuration of RUS instances are domains that will host mail-enabled objects, but do not have an Exchange server installed within them. A somewhat common example of this situation is the placeholder root domain configuration. In this instance, this also gives the benefit that Exchange servers can make use of GCs in the root domain in the event that none are available in the child domains.

In theory, the addition and removal of RUS instances is scriptable via ADSI; MSDN documents the MS-Exch-Address-List-Service-Container class in the AD schema. This class is the base of all RUS instance containers. In practice, there are a formidable number of properties that must be configured with the appropriate GUIDs for various servers and domain; these linkages are not documented and there are no methods provided in the various scripting interfaces to create or manage RUS instances themselves.

Since you can easily add RUS instances for your entire organization through the same node in ESM, and since these assignments should be relatively stable, stick to using ESM to manage your RUS instances.