Event ID 1025 is logged two times in the Application log with the "EcGenerateNRN: Error: 0x80070005" and "EcGenerateReadReport: Error: 0x80070005" error codes on a computer that is running Exchange Server 2003 or Exchange 2000 Server (899393)



The information in this article applies to:

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

SYMPTOMS

On a computer that is running Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server, you may experience the following symptoms:
  • Both the following events are logged in the Application log on the computer that is running Microsoft Exchange Server:

    Event ID 1025
    Event Type: Warning
    Event Source: MSExchangeIS Mailbox Store
    Event Category: General
    Event ID: 1025
    Date: date
    Time: time
    User: N/A
    Computer: ServerName
    Description: An error occurred on database "First Storage Group\Mailbox Store". Function name or description of problem: EcGenerateNRN: Error: 0x80070005

    Event ID 1025
    Event Type: Warning
    Event Source: MSExchangeIS Mailbox Store
    Event Category: General
    Event ID: 1025
    Date: date
    Time: time
    User: N/A
    Computer: ServerName
    Description: An error occurred on database "First Storage Group\Mailbox Store". Function name or description of problem: EcGenerateReadReport: Error: 0x80070005
  • If you follow the steps that are mentioned in the following Microsoft Knowledge Base article to try to resolve the previously mentioned event errors, the issue is not resolved:

    268831 Event 1025, Error 0xfffff9bb During EcGenerateNRN or EcGenerateReadReport

    Note In this article, the same functions are mentioned in the event descriptions. However, the error codes are different for the event that is in Microsoft Knowledge Base article 268831 and the events that are in this article. If you run the ISINTEG -fix command to resolve the issue that is mentioned in this article, the event ID 1025 events generally occur again within several days.

CAUSE

This issue occurs if the following conditions are true:
  • The computer account for the Exchange server has an explicit Deny permission for the Receive As permission assigned.
  • A user deletes an unread e-mail message that has a read receipt requested.
In this situation, Microsoft Exchange tries to generate a non-read notification message by using the credentials of the operating system. However, Exchange does not have sufficient permissions to generate the non-read notification message because the computer account has an explicit Deny permission for the Receive As permission assigned. Therefore, both of the event ID 1025 events that are mentioned in the "Symptoms" section are logged in the Application log.

By default, the computer account for the Exchange server has an explicit Allow permission for the Full Control permission assigned.

Note In a clustered Exchange environment, all the cluster node computer accounts have an explicit Allow permission for the Full Control permission assigned.

One of the rights that is granted by this explicit Allow permission for the Full Control permission is the Receive As permission. Additionally, the computer account for the Exchange server is a member of the Exchange Domain Servers group.

The Exchange Domain Servers group inherits the Deny permission for the Receive As permission. Assume a situation where you change the inherited Deny permission for the Receive As permission for the Exchange Domain Servers group to an explicit Deny permission for the Receive As permission for the computer account for the Exchange server.

In this situation, the explicit Deny permission for the Receive As permission takes precedence over the explicit Allow permission for the Receive As permission that is assigned to the computer account for the Exchange server. Therefore, Exchange does not have sufficient permissions to generate a non-read notification message. This behavior may occur if one of the following conditions is true:
  • The computer account for the Exchange server is removed from the Security tab of the Exchange computer object in Exchange System Manager.
  • The Apply these permissions to objects and/or containers within this container only check box is cleared on the Security tab of the Exchange computer object in Exchange System Manager. Additionally, the existing permissions are copied to the Exchange computer object.
Note The symptoms that are mentioned in this article do not indicate a serious problem with Exchange.

RESOLUTION

To resolve this issue, follow these steps.

Step 1: Export the permission entries for the Exchange server object

Use the DSACLS command to export the permission entries for the Exchange server object from the Active Directory Configuration container. To do this, follow these steps:
  1. Determine the distinguished name of the Exchange server. To do this, 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 that you 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.
    1. Start the ADSI Edit tool. To do this, click Start, click Run, type adsiedit.msc in the Open box, and then click OK.

      Note The ADSI Edit tool is included with the Microsoft Windows Support Tools. Use one of the following methods to install the Microsoft Windows Support Tools:
      • Double-click Setup.exe in the Support\Tools folder on the Microsoft Windows 2000 CD.
      • Double-click Suptools.msi in the Support\Tools folder on the Microsoft Windows Server 2003 CD.
    2. In the ADSI Edit Microsoft Management Console (MMC) snap-in, expand Configuration Container [domaincontrollername.example.com].
    3. Expand CN=Configuration,DC=example,DC=com, expand CN=Services, expand CN=Microsoft Exchange, expand CN=organizationName, expand CN=Administrative Groups, expand CN=yourAdministrativeGroup, expand CN=Servers, and then expand CN=ExchangeServerName.

      Note that the ExchangeServerName placeholder is the name of the Exchange server of which you want to obtain the distinguished name.
    4. Right-click CN=ExchangeServerName, and then click Properties.
    5. In the Select which properties to view list, click Both.
    6. In the Select a property to view list, click distinguishedName.
    7. Copy the value from the Value(s) box, and then click Cancel.
    8. Quit ADSI Edit.
  2. Click Start, click Run, type cmd in the Open box, and then click OK.
  3. At the command prompt, type the following command, and then press ENTER:

    dsacls "distinguishedName" > serverName.dsacls

    In this command, replace distinguishedName with the distinguished name that you copied from the Value(s) box in step g. Replace serverName with the NetBIOS name of the Exchange server.

    Note Include the quotation marks around the distinguished name of the Exchange server.
  4. Use a text editor, such as Notepad, to open the serverName.dsacls file that was created in the command from step 3. This file should display the computer account as having the Full Control permissions similar to the following example:

    Access list:
    Effective Permissions on this object are:
    
    Allow <EXAMPLE>\<SERVERNAME>$		FULL CONTROL

    Note For an Exchange server that is in a clustered environment, this entry appears similar to the following example:

    Access list:
    Effective Permissions on this object are:
    
    Allow <EXAMPLE>\<node-1>$		FULL CONTROL
    Allow <EXAMPLE>\<node-2>$		FULL CONTROL

    Additionally, the Exchange Domain Servers group should inherit a Deny permission for the Receive As permission as follows:

    Access list:
    Effective Permissions on this object are:
    
    Deny <EXAMPLE>\Exchange Domain Servers	Receive As  <Inherited from parent>

    Important If the Exchange server has an explicit Deny permission for the Receive As permission assigned instead of an inherited Deny permission for the Receive As permission, this explicit permission overrides the explicit Full Control Allow permission that the computer is assigned.
You can determine whether one or both of the following issues exist when you view the generated results from the DSACLS command:
  • The computer account is missing from the permission entries.
  • Inheritance is removed for the Receive As permission and the computer account has an explicit Deny permission for the Receive As permission.

Step 2: Restore the computer account permissions

If the computer account is missing from the permission entries, restore the computer account together with Full Control permissions. To do this, follow these steps:
  1. Start Exchange System Manager.
  2. If Administrative Groups are enabled, expand Administrative Groups, and then expand your administrative group.
  3. Expand Servers, right-click the Exchange server where the event ID 1025 events are logged, and then click Properties.
  4. In the ServerName Properties dialog box, click the Security tab, and then click Advanced.
  5. Click Add, click the computer account of the Exchange computer in which you experience this issue, and then click OK.
  6. In the Apply onto list, click This object, subcontainers and children objects if this option is not already selected.
  7. In the Permissions list, click the Full control check box in the Allow column.
  8. Click to clear the Apply these permissions to objects and/or containers within this container only check box if this check box is selected, and then click OK two times.

    Important If you click to select the Apply these permissions to objects and/or containers within this container only check box, the Full Control permission assignment does not propagate to child objects even with permission inheritance enabled. In this situation, the events that are mentioned in the "Symptoms" section are still logged when Exchange tries to generate a non-read notification message.

Step 3: Restore permission inheritances for the computer account

If the computer account has an explicit Deny permission for the Receive As permission assigned, restore permission inheritance for the computer account. To do this, follow these steps:
  1. Start Exchange System Manager.
  2. If Administrative Groups are enabled, expand Administrative Groups, and then expand your administrative group.
  3. Expand Servers, right-click the Exchange server where the event ID 1025 events are logged, and then click Properties.
  4. In the ServerName Properties dialog box, click the Security tab.
  5. If the Allow inheritable permissions from parent to propagate to this object check box is selected, follow these steps:
    1. Click to clear the Allow inheritable permissions from parent to propagate to this object check box, and then click Remove.
    2. Click Apply.

      Note You might have a situation where the following conditions are true:
      • The Allow inheritable permissions from parent to propagate to this object check box was previously cleared.
      • The existing permissions were copied to this object.
      • The Allow inheritable permissions from parent to propagate to this object check box was again selected.
      In this situation, it is best to remove all copied permissions, and then re-enable the inherited permissions.
  6. Click to select the Allow inheritable permissions from parent to propagate to this object check box, and then click Apply.
  7. Click OK, and then quit the Exchange System Manager program.

MORE INFORMATION

If the event ID 1025 events persist after you perform the steps that are mentioned in the "Resolution" section, verify that permission inheritance is not disabled on one or more of the mailbox store objects.

Note Sometimes, permission inheritance might have been disabled, the existing permissions were copied to the mailbox store object, and then permission inheritance was re-enabled. In this situation, the inherited Deny permission for the Receive As permission becomes an explicit Deny permission for the Receive As permission.

This explicit Deny permission for the Receive As permission overrides other Allow permissions. Therefore, it is best to remove the copied permissions, and then re-enable permission inheritance.

To re-enable permission inheritance on a mailbox store, follow these steps:
  1. Start Exchange System Manager.
  2. If Administrative Groups are enabled, expand Administrative Groups, and then expand your administrative group.
  3. Expand Servers, expand the Exchange server where the event ID 1025 events are logged, expand a storage group, right-click a mailbox store, and then click Properties.
  4. In the Mailbox Store ServerName Properties dialog box, click the Security tab.
  5. If the Allow inheritable permissions from parent to propagate to this object check box is selected, follow these steps:
    1. Click to clear the Allow inheritable permissions from parent to propagate to this object check box, and then click Remove.
    2. Click Apply, and then click Yes.

      Note You might have a situation where the following conditions are true:
      • The Allow inheritable permissions from parent to propagate to this object check box was previously cleared.
      • The existing permissions were copied to this object.
      • The Allow inheritable permissions from parent to propagate to this object check box was again selected.
      In this situation, it is best to remove all copied permissions, and then re-enable the inherited permissions.
  6. Click to select the Allow inheritable permissions from parent to propagate to this object check box, and then click Apply.
  7. Click OK when you receive the following error message:
    The inherited entries will not appear until you close and reopen this property sheet.

    ID no: c1033027
    Exchange System Manager
  8. Click OK.

Modification Type:MajorLast Reviewed:6/15/2005
Keywords:kbEventLog kbtshoot kbprb KB899393 kbAudITPRO