This article is a general guide to troubleshooting the Recipient Update Service in Microsoft Exchange Server 2003 and Exchange Server 2000.

Back to the top

Troubleshooting steps fall into the following categories:

•	Checking for typically known issues
•	Verifying the Recipient Update Service configuration
•	Increasing diagnostics logging
•	Checking Domain Name System configuration
•	Additional techniques

Back to the top

Checking for Typically Known issues

The common Recipient Update Service issues that you need to look for are as follows

•	Propagating permissions
•	Hidden distribution list (DL) membership
•	Cross-domain Recipient Update Service functionality
•	A missing address generator For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base: 286356 (http://support.microsoft.com/kb/286356/) Recipient update service does not stamp proxy addresses
•	Exchange Server 5.5 site addressing superceding other recipient policies

Back to the top

Verifying the Recipient Update Service Configuration

Make sure that you verify the Recipient Update Service configuration in the forest:

1.	In Exchange System Manager, click the Recipients container, and then click the Recipient Update Service container. Look for a Recipient Update Service for the domain that has users who are stamped with e-mail addresses. This can be Recipient Update Service (domain_name).
2.	In the properties of the Recipient Update Service, make sure that the domain controller and Exchange server that are entered are valid.
3.	In Exchange System Manager, click the Recipients container, and then click the Recipient Policies container. Make sure that the filter rules on the recipient policies are correct.

Back to the top

Increasing Diagnostics Logging

To increase diagnostics logging:

1.	Increase diagnostic logging to Maximum on the MSExchangeAL service for the following categories: LDAP Operations, Service Control and Address List Synchronization.
2.	Then, in Exchange Server 2003, increase diagnostic logging to Maximum on the MSExchangeSA service for the Proxy Generation category.
3.	Restart the System Attendant service and rebuild the Recipient Update Service.
4.	Examine Application Log for indications of problems.

Back to the top

Checking Domain Name System Configuration

A very common cause of Recipient Update Service issues is incorrect Domain Name System (DNS) configuration. Not only should you look for name resolution, you should also look for:

•	A server short name that exists in more than one domain, for example, server.root.com and server.child.root.com. This incorrect configuration causes communication security problems.
•	SRV records for all the servers that are involved.
•	The Internet Protocol address. Make sure that each server resolves the other server's name to the correct IP address.
•	The TCP/IP configuration. Make sure that the DNS servers in the Preferred DNS Server box in the TCP/IP properties are only SRV record-aware servers. Do not configure the Preferred DNS Server box to use an ISP DNS server.

Back to the top

Additional Techniques

These additional steps can sometimes reveal an underlying issue that is not discovered with the previous categories:

1.	View the matched objects in the Filter rule of the recipient policy by clicking Modify and then Find Now. The objects that meet the query are displayed in the list. Make sure that this information is correct.
2.	If some users are stamped but others are not, then obtain an LDP dump of the two objects, and then compare them attribute by attribute.
3.	Examine the msExchPoliciesIncluded attribute to see which policy the Recipient Update Service tried to stamp the object with.
4.	Verify permissions on directory objects that have Dsacls.exe from the Microsoft Windows 2000 support tools.
5.	Use Network Monitor to capture network traffic from the Exchange Server that is listed in the Recipient Update Service to ANY. Make sure that the DNS query is what is expected, that the DNS returns what is expected, that the LDAP modify is performed, and that no errors occur at the LDAP level.

Back to the top