How to troubleshoot the Recipient Update Service by using the Application log in Exchange 2000 Server or in Exchange Server 2003

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

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

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

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

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

Increase diagnostics logging

To troubleshoot Recipient Update Service 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 Recipient Update Service that you want to troubleshoot.

Note If there is more than one Recipient Update Service that is responsible for the domain, set the schedule to Never run for all but one Recipient Update Service. This will let you focus on the Application log of only one Recipient Update Service server when you troubleshoot Recipient Update Service issues.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.
6. Click MSExchangeSA in the Services list, click Proxy Generation in the Categories list, and then click Maximum.
7. Click OK.

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

Determine whether the Recipient Update Service 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 Recipient Update Service did not start or the Recipient Update Service has stopped responding. If you suspect that the Recipient Update Service did not start or that the Recipient Update Service 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 Recipient Update Service. Typically, if event ID 9006 appears, but event ID 9008 does not appear, this behavior indicates that the Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Services that you have:

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

If the Exchange server cannot see a Recipient Update Service object, the Exchange server cannot determine that it is responsible for that Recipient Update Service object. In this scenario, the Recipient Update Service will never process any objects. However, even if the Exchange server does not detect any Recipient Update Service objects, event ID 8011 and event ID 8012 will appear frequently. This behavior occurs because Abv_dg.dll frequently searches for the existence of Recipient Update Services. 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.

Determine whether the Recipient Update Service 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 Recipient Update Service queries the domain for any new or modified objects to process. Based on the Recipient Update Service schedule, the Recipient Update Service should query the domain for any new or modified objects. The Recipient Update Service should also query the domain if you right-click the Recipient Update Service and then click Update Now.

To determine whether the Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 'DC" description item.

If you have Recipient Update Services 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 Recipient Update Services.

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 Recipient Update Service has not yet queried for this object. If the uSNChanged value for this object is very much higher than the USNs that the Recipient Update Service is currently processing, the Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service schedule to determine when the Recipient Update Service should run. To view the Recipient Update Service 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 Recipient Update Service, and then click Update Now to cause the Recipient Update Service 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 Recipient Update Service schedule causes the Recipient Update Service to process objects, the Recipient Update Service might have stopped responding or the Recipient Update Service may be waiting for a domain controller to return search results.
  
  Typically, if the Recipient Update Service stops responding during an LDAP query, you can start it by restarting the Microsoft Exchange System Attendant service. However, the Recipient Update Service may stop responding again. In this scenario, you must determine the reason that the Recipient Update Service 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 Recipient Update Service has queried the domain for changes to this object.

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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service and then click Rebuild, the msExchDoFullReplication attribute is set to TRUE. When the Recipient Update Service starts to process objects in the Active Directory directory service, the Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service. The only difference between the Rebuild command and the Update Now command is that the Rebuild command causes the Recipient Update Service to restart object processing.

In this scenario, the Recipient Update Service starts from a USN of 1. The Update Now command causes the Recipient Update Service to start processing objects from the highest USN that was last recorded by the Recipient Update Service. This USN is stored in the msExchServer1HighestUSN property on the Recipient Update Service object in the Active Directory directory service. Therefore, if the Recipient Update Service 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 Recipient Update Service operation before you decide to perform a Rebuild operation. When a Rebuild operation has started, you must wait for the Recipient Update Service 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 Recipient Update Service queries for changes, click the following article number to view the article in the Microsoft Knowledge Base:

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 Recipient Update Service to stop responding (hang).
  
  Additionally, if you experience this kind of network problem, the Recipient Update Service does not generate any additional queries to the domain root because the Recipient Update Service 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 Recipient Update Service. 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 Recipient Update Service 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 Recipient Update Service 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'.

Determine which policies match the test object

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

When the Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service 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 Recipient Update Service used the object GUID attribute of the user object as the base of the search. The Recipient Update Service used the filter from the recipient policy as the search filter. In these specific events, the search did not return any results. Therefore, the Recipient Update Service 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 Recipient Update Service generates the proxy address for.

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

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

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 Recipient Update Service 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.

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: If changes were made to the object, the following events 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