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.