News Stay informed about the latest enterprise technology news and product updates.

Exchange Recipient Update Service and proxy addresses

In this tip from "15 tips in 15 minutes: Managing recipients and distribution lists," you'll learn about the primary functions of the Recipient Update Service and how to control the update Interval for a RUS instance.

The Recipient Update Service has responsibility for applying proxy addresses in Recipient Policies to target objects in Active Directory. To prevent conflicts, only one Exchange server in each domain can use RUS to perform updates. You can select this server, and configure other RUS parameters using ESM.

Drill down under Recipients to find the Recipient Update Services folder. In the right pane, you'll find at least two objects, one for Enterprise Configuration and one for each domain with an Exchange server. Figure 5.36 shows an example.

5.36
Figure 5.36 Recipient Update Service folder in ESM showing two RUS instances, one for Enterprise and one for the domain. (Click on image for enlarged view.)

You are reading tip #8 from "15 tips in 15 minutes: Managing recipients and distribution lists," excerpted from Chapter 5 of the book Learning Exchange Server 2003, published by Addison-Wesley Professional.
The Enterprise Configuration item controls the application of policies to system accounts for the Exchange servers. The domain item (or items) controls the application of policies to mail-enabled objects in the specified domain.

Note the Domain Controller and Exchange Server columns for each item. These columns list the Exchange server where RUS runs and the name of the domain controller where RUS sends its LDAP requests. Open the Properties window for the RUS instance to change the server selections and the update interval. Figure 5.37 shows an example.

Before taking an Exchange server offline, check first to see if it hosts a RUS instance. Exchange does not automatically select a new Exchange server to host RUS for a domain if the current server becomes unavailable. You must make this selection manually from the Properties window of the RUS instance. Click the Browse button next to Exchange Server and select another server that is operational and centrally located in your organization.

5.37
Figure 5.37 RUS instance properties showing server selected to run RUS instance, domain controller selected as the update server, and the update interval.(Click on image for enlarged view.)

RUS intervals

RUS does not wait in the wings for you to change a recipient policy so it can leap out and apply the change. It wakes up periodically, does its chores, and then goes back to sleep. You can control the Update Interval using the setting in the Properties window for a RUS instance.

By default, Exchange sets the Update Interval for a RUS instance to Always Run, meaning that RUS fires once a minute.

You can select a longer update interval for RUS, but use caution. RUS has other duties in addition to applying recipient policies. For example, RUS also applies address list parameters to mail-enabled objects. If you set an Update Interval of four hours, new recipients will take quite a while to get those address list settings, which delays their appearance in the GAL.

RUS and multiple domains

If you have more than one domain, you'll notice that ESM shows a separate RUS icon for each domain. This relates to the way Active Directory uses naming contexts. The users, groups, and contacts you normally deal with are stored in a Domain naming context, and the Exchange server running RUS must communicate with a domain controller in that domain.

Exchange system objects reside in the Configuration naming context. The Enterprise Configuration thread of RUS takes care of updating their proxy addresses.

Forcing a Recipient Policy update

You can force RUS to update Active Directory objects by right-clicking the RUS instance in ESM and selecting either Update Now or Rebuild from the flyout menu, shown in Figure 5.38.

description of image
Figure 5.38 RUS instance update options, Update Now or Rebuild.(Click on image for enlarged view.)

These selections look simple, but they initiate an intricate set of processes. I'm warning you about this right up front, not to scare you away, but to keep you from wondering, "Why is he making this seem so darned complicated?" It actually is darned complicated.

Standard updates

Let's start with the default way RUS works. Every so often, RUS fires up and gets ready to do its thing. Remember that RUS runs on an Exchange server, so it starts by querying a domain controller for any objects that have been updated since the last time it ran.

Let's say you recently added a mail-enabled user called New User1 with a logon name of newuser1. RUS gets the name of that object and then performs an evaluation based on the Recipient Policies. Just for the sake of argument, let's say that only the Default Policy applies to this object. RUS sends an LDAP write request to Active Directory that assigns an SMTP and an X.400 proxy address based on the policy. In this case, that would be an SMTP address of newuser1@company.com and an X.400 address of c=US;a= ;p=Company;o=Phoenix;s=newuser1;g=Phoenix. (The user is in the Phoenix OU of the domain Company.com.)

This is the behavior you get if you select the Update Now option from the flyout menu. RUS searches for a new or changed mail-enabled object and applies the first recipient policy that includes that object in its filter criteria. Key point: Only new and modified objects get updated.

Policy changes

Remember that I said this process gets complicated. Here's where the complications begin.

Let's say you want to add a new SMTP address, such as @companyinformation.com, to an existing Recipient Policy. You open the Properties for the policy and add the new address and check the box next to the new address to enable it. When you click OK to save the change, a little notification window pops up telling you that the email addresses have been modified and asking if you want to update all corresponding recipient email addresses to match the new address.

This is an important window. If you don't click Yes, then RUS won't see any changes to apply. If you click Yes, the new proxy addresses in the policy get added to an attribute called GatewayProxy in the Recipient Update Service object, as shown in this listing:

gatewayProxy: {98356E20-3000-4F1DBB4B3852C423E766}smtp:@companyinformation.com;
{98356E20-3000-4F1DBB4B3852C423E766}smtp:@company.com;
{98356E20-3000-4F1DBB4B3852C423E766} X400:c=US;a= ;p=Company;o=Phoenix;;

The next time RUS fires, it applies the entries in GatewayProxy to the objects targeted by the search query in the Recipient Policy. It then clears the entries from GatewayProxy.

Rebuilds

If you change the proxy addresses in a recipient policy and you want to apply the new addresses to all existing objects, select the Rebuild option. This sets a flag called msExchDoFullReplication in the Active Directory object that controls the RUS instance, which tells RUS to look at all current objects as well as any new or modified objects. You can see this flag using the ADSI Editor. Figure 5.39 shows an example.

description of image
Figure 5.39: ADSI Editor showing msExchDoFullReplication attribute after setting RUS to Rebuild. (Click on image for enlarged view.)

When you select Rebuild, you'll get a warning that this could take some time and that it could possibly update a significant number of objects, increasing replication traffic. But if you want to change existing objects, Rebuild is your only option.

But wait…It's not quite that simple.

The Rebuild option does not actually begin rebuilding immediately. It only sets the msExchDoFullReplication flag. Nothing happens until RUS reaches its next scheduled start interval.

When RUS fires, it sees the msExchDoFullReplication flag and commences the rebuild. This happens within a minute, if you left the RUS Update Interval set for Update Always, but takes longer if you set the Update Interval to a longer period. Key point: Rebuild uses the standard RUS update schedule. Don't expect the changes to take effect immediately if you do a manual rebuild.

Applying changes right away

If you change a proxy address and you want to apply the change to all existing mail-enabled objects, and you want the change to happen right now, first select Rebuild and then select Update Now. The Rebuild selection primes RUS with the msExchDoFullReplication flag and the Update Now option overrides the update interval.

Policy scope changes

It's not over yet. Each recipient policy has a scope defined by the content of the LDAP filter. Let's say you define a filter that says, "apply to members of group name Executives." (You should not use group membership as filter criteria for recipient policies, and this example will eventually show you why.) You populate this policy with an SMTP suffix for use by executives and board members and the standard SMTP suffix for your organization.

Later on, you realize that the administrative assistants who work with the executives also need that executive SMTP suffix, so you expand the policy scope to include members of the Executive Admin Assistants group.

When you make a change to the scope of a recipient policy, a little warning window pops up. This window contains a different warning than the previous one, so don't just click it and go on about your business. This warning tells you that the change you just made does not take effect unless you specifically select "Apply This Policy Now" from the flyout menu of the policy. Clicking OK on this warning does not perform any action. It simply acknowledges the message.

This necessity to manually prime RUS with proxy addresses following a scope change makes it possible to have "stealth" scope changes that do not result in an update to the target objects. For example, if you add an existing user to the Executive Administrative Assistants group, that user will not get the addresses in the Executive recipient policy because nobody has primed RUS by selecting "Apply This Policy Now."

For this reason, you should avoid defining LDAP searches that include group membership as a search criterion when formulating recipient policies or any other feature that relies on RUS. This includes Mailbox Management and Address Lists.

Key points for managing Recipient Policies

If the preceding process descriptions make you want change professions, here are a few simple rules of thumb for RUS:

  • When creating a new recipient policy, include all addresses that apply to the target recipients. Remember that RUS evaluates each policy in order of precedence. The first policy whose search scope includes a mail-enabled object is the policy that RUS applies to that object.

  • When changing the content or scope of a policy, be sure to select Apply This Policy Now from the flyout menu.

  • When applying a policy to existing recipients in a domain, select Rebuild followed by Update Now on the RUS service icon for that domain.

  • When taking an Exchange server down for maintenance, always check to see if the server hosts a RUS instance for a particular domain or the Enterprise Configuration. If so, select another Exchange server to host that instance until you complete the maintenance.

  • Avoid using group membership as a filter for a recipient policy. Only use filters that interact directly with the LDAP search, such as the Department or the Location attributes.


15 tips in 15 minutes: Managing recipients and distribution lists

 Home: Introduction
 Tip 1: Exchange security groups
 Tip 2: Group membership expansion
 Tip 3: Managing Exchange group email properties
 Tip 4: Exchange 2003 Query-Based Distribution Groups
 Tip 5: DSAccess for Exchange
 Tip 6: DSProxy for Exchange
 Tip 7: Managing Exchange recipient policies
 Tip 8: Exchange Recipient Update Service and proxy addresses
 Tip 9: Restricting mail storage on an Exchange server
 Tip 10: The Exchange server mailbox management service
 Tip 11: Blocking a user's email access
 Tip 12: Accessing another user's mailbox in Outlook
 Tip 13: Exchange mail retention
 Tip 14: Managing recipients with system policies
 Tip 15: Managing recipients with Global Settings

This chapter excerpt from Learning Exchange Server 2003 by William Boswell is printed with permission from Addison-Wesley Professional, Copyright 2004. Click here for the chapter download or to purchase the book.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close