Microsoft KB Archive/822794

From BetaArchive Wiki

Article ID: 822794

Article Last Modified on 10/25/2007


APPLIES TO

  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition



SUMMARY

In your Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server organization, you may experience a problem where the Recipient Update Service (RUS) does not stamp user objects with proxy addresses.
You can troubleshoot this problem by doing the following:


  • Increase diagnostics logging on the Exchange computer.
  • Select a test object to monitor.
  • View the Application log to determine whether the RUS processes the test object successfully.

Repeatedly performing a Rebuild operation on the RUS may make the troubleshooting process more difficult. Therefore, instead of repeatedly performing a Rebuild operation on the RUS, you can view the events that the RUS generates to determine where the RUS problem exists.


IN THIS TASK

INTRODUCTION

The Recipient Update Service (RUS) is included with Microsoft Exchange Server 2003 and Microsoft Exchange 2000 Server. This article describes how to troubleshoot the RUS by using events that appear in the Application log.

In your Exchange organization, the domain RUS stamps mail-enabled objects in a specified domain for that domain naming context. You can create one domain RUS for each domain controller in a specified domain. If a domain has more than one domain RUS, you must determine the RUS to troubleshoot. The Enterprise RUS only stamps objects in the Configuration naming context, such as public folder stores and site replication services. The Enterprise RUS does not stamp objects such as users, groups, contacts, or public folders.

You can identify many RUS problems by examining the Application log in Event Viewer. You can use the Application log to troubleshoot the following problems:

  • The RUS does not stamp objects with a proxy address.
  • The RUS takes a long time to stamp objects with a proxy address.
  • The RUS stamps objects with an incorrect proxy address.

back to the top

Increase diagnostics logging

To troubleshoot RUS issues that you may experience, increase diagnostics logging to the maximum level. Do this for all the following objects on the Exchange server that is responsible for the domain RUS that you want to troubleshoot.

Note If there is more than one RUS that is responsible for the domain, set the schedule to Never run for all but one RUS. This will let you focus on the Application log of only one RUS server when you troubleshoot RUS issues.

Service Category
MSExchangeAL LDAP Operations
MSExchangeAL Address List Synchronization
MSExchangeSA Proxy Generation (Exchange 2003 only)

To do this, follow these steps:

  1. Start the Exchange System Manager tool.
  2. If administrative groups are enabled, expand Administrative Groups, and then expand your administrative group. If administrative groups are not enabled, go to step 3.
  3. Expand Servers, right-click the Exchange server that you want to configure diagnostic logging on, and then click Properties.
  4. Click the Diagnostics Logging tab, and then click MSExchangeAL in the Services list.
  5. In the Categories list, click LDAP Operations, click Maximum, click Address List Synchronization, and then click Maximum.


If you are running Exchange 2003, go to step 6. If you are not running Exchange 2003, go to step 7.

  1. Click MSExchangeSA in the Services list, click Proxy Generation in the Categories list, and then click Maximum.
  2. Click OK.

After you have selected a domain RUS to troubleshoot, and after you have increased diagnostics logging on the Exchange server that handles the domain RUS that you want to troubleshoot, you must select an object to use to test the RUS. For example, test the RUS by using a user account that the RUS has not stamped. You can then view the actions that the RUS performs on this object.

back to the top

Determine whether the RUS has started

Within a few minutes after you increase diagnostic logging, event ID 8011 and event ID 8012 will appear in the Application log. If these events do not appear, the RUS did not start or the RUS has stopped responding. If you suspect that the RUS did not start or that the RUS stopped responding, restart the Microsoft Exchange System Attendant service. When you start the Microsoft Exchange System Attendant service, this service loads a series of DLLs. One of these DLLs is Abv_dg.dll.

When you start the Microsoft Exchange System Attendant service, the following event appears in the Application log.

Event ID 1000

Event Type: Information
Event Source: MSExchangeSA
Event Category: General
Event ID: 1000
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Microsoft Exchange System Attendant is starting. Microsoft Exchange Server System Attendant, service startup complete, version 6.5 (build 7226.0).

After this event occurs, events are displayed to indicate that some DLLs are loading and that the DSAccess component is being initialized. Then, the following events appear.

Event ID 9006

Event Type: Information
Event Source: MSExchangeSA
Event Category: General
Event ID: 9006
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Microsoft Exchange System Attendant is loading 'ABV_DG.DLL'.

Event ID 9008

Event Type: Information
Event Source: MSExchangeSA
Event Category: General
Event ID: 9008
Date: Date
Time: Time
ser: N/A
Computer: ServerName
Description: Microsoft Exchange System Attendant is starting 'ABV_DG.DLL'.

The 9008 event indicates that Abv_dg.dll is starting. Immediately after the 9008 event appears, the following events appear.

Event ID 8011

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8011
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Searching directory ServerName.contoso.com at base 'CN=Recipient Update Services,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com' using filter '(&(objectCategory=msExchAddressListService)(!(IsDeleted=TRUE)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; msExchMasterServiceBL; activationSchedule; activationStyle; msExchAddressListServiceLink; msExchDomainLink; msExchServer1AuthenticationCredentials; msExchServer1AuthenticationPassword; msExchEncryptedPassword; msExchServer1NetworkAddress; msExchExportContainers; msExchReplicateNow; msExchDoFullReplication; msExchServer1LastUpdateTime; msExchServer1HighestUSN; msExchServer1PageSize; msExchPollInterval; msExchServer1Flags; VersionNumber; msExchServer1HighestUSNVector; msExchProcessedSids; msExchDomainGlobalGroupSid; msExchDomainLocalGroupSid; msExchDomainGlobalGroupGuid; msExchDomainLocalGroupGuid; gatewayProxy.

Event ID 8012

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Search of directory ServerName.contoso.com at base 'CN=Recipient Update Services,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com' returned 2 objects.

These events appear when Abv_dg.dll searches for any existing RUS. Typically, if event ID 9006 appears, but event ID 9008 does not appear, this behavior indicates that the RUS server is a front-end server. Abv_dg.dll does not start on a front-end server. Therefore, event ID 8011 and event ID 8012 do not appear on a front-end server. The RUS must be pointed to a back-end server.

Notice that, in the filter that appears in event ID 8011, Abv_dg.dll searches for any objects that are members of the msExchAddressListService class and that do not have their isDeleted property set to TRUE. Generally, this means that Abv_dg.dll searches for any RUS objects that are not tombstoned. (Tombstoned objects are objects that have been deleted but have not yet been removed from the directory.) This search returns a number of results that is equal to the number of RUSs that you have:

In these events, the only RUS objects are the Enterprise RUS and one domain RUS. Therefore, the search returns two objects. If this search returns no results, your Exchange server does not see the RUS objects. This behavior may occur because a permissions problem exists.

If the Exchange server cannot see a RUS object, the Exchange server cannot determine that it is responsible for that RUS object. In this scenario, the RUS will never process any objects. However, even if the Exchange server does not detect any RUS objects, event ID 8011 and event ID 8012 will appear frequently. This behavior occurs because Abv_dg.dll frequently searches for the existence of RUSs. If event ID 8011 and event ID 8012 do not appear in the Application log after you restart the Microsoft Exchange System Attendant service, Abv_dg.dll may not have been started. Abv_dg.dll may not have been started because the Exchange server is a front-end server.

back to the top

Determine whether the RUS queries for changes

If event ID 8011 and event ID 8012 appear in the Application log after you increase diagnostics logging, you must determine whether the RUS queries the domain for any new or modified objects to process. Based on the RUS schedule, the RUS should query the domain for any new or modified objects. The RUS should also query the domain if you right-click the RUS and then click Update Now.

To determine whether the RUS queries the domain for changes, follow these steps.

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

Note The Active Directory Service Interfaces (ADSI) Edit snap-in is included with the Microsoft Windows Support Tools. To install the Windows Support Tools in Windows 2000, double-click Setup.exe in the Support\Tools folder on the Windows 2000 CD. To install the Windows Support Tools in Windows Server 2003, double-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD.

  1. Use the ADSI Edit snap-in or LDP.exe to connect to the domain controller that the RUS points to. Locate the test object that you selected in the "Increase diagnostics logging" section, and then record the value for the uSNChanged attribute.

    To do this, follow these steps:
    1. Click Start, click Run, type adsiedit.msc, and then click OK.
    2. Expand Domain NC [DomainController.contoso.com], expand DC=contoso,DC=com, and then expand the container that your test object is located in. For example, expand CN=Users.
    3. Right-click the test object, and then click Properties. For example, right-click CN=UserName, and then click Properties.
    4. In the Select a property to view list, click uSNChanged.
    5. Note the value that appears in the Value(s) box.
    6. Quit the ADSI Edit snap-in.
  2. On the Exchange server that is responsible for the RUS that you want to troubleshoot, start Event Viewer, and then view the contents of the Application log. To do this, click Start, click Run, type eventvwr, click OK, and then click Application Log.
  3. On the View menu, click Find.
  4. In the Event ID box, type 8011, type Base 'DC in the Description box, and then click Find Next.

  5. Click Close, and then double-click the event that the Find in local Application Log dialog box returns. This event includes information about the most recent search for changes that occurred in the domain naming context. For example, an event message that is similar to the following appears:

    Event Type: Information
    Event Source: MSExchangeAL
    Event Category: LDAP Operations
    Event ID: 8011
    Date: Date
    Time: Time
    User: N/A
    Computer: ServerName
    Description:
    Searching directory ServerName.contoso.com at base 'DC=contoso,DC=com' using filter '(&(USNChanged>=273870)(uSNChanged<=298312)((objectclass=*)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; objectCategory; displayName; msExchHideFromAddressLists; hideDLMembership; ntsecuritydescriptor; showInAdvancedViewOnly; msExchALObjectVersion; showInAddressBook; msExchPolicyEnabled; givenName; sn; cn; mailNickname; targetAddress; initials; proxyAddresses; mail; textEncodedORAddress; msExchHomeServerName; msExchExpansionServerName; msExchCustomProxyAddresses; msExchPoliciesIncluded; msExchPoliciesExcluded; replPropertyMetaData; replicatedObjectVersion; ReplicationSignature; WhenChanged; WhenCreated; USNchanged; USNcreated; ObjectVersion; isDeleted; homeMDB; homeMTA; msExchMailboxGuid; msExchMailboxSecurityDescriptor; msExchResourceGUID; UserAccountControl; msExchUserAccountControl.

In this event description, you notice that the RUS is searching for any objects that have a uSNChanged attribute value between 273870 and 298312. You may also notice that event ID 8011 appears many other times in the Application log. These other events contain different searches. These other events may be generated by many different operations. However, to troubleshoot the RUS stamping objects in your Exchange organization, you only have to consider event ID 8011 events where the base of the search is the affected domain. Therefore, you use the Find command together with the "Base 'DN" description item.

If you have RUSs for different domains that are running on the same Exchange server, you may want to include the whole name of the domain in the Description box of the Find in local Application Log dialog box. If you do this, you will skip event ID 8011 events for other domain RUSs.

Consider the following scenarios:

  • The test object has a uSNChanged attribute value that is higher than the value that appears in this event.

    If the test object that you noted the uSNChanged attribute value for has a uSNChanged value that is higher than the range of USNs in this event, the RUS has not yet queried for this object. If the uSNChanged value for this object is very much higher than the USNs that the RUS is currently processing, the RUS has fallen behind and is still catching up to the latest changes.

    Typically, this behavior occurs if a Rebuild operation was run. When you click Rebuild, the RUS starts over from a uSNChanged value of 1 and queries for all objects in the domain. In a large domain, it may take many hours or many days for the RUS to process all the objects in the domain.
  • The test object has a uSNChanged attribute value that is lower than the value that appears in this event.

    If the test object that you noted the uSNChanged attribute value for has a uSNChanged value that is lower than the range of USNs in this event, the RUS has already passed this object. In this case, continue to search back through the Application log until you find the event ID 8011 event that contains the range of USNs that include your test object.

    If you cannot find this USN range, modify the test object. Any change to the object, such as changing the objects' description, causes the uSNChanged to be changed to the latest value on the domain controller. Therefore, if the RUS has gone past the test object, and if you cannot find the associated event ID 8011 event, modify the test object and then note the new uSNChanged value. Then you can locate the next event ID 8011 event in the Application log. The next event ID 8011 event will include the USN of the object that you modified.
  • No event ID 8011 event appears that has "Base 'DC" in the event description.

    If the Application log does not contain an event ID 8011 event that has "Base 'DC" in the event description, the domain RUS has not started processing yet.

    Note This issue may also occur if the event ID 8011 event has been overwritten by newer events. If a Rebuild operation is running, the Application log may fill up very quickly. To determine whether a Rebuild operation is running, see the "Determine whether a Rebuild operation is running" section.

    If no event ID 8011 event appears, and if you determine that a Rebuild operation is not running, view the RUS schedule to determine when the RUS should run. To view the RUS schedule, follow these steps:
    1. Start the Exchange System Manager tool.
    2. Expand Recipients, and then click Recipient Update Services.
    3. In the right pane, right-click Recipient Update Service (CONTOSO), and then click Properties.
    4. If Use custom schedule appears in the Update interval list, click Customize.

    Note You can right-click the RUS, and then click Update Now to cause the RUS to start processing objects immediately. However, in this scenario, do not start a Rebuild operation or apply a policy.

    If no event ID 8011 events appear after you click Update Now or after the RUS schedule causes the RUS to process objects, the RUS might have stopped responding or the RUS may be waiting for a domain controller to return search results.

    Typically, if the RUS stops responding during an LDAP query, you can start it by restarting the Microsoft Exchange System Attendant service. However, the RUS may stop responding again. In this scenario, you must determine the reason that the RUS stops responding during an LDAP query. Generally, this behavior occurs because a network problem exists. To identify this network problem, use the Network Monitor tool to capture the query as it stops responding.

If the event ID 8011 event does contain a range of uSNChanged values that includes the uSNChanged value of your test object, the RUS has queried the domain for changes to this object.

back to the top

Determine whether a Rebuild operation is running

To determine whether a Rebuild operation is running, use one of the following methods.

Method 1: Use Repadmin.exe

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

Use the Repadmin tool (Repadmin.exe) that is included with the Windows 2000 Support Tools to determine the time that the msExchDoFullReplication attribute was modified. To do this, follow these steps:

  1. Use the ADSI Edit snap-in or LDP.exe to obtain the distinguished name of the RUS that you want to troubleshoot. To do this, follow these steps:
    1. Click Start, click Run, type adsiedit.msc, and then click OK.
    2. Expand Configuration Container [DomainController.contoso.com], expand CN=Configuration,DC=contoso,DC=com, expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=OrganizationName. For example, expand CN=First Organization.
    3. Expand CN=Address Lists Container, and then click CN=Recipient Update Services.
    4. In the right pane, note the distinguished name that corresponds to the domain RUS that you want to troubleshoot.
    5. Quit the ADSI Edit snap-in.
  2. Click Start, click Run, type cmd, and then click OK.
  3. Type the following command, and then press ENTER. Replace distinguishedName with the distinguished name of the RUS that you want to troubleshoot.

    repadmin /showmeta "distinguishedName" >rusmeta.txt

    For example, type the following command, and then press ENTER:

    repadmin /showmeta "CN=Recipient Update Service (CONTOSO),CN=Recipient Update Services,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" >rusmeta.txt

  4. In a text editor such as Notepad, open the Rusmeta.txt file that this command creates.

  5. In the Rusmeta.txt file, locate the entry that references the msExchDoFullReplication attribute. This entry appears similar to the following:

    298589      Default-First-Site-Name\<ServerName>    298589 2004-06-29 17:10:59   2 msExchDoFullReplication

When you right-click a RUS and then click Rebuild, the msExchDoFullReplication attribute is set to TRUE. When the RUS starts to process objects in the Active Directory directory service, the RUS sets this attribute to FALSE. By looking at the time stamp that appears in the Repadmin output, you can determine when this attribute was last modified. Therefore, you can determine when the Rebuild operation was last run.

Method 2: Use diagnostics logging

Turn down diagnostics logging on all items except the Address List Synchronization item. Set the Address List Synchronization item for medium logging, and then view the Application log to locate the following event.

Event ID 8329

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8329
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: The Recipient Update Service is starting a rebuild of DC=contoso,DC=com

Additionally, at about every 10 percent increment throughout the Rebuild operation, the following event is displayed to indicate the progress of the Rebuild operation.

Event ID 8332

Event Type: Information
Event Source: MSExchangeAL

Event Category: Address List Synchronization
Event ID: 8332
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: The Recipient Update Service has started to export a block of entries from DC=contoso,DC=com, beginning at USN 1. It will finish processing the directory when it reaches USN 298599

When the Rebuild operation has completed, the RUS logs the following event.

Event ID 8330

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8330
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: The Recipient Update Service has completed the rebuild of DC=contoso,DC=com

Note Typically, running a Rebuild operation does not help you troubleshoot a RUS. The only difference between the Rebuild command and the Update Now command is that the Rebuild command causes the RUS to restart object processing.

In this scenario, the RUS starts from a USN of 1. The Update Now command causes the RUS to start processing objects from the highest USN that was last recorded by the RUS. This USN is stored in the msExchServer1HighestUSN property on the RUS object in the Active Directory directory service. Therefore, if the RUS does not process new or modified objects as you expect, running a Rebuild operation will not help.

Additionally, because of the time that it may take for the Rebuild operation to be completed in a large environment, carefully consider how much time it may take to resume typical RUS operation before you decide to perform a Rebuild operation. When a Rebuild operation has started, you must wait for the RUS to catch up to the latest USNs before you can perform any additional troubleshooting against new or modified objects.

For more information about how the RUS queries for changes, click the following article number to view the article in the Microsoft Knowledge Base:

328738 How the Recipient Update Service applies recipient policies


back to the top

Determine whether the query returned results

If you locate an event ID 8011 event that indicates that a search was performed for a range of USNs, and the range of USNs includes the USN of your test object, determine whether this search returned any results. For the event ID 8011 event, the following corresponding event ID 8012 event appears in the Application log.

Event ID 8012

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Search of directory ServerName.contoso.com at base 'DC=contoso,DC=com' returned 16 objects.

Consider the following scenarios:

  • If no event ID 8012 event that corresponds to the event ID 8011 event appears in the Application log, Exchange did not detect a response to the search. Typically, this behavior indicates a network problem. Generally, this kind of network problem causes the RUS to stop responding (hang).

    Additionally, if you experience this kind of network problem, the RUS does not generate any additional queries to the domain root because the RUS is waiting for a response to its current search. Therefore, in this scenario, no additional event ID 8011 events appear in the Application log. If you repeatedly experience this behavior, it is best to capture a network trace to identify the network problem.
  • If the search returned zero objects, the Exchange server computer account does not have sufficient permissions to view the user object. These permissions come from the Exchange Enterprise Servers group. This group is granted permissions at the root of the domain when the Setup /domainprep command is run. If these permissions are changed, or if inheritance on a subcontainer is removed, Exchange may no longer have sufficient permissions to view a user account.

    Additionally, the Exchange Enterprise Servers group for this specific domain must contain the Exchange Domain Servers groups for all the other domains. Also, one of the Exchange Domain Servers groups must contain the Exchange server that is responsible for this RUS. If this chain of membership has been broken, the Exchange server may not be able to view the user account.
  • If the search returns more than 20 objects, you see more than one event ID 8012 event. The RUS uses a page size of 20 for this search. Therefore, the results are returned in batches of 20. Expect to see one event ID 8012 event for every 20 objects that the query returns.
  • If the search returned some objects, the events that following the event ID 8012 event list the objects that are being queued for processing. In this scenario, the following events appear:

    • Event ID 8175

      Event Type: Information
      Event Source: MSExchangeAL
      Event Category: Address List Synchronization
      Event ID: 8175
      Date: Date
      Time: Time
      User: N/A
      Computer: ServerName
      Description: Processing change to 'CN=UserName,CN=Users,DC=contoso,DC=com'.

    • Event ID 8134

      Event Type: Information
      Event Source: MSExchangeAL
      Event Category: Address List Synchronization
      Event ID: 8134
      Date: Date
      Time: Time
      User: N/A
      Computer: ServerName
      Description: Queuing request to process 'UserName,CN=Users,DC=contoso,DC=com'.

    By examining the 8175 events and the 8134 events that follow event ID 8012, you can determine whether the test object is returned in this search. If your test object was not returned in this search, you may be experiencing a permissions issue where Exchange does not have sufficient permissions to view the user object.

When the RUS has finished queuing changes to process, the following event appears in the Application log.

Event ID 8169

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8169
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Retrieved all directory changes under: 'DC=contoso,DC=com'.

back to the top

Determine which policies match the test object

If you determine that the RUS queried for changes to the test object, and that the query returned the expected result, you must then determine what occurred when the RUS processed the test object.

When the RUS retrieves of the objects that are queued for processing, the following event appears in the Application log.

Event ID 8163

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8163
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Thread #12b8: received next Address List Transaction. DC=contoso,DC=com.

The RUS then evaluates the object against each address list and each policy. For each evaluation, the following event is generated.

Event ID 8129

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8129
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Evaluating directory object 'CN=UserName,CN=Users,DC=contoso,DC=com' against address list 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com' rule '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))'. DC=contoso,DC=com.

If the address list or the policy matches the object, the following event appears.

Event ID 8130

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8130
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com' added to 'CN=UserName,CN=Users,DC=contoso,DC=com'. DC=contoso,DC=com

You can examine these events to determine which policies and which address lists the RUS has determined match the object.

Note You may see an event ID 8130 event for more than one recipient policy. However, this scenario does not mean that multiple policies are applied to an object. Of all the matching policies, only the policy that has the highest priority affects the recipient. However, address lists are cumulative. In this scenario, all the matching address lists are applied to the recipient.

Expect an event ID 8129 event to appear for each existing address list and for each policy. If an event ID 8129 event does not appear for each address list or for each recipient policy, the RUS does not see these address list objects or these recipient policy objects. Typically, a permissions issue causes this behavior, especially in a hosting scenario where permissions on individual address lists have been modified.

This behavior may also occur if these objects have not replicated to the domain controller that the Exchange server has selected as the configuration (Config) domain controller. Exchange reads the address lists and the recipient policies from the configuration domain controller and not from the domain controller that the RUS points to. To determine which domain controller is used as the configuration domain controller, follow these steps:

  1. Start the Exchange System Manager tool.
  2. If administrative groups are enabled, expand Administrative Groups, and then expand your administrative group.
  3. Expand Servers, right-click the Exchange server that you want to view the properties of, and then click Properties.
  4. Click the Directory Access tab, and then click Configuration Domain Controller in the Show list.

Sometimes, the RUS must query the Active Directory directory service to determine whether a policy applies. In this scenario, the following events appear in the Application log.

Event ID 8129

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8129
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Evaluating directory object 'CN=UserName,CN=Users,DC=contoso,DC=com' against address list 'CN=NewPolicy,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com' rule '(&(extensionAttribute1=mySpecialValue))'. DC=contoso,DC=com

Event ID 8011

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8011
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Searching directory ServerName.contoso.com at base '<GUID=F56238A9720BA14FBBD786F9CC847A45>' using filter '(&(extensionAttribute1=mySpecialValue))' and requesting attributes ObjectClass; ReplPropertyMetaData. DC=contoso,DC=com

Event ID 8012

Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Search of directory ServerName.contoso.com at base '<GUID=F56238A9720BA14FBBD786F9CC847A45>' returned 0 objects. DC=contoso,DC=com

In these events, the RUS submitted a search to the domain controller to determine whether the policy that is described in these events matched the user object. In this scenario, the RUS used the object GUID attribute of the user object as the base of the search. The RUS used the filter from the recipient policy as the search filter. In these specific events, the search did not return any results. Therefore, the RUS has determined that this policy does not match this user object.

By reading the event ID 8130 events, you can determine which policies match the recipient. Then, from each recipient policy that appears in an event ID 8130 event, you can identify the recipient policy that has the highest priority. The recipient policy that has the highest priority is the policy that the RUS generates the proxy address for.

Note This scenario assumes that it is appropriate for the RUS to generate a proxy address for the specified recipient.

For more information about how the RUS determines whether to generate addresses, click the following article number to view the article in the Microsoft Knowledge Base:

328738 How the Recipient Update Service applies recipient policies


back to the top

View the proxy generation results

After you increase diagnostics logging for proxy generation on a computer that is running Exchange Server 2003, the following event appears in the Application log.

Event ID 3006

Event Type: Information
Event Source: MSExchangeSA
Event Category: Proxy Generation
Event ID: 3006
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Policy provider instance processing recipient.
Recipient DN: CN=UserName,CN=Users,DC=contoso,DC=com
Current recipient proxies:
X500:/O=Microsoft/OU=Site1/cn=Recipients/cn=UserName
smtp:UserName@adatum.com CCMAIL:UserName at Site1
MS:MICROSOFT/SITE1/UserName
SMTP:UserName@Site1.Microsoft.com
X400:c=US;a= ;p=Microsoft;o=Site1;s=UserName;
Applicable policies:
CN=Default Policy,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com CN=Site1,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Chosen policy:
CN=Site1,CN=Recipient Policies,CN=Microsoft,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Proxies of chosen policy:
smtp:@adatum.com
X400:c=US;a= ;p=Microsoft;o=Site1;
SMTP:@Site1.Microsoft.com
MS:MICROSOFT/SITE1
CCMAIL: at Site1
Proxies in change list:
Proxies to generate:
Conflicts during generation:
Proxies generated:
Proxies written to recipient:

This event describes the decisions that the RUS made in the proxy generation step, together with a summary of the applicable policies. You can use this event instead of reading through all the event ID 8130 events.

back to the top

Determine whether changes were required

After the address list or recipient policy evaluation process has completed, the following event appears in the Application log.

Event ID 8160

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8160
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: No change required for CN=UserName,CN=Users,DC=contoso,DC=com. DC=contoso,DC=com

In some scenarios, event ID 8160 appears in the Application log even if you are sure that an object should have been modified. For example, consider the following symptoms:

  • You have a recipient who does not have any proxy addresses assigned.
  • You see event ID 8130 events that indicate that recipient policies match this recipient.
  • The evaluation process logs an event ID 8160 event to indicate that this recipient object does not require any changes.

Typically, this behavior occurs if the proxy generator has not loaded successfully. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

286356 Exchange Recipient Update Service does not stamp proxy addresses in Exchange 2000 Server and in Exchange Server 2003


If changes were made to the object, the following events will appear in the Application log.

Event ID 8039

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8039
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Completed the transaction...

dn: <GUID=EDC7EA535F006845892C30A34F038549>
changetype: Modify
showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=Microsoft,CN=Mic... : CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists
Cont...
mail:TestUser1@Site1.Microsoft.com
textEncodedORAddress:c=US;a= ;p=Microsoft;o=Site1;s=User1;g=Test; proxyAddresses:X400:c=US;a= ;p=Microsoft;o=Site1;s=User1;g=Test;

SMTP:TestUser1@Site1.Microsoft.com
MS:MICROSOFT/SITE1/TESTUSER1
CCMAIL:User1, Test at Site1
smtp:TestUser1@adatum.com

msExchPoliciesIncluded:add:{14FE313C-34F5-41DC-8361-D58A46A5260A},{3B6813EC-CE89-42BA-9442-D87D4AA30DBC} : {14FE313C-34F5-41DC-8361-D58A46A5260A},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchUserAccountControl:0
msExchALObjectVersion:49
objectGUID:EDC7EA535F006845892C30A34F038549
-
DC=contoso,DC=com

Event ID 8035

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8035
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Successfully modified entry 'CN=TestUser1,CN=Users,DC=contoso,DC=com' on directory ServerName.contoso.com. DC=contoso,DC=com

Event ID 8167

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8167
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description:
Modified the object: 'CN=TestUser1,CN=Users,DC=contoso,DC=com'. DC=contoso,DC=com

Finally, after the evaluation of this recipient has completed, the following events appear in the Application log.

Event ID 8133

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8133
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Calculations complete on 'CN=TestUser1,CN=Users,DC=contoso,DC=com'. DC=contoso,DC=com

Event ID 8162

Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8162
Date: Date
Time: Time
User: N/A
Computer: ServerName
Description: Thread #12b8: waiting for next Address List transaction. DC=contoso,DC=com

back to the top


Additional query words: rus replication replicate object not

Keywords: kbhowtomaster kbexchtechbulletin kbdirectory kbinfo KB822794



Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.


Retrieved from ‘https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/822794&oldid=381998’
the Creative Commons 3.0 ShareAlike (except the Microsoft KB Archive).
Powered by MediaWiki