Step 5: Troubleshoot the Exchange RUS with ADSI Edit and 8011 events

Learn how to troubleshoot the Exchange Recipient Update Service with ADSI Edit and 8011 events, and discover how to schedule and perform RUS updates.

Now that you've enabled diagnostic logging and understand what Event IDs correspond to the Exchange Recipient Update Service, we're going to use the ADSI Edit utility to check a specific attribute of a random user who has a mailbox on the effected Exchange server. We'll then check the event log for a particular type of 8011 event that reflects the recorded value. That information should yield clues as to the cause of a RUS problem.

If you do not already have the ADSI Edit utility installed, you can find it on your Windows Server 2003 installation CD. Just insert your Windows installation CD and run the installation program found in the \Support\Tools folder. Be warned, however, that the ADSI Edit utility lets you manipulate Active Directory attributes directly. Using ADSI Edit incorrectly can destroy Windows and Exchange Server, so you would be well-served to make a full system backup before beginning the instructions below.

How to use ADSI Edit and 8011 events to troubleshoot RUS

  1. Randomly pick a user who has a mailbox on the effected Exchange Server.

  2. Check the Event Viewer for 8011 events that reflect the recorded value. The information recorded in the event log should yield clues to the cause of the problem.

  3. Choose command prompt from the All Programs -> Windows Support Tools menu to open a command prompt window with the path already set to the C:\Program Files\Support Tools folder.

  4. Enter the ADSIEDIT.MSC command in Windows to launch ADSI Edit.

  5. When ADSI Edit opens, navigate through the console tree to Domain [your domain -> DC=your domain, DC=com -> CN=Users.

  6. Expand the CN=Users container to see subcontainers corresponding to each user and group within the domain (Figure 10).


    Figure 10. Navigate to Domain [your domain] -> DC=your domain, DC=com -> CN=Users.

  7. Locate the container that corresponds to the user account you originally selected.

  8. Right click on the user's container and select Properties.

  9. Scroll through the properties sheet until you locate the uSNChanged attribute. As shown in Figure 11, there is a value associated with the uSNChanged attribute. Make note of this value.

    Note: Throughout the troubleshooting process, make sure that no other administrators change objects in the domain. If this occurs, the uSNChanged value could change, rendering this test invalid.


    Figure 11. Document the value associated with the selected user's uSNChanged attribute.

  10. Open the Event Viewer.

  11. Select the Application Log.

  12. Choose the View -> Find command.

  13. Set the Event ID to 8011 and enter Base 'DC into the Description field, as shown in Figure 12.


    Figure 12. Search for 8011 events with Base 'DC in their description.

  14. Click Find Next.

  15. When a matching event is located, click Close.

  16. Double click on the event that has been located. The event's details should look similar to that in Figure 13.


    Figure 13. The event you are searching for looks like this.

  17. As you look at this figure, don't worry about the majority of the extensive description. You are only interested in the portion that looks like this:

    '(&(USNChanged>=2125869) (uSNChanged<=212869)

    Event ID 8011 is an LDAP query. In this case, the LDAP query looks for Active Directory objects within the selected domain that have a USNChanged value between 2125869 and 2125869. Because my examples are on a lab server, the two values are the same. On a production server, however, the specified values would almost always represent a range.

  18. Look again at Figure 13, and you will notice that the value associated with the uSNChanged attribute is lower than the values for which the LDAP query is searching. This means that the RUS has passed the object. You might be able to verify this by searching through the Application Log until you find an 8011 event, similar to the one shown in Figure 14, that reflects the expected uSNChanged attribute range.


    Figure 14. Changing the object's properties causes the uSNChanged attribute value to change.

    More often, you won't be able to find the expected attribute range within the Application Log. There are two reasons for this:

    • Exchange Server diagnostic logging was not enabled at the time to the LDAP query against the attribute range occurred.

    • The event was logged, but was overwritten by newer events. Remember that diagnostic logging can produce an extremely large number of events, which quickly flushes older events. This is especially true if the Recipient Update Service performs a rebuild operation.

  19. If the attribute range listed in the 8011 event is higher than the recorded attribute value, use Active Directory Users and Computers console to modify one of the properties associated with the user account in question. This will cause a new value to be applied to the object's uSNChanged attribute (Figure 14). You then can refresh the Application Log and search for an event in which the specified attribute range matches the recorded attribute, which shows that the RUS is working.

Making sense of higher attribute values

If the attribute's value is higher than the range that the 8011 event specifies, it means that the Exchange Recipient Update Service has not yet performed a query on the object since the object was updated.

Just because an attribute's value is higher than the value range recorded by the 8011 event, doesn't mean that the RUS has a problem. For example, if the attribute's value is slightly higher than the range listed in the 8011 event, it could mean that the Exchange server is busy and has not had a chance to perform the necessary query.

If the range that the event log reflect is significantly higher than the user account's uSNChanged attribute value, it can mean one of two things.

  • The Recipient Update Service has broken, and the necessary attribute range will never be queried.

  • The server is busy and has not made it to the expected attribute range yet. This tends to occur mostly in very large domains, and is usually associated with a rebuild operation.

When the RUS performs a rebuild, it queries objects with an uSNChanged attribute value of 1, followed by higher attribute values, until all objects in the domain have been queried. Depending on the domain size, a rebuild can take from several hours to several days. A rebuild is different from running the Update Now command, because a rebuild starts with an uSNChanged value of 1, while the Update Now command starts with the highest uSNChanged value recorded by the RUS.

There are a couple ways to determine if the RUS is experiencing a rebuild.

  • Periodically check for 8011 events to see if the attribute range is increasing.

  • Disable diagnostic logging for everything except Address List Synchronization, which should be set to medium. You then can check the Application Log for events that reflect a rebuild.

    When a rebuild is initiated, Exchange Server will issue an Event ID 8329. As the rebuild progresses, Event ID 8332 will be displayed after approximately 10% is complete. If you search for a rebuild-related event, you should search for Event ID 8332. When the rebuild is complete, Exchange Server will generate an Event ID 8330 to confirm.

Scheduling Exchange RUS updates

An 8011 event attribute range can be the same, higher, or lower than a user's uSNChanged attribute. But there's also the possibility that no 8011 event will be generated. If no 8011 event is recorded, usually it means that the RUS has stopped responding, or that it is not time for it to perform an update.

If this occurs, the following steps should be taken to verify the Exchange Recipient Update Service update interval:

  1. Open the Exchange System Manager and navigating through the console tree to Recipients -> Recipient Update Services.

  2. Right click on the RUS (your domain) object in the details pane, and select Properties.

  3. Make sure that the update interval is set to Always Run.

If you need the RUS to conform to a custom schedule, you can force a manual update by right clicking on the RUS (your domain) object and selecting Update Now from the shortcut menu. You might notice that the shortcut menu also contains an option to rebuild the RUS. If you choose to initiate a rebuild manually, remember that a rebuild can take some time and could consume a considerable amount of system resources.

For additional help, refer to Microsoft Knowledge Base article 822794, How to troubleshoot the Recipient Update Service by using the Application Log in Exchange 2000 Server or in Exchange Server 2003.


TROUBLESHOOTING THE RECIPIENT UPDATE SERVICE

 Home: Introduction
 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.
This was first published in October 2007
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close