Microsoft KB Archive/254030

Knowledge Base

Missing permissions cause the Recipient Update Service not to process accounts in Exchange 2000 Server and Exchange Server 2003

Article ID: 254030

Article Last Modified on 10/25/2007

---

APPLIES TO

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

---

This article was previously published under Q254030

This article is a consolidation of the following previously available articles: 261185, 296123, 297124, 317654, 328223, 328675

SYMPTOMS

You may not be able to log on to or resolve the name of a specific user's or administrator's Exchange 2000 Server or Exchange Server 2003 mailbox. However, you may notice that the Exchange mailbox object appears in the Exchange System Manager console. If you use the Update Now option of the Recipient Update Service, the users are still not stamped with e-mail addresses from your Recipient Policy.

CAUSE

Exchange 2000 Server and Exchange Server 2003 use the Recipient Update Service to assign e-mail addresses to mail-enabled objects. E-mail addresses are just one of many attributes that the Recipient Update Service manages updates for. This issue can occur when the Recipient Update Service does not have the necessary access permissions to update the objects. The "Resolution" section describes four possible scenarios that can cause this behavior and it explains how to address each scenario.

RESOLUTION

Scenario 1: Administrator or user of built-in Active Directory security group name or log on does not resolve

This behavior may occur with the Administrator account and with users or groups that are members of the following Active Directory security groups:

• Schema Administrators
• Domain Administrators
• Enterprise Administrators

The following event may appear in the Event Viewer Application log: Event Type: Warning
Event Source: MSExchangeAL
Event Category: Replication
Event ID: 8315
Description: The service could not update the entry 'CN=UserName,CN=Users,DC=domain,DC=com' because inheritable permissions are not propagated to this object. The inheritable permissions may be disabled because the object belongs to a Windows 2000 administrative group or the inheritable permissions were disabled explicitly by an administrator. DC=ServerDC1,DC=domain,DC=com.

Cause

The Administrator account and the accounts that are members of the Active Directory security groups that are listed do not have the Allow inheritable permissions from parent to propagate to this object check box selected. This check box is located on the Security tab for the user or group object. This tab is displayed when Advanced Features is enabled on the Active Directory Users and Computers management console. If you select this check box, a Microsoft Windows system task clears the check box automatically.

This behavior is by design. This system task prevents security issues that may occur that stem from "elevation of privilege" attacks. For example, Group X is a member of the Domain Administrators security group. If the Access Control List (ACL) on Group X indicates that Group Y can modify the Group X object, members of Group Y may make themselves members of Group X. Transitively, they may become members of the Domain Administrators security group. We recommend that you do not use accounts with administrative permissions to perform mailbox-related tasks.

Resolution

To access mailboxes or perform mailbox-related tasks, use Active Directory accounts that do not have administrative permissions.

Scenario 2: Inheritable permissions from parent are not propagated to object

The Recipient Update Service does not have the necessary permissions to an Active Directory organizational unit that accounts reside in. The following events may appear in the Event Viewer Application log: Event Type: Warning
Event Source: MSExchangeAL
Event Category: Replication
Event ID: 8315
Description: The service could not update the entry 'CN=UserNameB,CN=CustomOrgUnit,DC=domain,DC=com' because inheritable permissions are not propagated to this object. The inheritable permissions may be disabled because the object belongs to a Windows 2000 administrative group or the inheritable permissions were disabled explicitly by an administrator. DC=ServerDC1,DC=domain,DC=com.

Event Type: Error
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8270
Description: LDAP returned the error [32] Insufficient Rights when importing the transaction dn: <GUID=1631A14EC051DF4C87260F7AE8212AE6> changetype: Modify showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=<Exchange_Organization_Name> ... : CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists
mail:User_Name@domain.com
textEncodedORAddress:c=us;a= ;p=Org;o=Site;s=LastName;g=FirstName;
proxyAddresses:SMTP:UserNameB@domain.com : X400:c=us;a= ;p=Org;o=Site;s=LastName;g=FirstName; : smtp:UserNameB@domain.com
msExchPoliciesIncluded:add:{D1D8C0C6-D450-4CD7-8F35-1F5A42C49C1C},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchUserAccountControl:0
msExchALObjectVersion:52
objectGUID:1631A14EC051DF4C87260F7AE8212AE6
-
DC=domain,DC=com

Event Type: Error
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8022
Description: LDAP Modify on directory .domain.com for entry '<GUID=1631A14EC051DF4C87260F7AE8212AE6>' was unsuccessful with error:[0x32] Insufficient Rights [ 00002098: SecErr: DSID-03150646, problem 4003
(INSUFF_ACCESS_RIGHTS), data 0
].
DC=domain,DC=com

If you enable the MSExchangeAL diagnostic logging, you may see the following event in the Event Viewer Application log:
Event Type: Warning
Event Source: MSExchangeAL
Event Category: Replication
Event ID: 8316
Description: The service could not update the entry 'CN=UserNameB,CN=CustomOrgUnit,DC=domain,DC=com' because inheritable permissions have been explicitly disabled to all objects in the container 'OU=CustomOrgUnit,DC=domain,DC=com'. For this object to be mail-enabled properly, you will need to enable inheritable permissions on the security tab for this container so that the permissions can be propagated correctly to the entry that the service is trying to process.

Cause

This behavior may occur if you disabled the Allow inheritable permissions from parent to propagate to this object check box on the Active Directory organizational unit that the accounts reside in.

Resolution

Use either the Active Directory Users and Computers management console or use Active Directory Service Interfaces (ADSI) Edit to re-establish inheritable permissions on the organizational unit.

In Active Directory Users and Computers

1. In Active Directory Users and Computers on the View menu, click Advanced Features.
2. Right-click the container or organizational unit that contains the users who are not being stamped by the Recipient Update Service, and then click Properties.
3. On the Security tab, verify that the Allow inheritable permissions from parent to propagate to this object check box is selected. This options adds Exchange Enterprise Servers to the list of accounts that have rights to that object.
4. Verify that this box is selected at the container level, and also in the user properties. To select the properties for individual users, right-click the user, click Properties, and then click the Security tab.

In ADSI Edit

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 that require that you reinstall Microsoft Windows and Microsoft Exchange. Microsoft cannot guarantee that problems resulting from the incorrect modification of Active Directory object attributes can be solved. Modify these attributes at your own risk.

1. Click Start, point to Programs, point to Windows 2000 Support Tools, and then click ADSI Edit.
2. In ADSI Edit, expand the domain tree, and then expand the organizational unit or container in which the user that is not getting stamped resides.
3. Right-click the container or organizational unit, and then click Properties.
4. On the Security tab, verify that the Allow inheritable permissions from parent to propagate to this object check box is selected. This option adds Exchange Enterprise Servers to the list of accounts that have rights to that object.
5. Verify that this box is selected on all the individual users within that container. If Exchange Enterprise Servers do not have correct rights, the Recipient Update Service will not stamp the mailboxes. To select the properties of the individual users, right-click the user, click Properties, and then click the Security tab.
6. Open the Exchange System Manager (ESM), expand Recipients, and then click Recipient Update Service.
7. Right-click the Recipient Update Service for the domain where these users are located, and then click Update Now. The Recipient Update Service should now have sufficient rights to stamp these objects.

Scenario 3: Exchange Enterprise Servers group is missing required permissions

The Exchange Enterprise Servers group may not have the required permissions at the domain level. The Event Viewer Application log may show the following events:
Event Type: Warning
Event Source: MSExchangeAL
Event Category: Replication
Event ID: 8317
Description: The service could not update the entry 'CN=UserName,CN=Users,DC=domain,DC=com' because inheritable permissions may not have propagated completely down to this object yet. The inheritance time may vary depending on the number of Active Directory objects within the domain and also the load of your domain controllers. To correct this problem, verify that the Exchange permissions have been propagated to this object and then force a rebuild for the Recipient Update Service on this domain.
DC=domain,DC=com

Event Type: Error
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8270
Description: LDAP returned the error [10000001] Local Error when importing the transaction dn: <GUID=1631A14EC051DF4C87260F7AE8212AE6> changetype: Modify showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=<Exchange_Organization_Name> ... : CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists
mail:User_Name@domain.com
textEncodedORAddress:c=us;a= ;p=Org;o=Site;s=LastName;g=FirstName;
msExchPoliciesIncluded:add:{D1D8C0C6-D450-4CD7-8F35-1F5A42C49C1C},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchUserAccountControl:0
msExchALObjectVersion:52
objectGUID:1631A14EC051DF4C87260F7AE8212AE6
-
DC=domain,DC=com

Cause

The permissions may have been modified or removed without knowing how it would affect Microsoft Exchange and the Recipient Update Service.

Resolution

To verify that the permissions for the Exchange Enterprise Servers group are missing at the domain level, follow these steps:

1. Click Start, point to Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.
2. On the View menu, click Advanced Features.
3. Right-click the domain, and then click Properties.
4. Click the Security tab, and then click Advanced.

There are several permissions for Exchange Enterprise Groups at the domain level. These permissions include four write permissions. If some of the write permissions are missing, it is very likely that the MSExchangeAL 8270 and 8317 events that were discussed earlier will be logged in the Event Viewer Application log. If all the write permissions are missing, there may not be any errors logged.

To reset the permissions for the Exchange Enterprise Servers group if they are missing, follow these steps:

1. Insert your Exchange 2000 Server or Exchange Server 2003 CD-ROM into the CD Drive.

2. Click Start, click Run, type

   <drive>:\I386\Setup.exe /domainprep

   in the Open box, and then press ENTER.
   
   <drive> refers to the drive letter of your CD Drive. When you run Setup with the /domainprep switch, you restore default permissions for the Exchange Enterprise Servers group.

3. To rebuild the Recipient Update Services, follow these steps:
   1. Click Start, point to Programs, point to Microsoft Exchange, and then click Exchange System Manager.
   2. Double-click Recipients, and then click Recipient Update Services.
   3. Right-click each Recipient Update Service listed in the right pane, and then click Rebuild.

Note We do not suggested that you rebuild the Recipient Update Service here for the following reasons:

1. 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.
2. Repeatedly performing a rebuild operation on the Recipient Update Service may make the troubleshooting process more difficult. Therefore, instead of repeatedly performing a rebuild operation on the Recipient Update Service, you can view the events that the Recipient Update Service generates to determine where the Recipient Update Service problem exists.

Scenario 4: Group has the hideDLMembership attribute set to True

In this scenario, you may see the following event in the Event Viewer Application log: Event Type: Warning
Event Source: MSExchangeAL
Event Category: Replication
Event ID: 8315
Description: The service could not update the entry 'CN=UserName,CN=Users,DC=domain,DC=com' because inheritable permissions are not propagated to this object. The inheritable permissions may be disabled because the object belongs to a Windows 2000 administrative group or the inheritable permissions were disabled explicitly by an administrator. DC=ServerDC1,DC=domain,DC=com.

For information about this specific scenario, see the following article in the Microsoft Knowledge Base:
253828 How the Recipient Update Service Populates Address Lists

Additional query words: rus

Keywords: kbprb KB254030

---

Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.