Export (0) Print
Expand All
Expand Minimize
2 out of 6 rated this helpful - Rate this topic

MSExchangeIS 5000 (0x80004005): Cannot Mount Database Because of Incorrect Service Account or Missing SeSecurityPrivilege Permissions or Incorrect Group Membership

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2009-08-17

The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 5000 events with error code 0x80004005 in the Application log. The event indicates that a database or databases on the Exchange server cannot be mounted because of an incorrect service account, missing SeSecurityPrivilege permissions, or incorrect group membership.

The event can occur when any of the following is true:

  • The Manage auditing and Security log permission (SeSecurityPrivilege) is removed from the Exchange Enterprise Servers group on one or more domain controllers. The Exchange Enterprise Servers group must have the Manage auditing and Security log permission on all domain controllers in the domain. When this condition is true, one or more Exchange Server related services will not start.
  • The Microsoft Exchange Information Store service is starting with an account other than Local System, or if the domain controller, the domain, or the Local Machine Security Policy does not include the Local Service account in the Generate Security Audits policy. When this condition is true, the Exchange Information Store service does not start.
  • The Exchange Enterprise Servers group from the parent domain does not contain the Exchange Domain Servers group from the child domain.

The event can also be identified as MAPI_E_CALL_FAILED. The event applies to the following versions of Exchange server:

  • Microsoft Exchange Server 2007
  • Microsoft Exchange Server 2003
  • Microsoft Exchange 2000 Server

To resolve the issue, do one or more of the following:

  • If Manage auditing and Security log permission (SeSecurityPrivilege) is removed from the Exchange Enterprise Servers group on one or more domain controllers, follow these steps:
    To add permissions on one or more domain controllers
    1. Use Policytest.exe to troubleshoot permissions issues. Policytest.exe is located in the Support\Utils\I386 folder on the Exchange 2000 Server CD, or in the Support\ExDeploy folder on the Exchange Server 2003 CD. Use Policytest.exe to determine whether the "Manage auditing and security log" permission for the Exchange Enterprise Servers group is missing from a domain controller. A successful result returns information that resembles the following:

      Local domain is "<contoso.com>" (contoso) Account is "CONTOSO\Exchange Enterprise Servers" DC = "<ComputerName>" In site = "<Default-First-Site-Name>" Right found: "SeSecurityPrivilege"

      Note   A successful result shows that the "Manage auditing and security log" permission exists. You must have domain administrator rights to run Policytest.exe. For more information about the Policytest.exe utility, see Microsoft Knowledge Base 281537, XADM: Description of the Policytest.exe Utility.

      Note   The Policytest.exe tool cannot be used in a native Exchange 2007 environment.

    2. Reset the Exchange Enterprise Server default permissions at the domain level. To do this, follow these steps:

      1. Run the setup /domainprep command from the Exchange Server CD or from a network installation point. The setup /domainprep command adds the Exchange Enterprise Servers group to the domain that has default permissions. When you run the setup /domainprep command, the permissions are immediately added to one domain controller. Then, the change replicates to the other domain controllers.
      2. Restore permissions inheritance to other organizational units. Then, wait for the domain controllers to replicate the changes throughout the domain.
      3. Run Policytest.exe. Note which domain controllers return the following successful result:
        Right found: "SeSecurityPrivilege"
        If all domain controllers have the correct permissions, restart the Exchange Server services. If no domain controllers have the correct permissions, see step 3.
    3. Verify the default domain controllers' policy. To do this, follow these steps:

      1. Start the Active Directory Users and Computers snap-in.
      2. Right-click the Domain Controllers container, and then click Properties.
      3. Click the Group Policy tab, and then make sure that Default Domain Controllers Policy is listed in the Group Policy Object Links box.
        Note   If Default Domain Controllers Policy is not listed, click Add, click Default Domain Controllers Policy, and then click OK. Then, wait for this change to replicate to all other domain controllers.
      4. Run the setup /domainprep command from the Exchange Server CD or from a network installation point. The setup /domainprep command adds the Exchange Enterprise Servers group to the domain that has default permissions.
      5. Run Policytest.exe. Note which domain controllers return the following successful result:

      Right found: "SeSecurityPrivilege"

      If all domain controllers have the correct permissions, restart the Exchange Server services. If some domain controllers do not have the correct permissions, see step 4.

    4. Manually add permissions to the domain controller. The File Replication Service (FRS) may not replicate the updated security policy to one or more domain controllers after you run the setup /domainprep command. If this problem occurs, you must manually assign the correct permissions to the Exchange Enterprise Servers group. If some domain controllers or all domain controllers do not have the correct permissions, assign the "Manage auditing and security log" permission to the Exchange Enterprise Servers group. Then, wait for the setting to replicate to the other domain controllers. To do this, follow these steps:

      1. Start the Active Directory Users and Computers snap-in.
      2. Right-click the Domain Controllers container, and then click Properties.
      3. Click the Group Policy tab, click Default Domain Controllers Policy in the Group Policy Object Links box, and then click Edit.
      4. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment.
      5. In the right pane, double-click Manage auditing and security log, click Add, click Browse, and then add the Exchange Enterprise Servers group.
      6. In the Add user or group dialog box, click OK. Then, click OK again.
      7. Exit the Group Policy snap-in, and then click OK in the Domain Controllers Properties dialog box.
        Note   Sometimes, the Exchange Enterprise Servers group may not be visible when you click Browse in the Add user or group dialog box. If this behavior occurs, add the Exchange Domain Servers group. Then, run the setup /domainprep command again. This process makes the addition of the Exchange Enterprise Servers group persist across all domain controllers.
  • If the Exchange Information Store service is starting with an account other than Local System, or if the domain controller, the domain, or the Local Machine Security Policy does not include the Local Service account in the Generate Security Audits policy, follow the resolution prescribed here.
    By default, the Exchange Information Store service uses the Local System account to start the Information Store service (MACHINENAME$). Use the Services.msc snap-in to check which account is being used to start the Information Store service. If the account is the Local System account, you must regrant the Local System account the Generate security audits right. To do this, use one of the following methods:
    To regrant the Generate security audits right to the Local System account
    1. Rerun the Exchange Setup /domainprep command from this computer.

    2. Manually grant the Local System account the Generate security audits right on one of the following policies:

      • The domain controller's policy
      • The domain policy
      • The Local Machine Security policy

    To regrant the Generate security audits right to the Local Machine Security policy of a member server
    1. Click Start, click Administrative Tools, and then click Local Security Policy.

    2. Expand Security Settings, click Local Policies, and then click User Rights Assignment.

    3. In the right pane, double-click Generate security audits, click Add, enter the MACHINENAME$, and then click OK two times.

    4. Exit the Group Policy snap-in.

    If you start the Information Store service by using an account that is not the Local System account, you should change it back to the Local System account (MACHINENAME$). Then, try to start the Information Store service. For more information about why Exchange 2000 Server and Exchange Server 2003 use the Local System account to start Exchange services, see Microsoft Knowledge Base article 239762, Exchange Services Run Under LocalSystem.
  • If Exchange Enterprise Servers group from the parent domain does not contain the Exchange Domain Servers group from the child domain, add the Exchange Domain Servers group from the child domain to the Exchange Enterprise Servers group in the parent domain. You can also resolve this problem by creating the Recipient Update Service in the root domain.
    To resolve this issue, run Exchange Setup with the /domainprep switch on a server in the remote Windows domain. Then, on the Exchange server use the Exchange System Manager to create a Recipient Update Service for the remote domain. To do this, follow these steps:
    To create a Recipient Update Service for the remote domain
    1. Click Start, click Programs, click Microsoft Exchange, and then click System Manager.

    2. Expand the Organization object, and then expand the Recipients container.

    3. Click Recipient Update Service.

    4. In the right pane, right-click New, and then click Recipient Update Service.

    5. Click the domain that does not have an instance of the Recipient Update Service and that has users who must be updated by Exchange.

    6. Click Next.

    7. Select the server where you want to run the Recipient Update Service and process all the necessary users with the Exchange attributes.

    8. Click Next.

    9. Click Finish.

    10. To manually initiate an update of the recipients in that domain, right-click the Recipient Update Service, and then click Update Now to force an update.

    For more information, see Microsoft Knowledge Base article 253770 Tasks performed by the Exchange Recipient Update Service.
 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.