Exchange Server depends on the Active Directory, which, in turn, depends on a DNS server. In relation to the Recipient...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Update Service (RUS), this means that if your DNS server is not configured correctly, the RUS probably will not work properly. Troubleshooting DNS-related RUS problems can be difficult if you have several Exchange servers, but it is necessary.
To diagnose and troubleshoot Exchange Recipient Update Service issues caused by DNS configuration problems:
- First, check each Exchange server's TCP/IP configuration. Each configuration that is bound to a network adapter in the server should point to the same DNS server that your Active Directory uses. It should not be configured to use your ISP's DNS server. If the Exchange server needs to resolve external IP addresses, it should be configured to point to an internal DNS server. However, you should configure that internal DNS server with a forwarder that points to your ISP's DNS server. This will allow you to resolve both internal and external IP addresses.
- As you verify each Exchange server's TCP/IP configuration, open a command prompt window and use the Nslookup command to verify that the server can correctly resolve the IP addresses of all other Exchange servers. To do this, append the server's fully qualified domain name (FQDN) to the Nslookup command. For example, if the server's FQDN was exchange.contoso.com, then you would use the following command: Nslookup exchange.contoso.com.
- Once you've verified that the DNS name resolution works correctly for all Exchange servers, look through the DNS management console and verify that the appropriate service-locator records (SRV records) exist for domain controllers. (SRV records are described in RFC 2052.)
An SRV maps the name of the service to the name of the server it offers. In the case of a domain controller, the SRV record points to services such as Kerberos, LDAP, and the global catalog. Figure 3 gives an example of what the SRV records should look like. Remember that this is not the only location in the DNS hierarchy where SRV records might be found.
Figure 3: SRV records map a service to a server offering that service.
Another DNS-related issue that you should check is that you don't duplicate computer names. The Active Directory is designed to prevent you from creating duplicate computer names within a domain. However, using the same computer name in both a child domain and a parent domain can cause problems.
For example, suppose you had a domain named contoso.com and a child domain named exchange.contoso.com. Although Windows might allow you to create a computer with the same NetBIOS name in both domains, you shouldn't. This doesn't apply strictly to Windows machines, but to any device that uses NetBIOS names or fully qualified domain names.
TROUBLESHOOTING THE RECIPIENT UPDATE SERVICE
Step 1: Validate server names for the Exchange Recipient Update Service
Step 2: Diagnose DNS-related Exchange Recipient Update Service problems
Step 3: Enable diagnostic logging for the Exchange Recipient Update Service
Step 4: Find Exchange Recipient Update Service Event ID log entries
Step 5: Troubleshoot the Exchange RUS with ADSI Edit and 8011 events
|ABOUT THE AUTHOR:|
| Brien M. Posey, MCSE
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Dig Deeper on Microsoft Exchange Server Monitoring and Logging